On 01/12/2011 12:07 PM, Hal Murray wrote: > Even if you have a perfect source of UTC, it's going to be hard to > keep a typical Linux server within 5 microseconds of that clock. > > I think you need to reconsider the whole system. Where > did that 5 microseconds come from? What happens if/when > the clocks are off? [....] > One of the major sources of clock inaccuracy on typical PCs > and servers is the minor change in frequency of the system > clock because the temperature of the crystal changed. [...]
IMHO, there are at least two other sources for jitter: Modern boards use spread spectrum technology to reduce the emitted electromagnetic radiation. They modulate the frequencies of the cores and other 'non-critical' equipment (as timing goes) to smear the emission spectrum, so the energy is emitted in bands instead of sharp single spikes. So a lot of frequencies are a bit wobbly. I don't know how much that contributes to time measurement noise, but it might be noticeable. Some frequencies might be more affected than others -- My personal AMD64 box seems to run smoother with HPET as clock source instead of TSC. (And no, no proof -- it's a feeling.) There's always interrupt latency, which is still in the order of a few microseconds. (*micro*, not nano or pico!) The speed of interrupt processing in most combinations of interrupt controllers / CPU combinations did not increase that much over the years, at least in typical PCs. That's why some (many?) 10GB and 1GB network chip sets have the ability to coalesce several interrupt requests into one: The interrupt processing is too slow. Then there's interrupt priority, which affects the latency: The serial line IRQ is probably not the highest (should by the system ticker anyway), and interrupt chaining compounds the problem by increasing the jitter in the interrupt latency. Considering the fact that typical PC's are not build for precision time keeping, nor for hard realtime conditions, I always thought that keeping mine in +/-5usec to the PPS pulse of my GPS receiver was quite an achievement... Maybe I should set up a FreeBSD on the same machine, so I could try what happens with an OS known for its good interaction with ntpd. _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions