1ms or better accuracy on a USB-connected GPS.
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
See: usb gps
Timestamp the USB byte in the kernel
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.
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.
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:
percentile | Run 5 | Run 6 |
---|---|---|
50% | 10 µs | 3 µs |
90.0% | 40 µs | 22 µs |
99.0% | 153 µs | 46 µs |
99.9% | 922 µs | 56 µs |
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
This change lowered the 90 percentile window from 40µs to 22µs