On Sat, Aug 6, 2016 at 6:41 AM, Attila Kinali <[email protected]> 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 <[email protected]> wrote: > On Fri, 5 Aug 2016 21:35:05 +0200 > Magnus Danielson <[email protected]> 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 -- [email protected] > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
