[ntp:hackers] Reduce jitter of refclocks (connected via USB)

todd glassey tglassey at earthlink.net
Mon Mar 14 16:00:32 UTC 2011


On 3/13/2011 1:10 AM, Volker Strauß wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Hi,
>
> 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.
Are there free SATA Connectors on the Mother Board?

You could probably also use the existing 1PPS refclock driver with very 
little hacking on the SATA controller since its periodicity is much 
better than the low-speed hubs which usually contain the USB 
functionality as an embedded USB 1 or USB 2 hub.
> 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.
yes which USB Hub (internal bridge chip) are you using? That will make a 
big difference in how the internal drivers set up interrupt processing.

As to running out of space in the PCI backplane we took a PCI socket 
extender and used it to hack an interrupt line into the system for 1PPS 
but the Meinberg 1PPS pulse is too wide for some systems use. The NIST 
NTP for instance needs a narrower positive going edge (about 50ns) and 
so we are using a box Len Cutler from HP Labs originally designed for 
conditioning the output of a 5071a so that it could be used for this 
same operation.
> 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.
The real issue is why you are going to all this trouble? why do you need 
more than 1ms of resolution for a production system which is not 
involved in securities trading or other HFT type applications?
> 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.
Would that include selecting from the best refclock available too?
>   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.
>
> Cheers
>
> Volker
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
>
> iEYEAREKAAYFAk18ihgACgkQRenTdFBpnRs2NQCfQbb753DMLih+daozw00XOSjL
> YQAAnj/VaBE5vUurSZTLX1AWaGUjdkdC
> =qxT4
> -----END PGP SIGNATURE-----
> _______________________________________________
> hackers mailing list
> hackers at lists.ntp.org
> http://lists.ntp.org/listinfo/hackers
>



More information about the hackers mailing list