unruh <un...@invalid.ca> wrote: > 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.
The GbE NICs of other vendors will have different semantics for rx-usecs == 3. In the case of e1000 (PCI-X and some PCIe cards depending on era) (and probably e1000e - PCIe cards) driven NICs from Intel a value of three means it was doing a dynamic interrupt throttle/coalescing heuristic. Broadcom or other vendor NICs will have different semantics, though indeed if all the -usecs and -frames are set to zero it should disable interrupt coalescing in the NIC. (Though best to triple check with the vendor documentation) In the case of Intel GbE NICs, I think once one gets above a value of '8' then one is setting an actual coalescing timer. The effect of disabling interrupt coalescing on other aspects of performance besides NTP is left as an exercise to the reader(s). One increasingly old example can be seen, for the time being at least, at ftp://ftp.cup.hp.com/dist/networking/briefs/nic_latency_vs_tput.txt rick jones -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
