[ntp:hackers] Reduce jitter of refclocks (connected via USB)
martin.burnicki at meinberg.de
Tue Mar 15 09:27:44 UTC 2011
Volker Strauß wrote:
> I am running a Meinberg USB 5131 DCF77 Radio Clock. The clock works
> quite good. I know that USB is a very poor solution for timekeeping, but
> I had no other choice since my mini pc has no serial interface and
> there's no free PCI slot.
First, please keep in mind that the accuracy provided by the DCF77 AM
signal is also only in the same range.
> I noticed that there's a jitter of about (exactly?) 1 ms. As the device
> works with USB 1.1 (Full Speed), I assume that the jitter is a result of
> an additional interrupt interval in some cases, leading to an additional
> error of 1 ms.
The device is USB 1.1, but supports microframing i.e. 125 us rather than
1 ms. Unfortunately the OS device drivers don't use this if they see a
1.1 device. If you connect the device via a USB 2.0 hub, though, the
microframing is used and thus the additional error is reduced to 125 us.
Please note the Meinberg USB devices do not simply send a serial ASCII
string via a built-in serial-to-USB converter. They use the same binary
data structures as the PCI cards, and can be accessed from applications
using the same API calls as the PCI cards. This requires the Meinberg
driver package for Linux.
The original approach of the driver package was to feed the timestamps
to ntpd via ntpd's parse driver, in which case at each second changeover
an IRQ is generated by the PCI devices, and a data packet is sent
automatically by USB devices.
The drawback of this approach is the latency occuring from the moment
the second changeover occurs (and thus the IRQ is generated or the USB
packet is sent) until the timestamp from the refclock arrives in the
parse driver where an associated timestamp of the system time is taken.
Volker, the development version of the Linux driver I've sent you
supports also a different approach where the mbgsvcd daemon which comes
with this driver package lets the kernel driver read both a timestamp
from the refclock (PCI or USB) and an associated system timestamp. The
pair of timestamps is then fed to ntpd via ntpd's shared memory driver.
This approach avoids latencies and execution times which lead to a time
offset even if a PCI card is being used as reference.
The low level routine which reads a timestamp from an USB device is
shared among the Linux and Windows version of our driver package, but
contains conditional code for Windows which reduces the jitter from the
underlying USB layer. We are planning to port this also to the Linux
version, but this has not yet been implemented and tested.
Anyway, under Windows this already provides pretty good accuracy with
the TCR51USB device which receives an IRIG signal and thus yields much
better internal accuracy than a DCF77 AM receiver. I'm sure this is also
true for Linux when it has been implemented.
To test the new approach you simply need to configure the shared memory
driver rather than the parse driver for the USB device, and start the
In ntp.conf, replace the lines
server 127.127.8.0 mode 2 minpoll 4 maxpoll 4 noselect
fudge server 127.127.8.0 ...
etc. by the new lines
server 127.127.28.0 minpoll 4 maxpoll 4 iburst
fudge 127.127.28.0 refid shm0
If you run mbgsvcd in the foreground then it prints the determined
offset between the USB device time and the system time on the console.
Again, keep in mind the accuracy is also limited due to the DCF77 signal.
More information about the hackers