Discussion:
It is definitely, definitely true that offset (error) is highly
correlated with the distance between the client and the server. For
a time, one of the stratum 2 servers in the USA State of New Jersey
was using a server at a technical university in Poland as a source of
time. When the New Jersey server was connected to a server in New
York (maybe 20-25 miles away), its time output was in sync with
everyone else's, but when it was connected to the one in Poland,
its time was ~30 ms slower than everyone else's. Perhaps the time
it took the New Jersey server to warm up its local DNS (or ARP???)
to access the IP address of the Poland server accounts for this
error. Nothing or no one else has been able to account for it.
And I have checked the formulas for delay and offset in the RFC
and in the implementation in NTPD dozens of times and can find
no error (as long as the server and the client are relatively
close (within a few years) to each other in time).
On that same note, NTPD could rid itself of all those bit-twiddling
macros to compute time differences by recognizing that 32-bit
arithmetic is with us now and unsigned 64-bit arithmetic is built
in to most modern compilers. In addition, Microsoft's Visual Studio
Express, I believe, sets the rounding mode of the FPU to convert
everything to 63 bits of significant, whereas the default rounding
mode of the FPU is to compute everything with the original bits of
the arguments and then to round off to the value closest to the
exact result. Therefore, it might be possible to pick up a bit or
two of precision by setting the rounding mode of the FPU to its
default before converting from NTP timestamp format to doubles.
I am not sure if the FPU rounding mode is preserved between context
switches or not, but if it is, then the rounding mode of the FPU
could be set in NTPD initialization code and forgotten elsewhere.
C Elliott
-----Original Message-----
From: questions-bounces+elliott.ch=verizon....@lists.ntp.org
[mailto:questions-bounces+elliott.ch=verizon....@lists.ntp.org] On Behalf Of
Harlan Stenn
Sent: Monday, January 27, 2014 7:55 PM
To: Brian Utterback
Cc: questions@lists.ntp.org
Subject: Re: [ntp:questions] NTP request retry?
Brian Utterback writes:
> On the other hand, I have definitely observed that phenomenon as a
> source of asymmetric round trip time. The outgoing request packet gets
> delayed for ARP request and reply at each hop, but the return packet
> has no such delay. Quite a while ago I suggested a special burst mode
> where two packets were sent, one shortly after the other and the first
> one would be ignored. Dr. Mills said that the first would generally be
> ignored because of the longer round trip time (delay), but I thought
> that treating the first packet as a throw away would be better because
> otherwise you end up with half the number of "good" samples in the
> billboard. Anyway, nothing every came of the discussion.
I'm game to see this discussion warmed up.
H
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
