Miguel Gonçalves wrote:
No. This is a stratum 2 server and it gets the time from stratum 1 servers
thus the names and not IP addresses.
Poorly connected stratum 1 servers. With current WAN speeds you should
have delays more like 10ms. Maybe you WAN is overloaded. Certainly you
haven't prioritised NTP traffic. As you are running VoIP, maybe you
have prioritised that.
Assuming ntp04, ntp05 and ntp06 are on the same LAN I see offsets higher
than 100 us. Is it possible to decrease these numbers?
Why do you need that accuracy. VoIP will tolerate a few milliseconds.
Firstly note that the offset is not the same as the error. When things
are stabilised the error should be several times less than the RMS offset.
To improve:
- Do use local radio clocks - the jitter from your long delay external
servers doesn't give you a good start;
- Don't use Gigabit switches, these can introduce considerable latency;
- Beware of modern ethernet cards that do interrupt combining;
- Make sure that your routers and the ethernet driver give NTP traffic
highest priority. As you are presumably already using EF for the VoIP
traffic, and that is likely to be a significant part of the traffic,
this may not be possible within the DiffServ framework;
- ideally don't run VoIP on the same machine, as it likely to produce
bursty traffic
OK. But this is a 24 port Gigabit switch from Cisco. I wouldn't expect
asymmetry but it could be.
Gigabit switches are bad news for anything with extreme latency
requirements.
All these machines sit in a room temperature controlled at 20 ºC. 10.0.2.2
is a backup server that just does some work every hour but nothing huge
That doesn't mean that there is a good exchange of air between the hot
areas and the controlled room. Incidentally the best way of cooling
machines, although not necessarily the best way of getting a constant
temperature, is blow the cooled air directly into the machines, rather
than just generally cooling the air in the room.
.
10.0.2.2 has been running for quite a while and it doesn't seem to get lower
offsets. Could it be because it's running Linux? I've heard Linux is not as
good as FreeBSD for time keeping.
It probably means there is jitter in the time from the servers. Offset
doesn't measure the error in the internal time, it measures the
estimated instantaneous error in the measurements of that time. A large
error in the measurement will produce a proportionate, but smaller error
in the actual time.
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
