STM32F4 time experiments

other runs

Goal

1ms or better accuracy on a USB-connected GPS.

Hardware

stm32f4 discovery board using a 10.5mhz internal timer is measuring the PPS interval from a Fastrax UP501 GPS reciever (claims "+/- 50 ns (RMS) accuracy"). The stm32f4 is connected via full-speed usb to a pc

Software

See: usb gps

Changes from Run 5

Timestamp the USB byte in the kernel

Comparing kernel timestamp vs realtime timestamp

Min and Max offsets within the 16 second cycle

userland on the left, kernel on the right

Notes: (userland timestamping) realtime enabled at day 1@~15:00 (kernel timestamping) moderate cpu/disk activity started at day 1@20:33, ended day 2@~17:30. Heavy cpu/disk activity started at day 2@18:31, ended day 2@23:15. VM enabled at day 3@15:23 and ended day 3@16:31
Even under high load, the window on the kernel side between min/max is limited in size. CPU scaling frequency had a huge impact. Turning on a VM on the machine caused a large time error.

ntpd's measurement of jitter

userland on the left, kernel on the right

See the graph above for the explanation of the different patterns (spikes, low areas). Kernel timestamping lowered the jitter.

Histogram

This takes all samples within a 16 second window and graphs the number of samples within X µs of the mode

Comparison between run 5 and run 6:
percentileRun 5Run 6
50%10 µs3 µs
90.0%40 µs22 µs
99.0%153 µs46 µs
99.9%922 µs56 µs
Run 6 changes resulted in a signficant reduction in variance

PC clock

Loopstats graph - local clock error (PPM, green) and USB/GPS offset (µs, red)

The heavy CPU usage between the start and day 2@23:15 is evident in the local clock PPM error (heavy CPU usage = higher temperature). The impact of starting the VM on day 3@15:23 is evident in the offset

Overall conclusion

This change lowered the 90 percentile window from 40µs to 22µs

Future enhancements