On 2012-06-11, Rick Jones <rick.jon...@hp.com> wrote: > unruh <un...@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. _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
