On Fri, 06 Mar 2009 05:44:24 GMT, Unruh wrote: > Jason <bmwja...@bmwlt.com> writes: > > > >>A sys admin and I discussed the possible solutions today, and we have a >>potential winner, although we can't reach the small 10s of uSec goal, we >>can reach several 100s of uSec (and probably less) easily. We are going >>to make a proposal to mgmt to increase the number of S1 servers, the >>number of GPS receivers, and I'm looking for an Rb clock source for the >>main datacenter as well. We are also re-engaging the blade / enclosure >>vendor. > > It looks, from the situation we have here at my university, that it will > also depend on the kind of switches you have. We replaced our 10/100 > switches with Gbit switches, and the behaviour of ntp decayed significantly > ( by factors greater than 2). Ie, whereas before I was getting 10s of usec > as the "accuracy" of my clocks, it is not creaping toward 100usec. We have > tried to figure out what the problem is, but have not succeeded. These Gbit > switches seem to have, or trigger in the ethernet cards, additional and > assymetric delays of the order of 100-200usec. (assymentric delays are of > course the worst, since they directly affect the errors in ntp). Now If you > run a gps PPS to each machine you could do far better, that seems not to be > an option for you. (I run the PPS on the parallel port, but your blades are > unlikely to have those-- in fact they are getting rarer even on standalone > boxes). > > Ie, test your switches as well.
Interrupt coalescing in ethernet card will also be a bad thing for ntp jitter. /hjj _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
