[ntp:questions] NTP vs RADclock?

unruh unruh at invalid.ca
Tue Jun 12 00:33:42 UTC 2012


On 2012-06-11, Rick Jones <rick.jones2 at hp.com> wrote:
> unruh <unruh at invalid.ca> wrote:
>> Tried that. Makes no difference to scatter of return time on the
>> client. Do not know if that means that interrupt coalescence is
>> still on, or that it makes not difference. The problem appears to be
>> in the receipt of the packets, not the transmission (although I
>> guess it could still coalesce interrupts on receipt as well. )
>
> Avoiding TX completion interrupts started happening with 100BT NICs.
> Schemes like only taking a TX compltion interrupt when it covered more
> than half the transmit queue, and then checking TX completions on RX
> interrupts.  Coalescing RX completion interrupts arrived with GbE
> NICs.  If you have all the values as zeros, then presumably there
> should be a 1-1 between interrupts and packets sent/received.
> Presumably then there should be a 1-1 between packets sent/received
> (ifconfig or ethtool -S) and counters incrementing in /proc/interrupts
> for the IRQ(s) of the interface.
>

OK, Since I set the rx-usecs: 0 the clients have lost that strong
correlation of return trip to offset that they had. Ie, it does appear
that there was interrupt coalescence going on in the receipt of the
packets on my Gb etehrnet card, and it was adding randomly up to about 50us to
the return trip ( and increasing the  to the uncertainty of the clock
measured offsets to about 10 us) Thus, if your server has a Gb etehrnet card, make sure
it is actually running at Gb speed, and that the rx-usecs is 0. 
You can check by looking at the scatter plots on your clients (round
trip time vs offset) and see if there is a correlation, especially a
positive correlation (assuming positive offset means client clock is
slow). 

This seems to have brought the offset uncertainly down by a factor of about 2
in the client clocks down to about 5 microseconds (using chrony, not ntpd)

 Ie, standard deviation in measured clock offsets 
a) with Gb card running at 1000Mbps and  all coalescense removed (rx-usecs: 0) -- 5us
b)With Gb card running at 1000Mbps but with rx-usecs: 3  --- 10us
c)with Gb Intel card running at 100Mbps and rx-usecs=3 --- 40us

(All tests run with chrony both on server and client, and with a polling
interval of 4 (ie 16sec))

Note that those clock offsets are not the offsets from true time, but
the measured offset between the server clock (disciplined by a GPS PPS )
and the client via the exchange of ntp packets. Since in the latter two
cases there is strong correlation between return time and measured
offset, the actual offset from true time is probably about twice as big. 





More information about the questions mailing list