[time-nuts] Using the HP 58503a to correct your PC clock

[Michael Wouters]

On Sat, Aug 6, 2016 at 6:41 AM, Attila Kinali <attila at kinali.ch> wrote:

> So, best you can hope for is an jitter of ~50us rms within the same
> city with _good_ network connections. Once the distance increases
> and especially if you get routers with conquestion inbetween, then
> the delay and its jitter rise quickly.

That pretty well agrees with my practical experience of NTP on
somewhat longer, uncongested links.
NTP servers separated physically by 1000-3000 km but perhaps 10
network hops had apparent offsets of about 100 us rms with respect to
each other.

Cheers
Michael

On Sat, Aug 6, 2016 at 6:41 AM, Attila Kinali <attila at kinali.ch> wrote:
> On Fri, 5 Aug 2016 21:35:05 +0200
> Magnus Danielson <magnus at rubidium.dyndns.org> wrote:
>
>> > From a "Time Nuts" point of view none of the above are even close to
>> > accurate clocks.  A microsecond is a very course and crude measure of
>> > time.  Pico and Femto seconds are were it gets interesting.
>>
>> Certainly. Look at White Rabbit, which really changes how PTP works.
>> It may not be pico second accurate, but you get pretty far with it.
>
> WR achieves sub-ns accuracy. Depending on the environment <200ps offset/skew
> are possible.
>
>> > Maybe someday NTP will have a time nuts level of accuracy.  the new up
>> > coming version, I hear will be using 64 bits to carry the factional part of
>> > a second.  That is truly nuts.
>>
>> Well, if NTP takes the main ideas from PTP and White Rabbit, maybe then.
>
> This wont help. The achievable accuracy is dictated by the measurement
> and the delay uncertainty. Even with network cards that support time stamping,
> you cannot hope to get better than 1/125MHz=8ns. Standard network cards
> will just trigger an IRQ at some point after reception and enqueuing of
> the packet. The IRQ is measured by the OS, which leads to uncertainties
> in the order of several us to a couple of 10s of us. If the card does DMA
> the packet directly into main memory, then this value is even more inflated.
>
> The network itself has a relatively high jitter. Assume 10s to 100s of us
> on a local network per switch. Once you pass a router, you can assume
> jitter in the order of a couple of 100us to a couple of ms per router.
>
> To illustrate this, here a few ping statistics (64byte, 1000 packets each):
>
> Local network, GBit/s, two level1 smart switches:
> rtt min/avg/max/mdev = 0.073/0.131/0.362/0.044 ms
>
> Two hosts in colo centers within the same city, same ISP, hence
> on the same "network" (ie no conguestion), 4 hops:
> rtt min/avg/max/mdev = 0.288/0.437/0.620/0.051 ms
>
> Two hosts in colo centers, within the same city, different ISP
> but with direct peering (ie no conguestion), 9 hops:
> rtt min/avg/max/mdev = 2.916/3.008/3.505/0.078 ms
>
> Two hosts in colo centers, one in Switzerland, one in Germany, 9 hops
> rtt min/avg/max/mdev = 12.636/12.947/28.943/0.609 ms
>
> These are all well connected machines, with "carrier grade" networks
> inbetween. No consumer internet connections with their huge delays
> and jitter.
>
> So, best you can hope for is an jitter of ~50us rms within the same
> city with _good_ network connections. Once the distance increases
> and especially if you get routers with conquestion inbetween, then
> the delay and its jitter rise quickly.
>
>
>                         Attila Kinali
>
> --
> Malek's Law:
>         Any simple idea will be worded in the most complicated way.
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.