[ntp:hackers] Reduce jitter of refclocks (connected via USB)
Volker.Strauss at gmx.de
Sun Mar 13 09:10:49 UTC 2011
-----BEGIN PGP SIGNED MESSAGE-----
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.
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.
As some servers on the internet have a lower jitter with my connection
and low traffic, I thought about reducing refclock jitter by some
additional code. I'm not familiar with the existing code in detail, so
please don't hang me for the following. It's only an idea and if there
are better solutions, feel free to post them.
My idea is to compare the delays of the pollings from the refclock. If
the 1-ms-jitter really comes from the interrupt period of the USB
protocol, my assumtion is that the device sometimes need longer to
response to the request, which results in an additional error of about 1
millisecond. Based on this assumtion, the following (pseudo-) code would
eventually minimize the jitter:
"timestamp": the timestamp received from the device
"min_delay": minimal delay of the device measured since ntpd startup;
shold be initialized with the first delay or a huge value
"act_delay": delay measured while reading the current timestamp
if(act_delay < min_delay) // Update min_delay
min_delay = act_delay;
else // add the additional delay occured in the actual polling
timestamp += (act_delay - min_delay);
The delay could be displayed by the ntpq program as well.
This method would "ignore" the "default delay" (to be configured as
fudge time1), but takes care of jitter caused by interrupt intervals or
something else. Maybe this isn't useful only for USB-driven refclocks?
The precision with USB (1.1) devices could also be improved, if the time
between the polling request by ntpd and the moment where the request
will be sent to the device (Full Speed USB mode: between 0 and 1 ms)
could be determined. But I'm not sure if that would improve the
precision as well as it sounds.
I'm open-minded about your comments on this idea.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
-----END PGP SIGNATURE-----
More information about the hackers