Re: [ntp:questions] ntpd sensitivity to ordering of servers in ntp.conf?

[Mike Cook]

> Le 25 févr. 2016 à 14:13, Miroslav Lichvar  a écrit :
> 
> On Thu, Feb 25, 2016 at 02:49:48AM -0800, Weber wrote:
>> ntp.conf is specifies both servers with minpoll 4/maxpoll 4. Peer and loop
>> statistics are enabled.
> 
>> By just changing the order of servers in ntp.conf the delay and offset
>> values in peerstats are swapped. Now it is A with 60us delay and B has 85us.
>> Similarly, A's offset is not -5us and B is showing +5us.
>> 
>> It appears there is something in ntpd where measurements on server A in
>> ntp.conf come out slightly different depending its ordering in ntp.conf.
> 
> When A is specified as first in the config, the interval between
> polling of A and B will be 1 second and the interval between B and A
> will be 15 seconds. When you swap the servers, the intervals will be
> swapped too. I think there could be a lot of things than would happen
> in 15 seconds, but not in 1 second. Maybe some power saving feature is
> activated or maybe some cache entry expires.
> 
> You could try adding B manually via ntpq -c config:, timing the
> command so that the polling is exactly between two polls of B, and
> see what happens with the delays. Or you could run ping against the
> servers to keep the link "up".
> 
> The direction in which the offset changed suggests it's the processing
> of the server packet that has the extra delay.

Hi,
  I have also run some tests with identically configured (hardware (ARM uc)/LAN 
segment/OS( linux Debian variant )/NTP version 4.2.8p4) servers/client and 
replicate Weber’s findings. However loading the network as suggested by 
Miroslav does not improve the situation. Neither does saturating the cpu with 
other work. Agreed that this is just usecs and would be washed out over the 
WAN, but it is an order of magnitude. Curious.
So what’s up?


> -- 
> Miroslav Lichvar
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions

"The main function of a modern police force is filling in forms."
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ntpd sensitivity to ordering of servers in ntp.conf?

[Miroslav Lichvar]

On Thu, Feb 25, 2016 at 02:49:48AM -0800, Weber wrote:
> ntp.conf is specifies both servers with minpoll 4/maxpoll 4. Peer and loop
> statistics are enabled.

> By just changing the order of servers in ntp.conf the delay and offset
> values in peerstats are swapped. Now it is A with 60us delay and B has 85us.
> Similarly, A's offset is not -5us and B is showing +5us.
> 
> It appears there is something in ntpd where measurements on server A in
> ntp.conf come out slightly different depending its ordering in ntp.conf.

When A is specified as first in the config, the interval between
polling of A and B will be 1 second and the interval between B and A
will be 15 seconds. When you swap the servers, the intervals will be
swapped too. I think there could be a lot of things than would happen
in 15 seconds, but not in 1 second. Maybe some power saving feature is
activated or maybe some cache entry expires.

You could try adding B manually via ntpq -c config:, timing the
command so that the polling is exactly between two polls of B, and
see what happens with the delays. Or you could run ping against the
servers to keep the link "up".

The direction in which the offset changed suggests it's the processing
of the server packet that has the extra delay.

-- 
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

[ntp:questions] ntpd sensitivity to ordering of servers in ntp.conf?

[Weber]

Bored? Need something to do? You could try helping me with this puzzle 
regarding ntpd. This is a rather long message, so if you're otherwise 
busy I won't be offended if you skip it.


-- Executive Summary --

The delay and offset values measured by ntpd appear to change slightly 
when the order of two servers is swapped in ntp.conf.


-- Introduction --

I'm working to verify the performance of two NTP servers I've built, and 
have run into some curious behavior with ntpd on a current release of 
Fedora. This is regarding a few 10's of microseconds at most and is 
certainly not a serious problem.


-- The NTP Servers --

The two NTP servers being tested are embedded systems (Arduino-based) 
and each has an independent GPS reference clock. One uses an HP55300A 
while the other uses a Trimble timing-specific GPS module (ICM SMT 360). 
There are hardstamps on received packets and (oscilloscope-calibrated) 
drivestamps for transmit.


I suspect these servers are accurate to something on the order of a 
microsecond or so and am trying to get some verification of this at the 
network level. This estimate of accuracy only applies when the NIC can 
get onto the wire w/o delay. When there is other network traffic I can 
routinely measure variable delays on the order of a hundred microseconds 
and more.


I realize this sort of accuracy is not perhaps all that useful given the 
variable delays that occur in a typical loaded network. On the other 
hand, by placing one of these servers on an unused Ethernet port it 
could be possible to get reference-clock accuracy without a 
hardware-connected reference clock. And well, like climbing a 
mountain...just because it's there.


-- Test Setup --

The NTP client is a 32-bit Pentium-class PC (an old one with IDE disks) 
running Fedora 23. I believe it has kernel discipline and probably the 
nano kernel but am not positive about that. The kernel build is 
4.2.3-300.fc23.i686.


The PC and two NTP servers are connected to a 100 base-T network hub. 
The hub is not connected to any other networks.


ntp.conf is specifies both servers with minpoll 4/maxpoll 4. Peer and 
loop statistics are enabled.


-- loopstats --

Both offset and frequency offset are very stable in loopstats (as long 
as the CPU temperature stays constant). Over a 6-hour test run, the mean 
value of offset was -0.63us and the standard deviation was 5.5us. 
Frequency jitter hovered around 5ppb with occasional jumps up to about 
10ppb. As I understand it, this is about as good as it gets, even with a 
good local ref clock.


-- The Puzzle --

The curious part is in peerstats. Server A shows a delay averaging 
around 85us and server B is running around 60us. Offsets are also 
different, but by about half as much. Offset on A is about +5us and -5us 
for B.


I was hoping to see closer to identical delays and offsets on the two 
servers. I'm fairly certain they should be closer than 10us in offset. I 
tried the following experiments trying to track this down:


1) Swap network hub ports between servers A and B. No change.
2) Cycle power on network hub after (1). No change.
3) Re-check transmit timestamp timing with oscilloscope. Looks good.
4) Change the order of the two servers in ntp.conf. Yikes, that's it!

By just changing the order of servers in ntp.conf the delay and offset 
values in peerstats are swapped. Now it is A with 60us delay and B has 
85us. Similarly, A's offset is not -5us and B is showing +5us.


It appears there is something in ntpd where measurements on server A in 
ntp.conf come out slightly different depending its ordering in ntp.conf.


So yes, this is really mouse-nuts. It is however setting a bound on how 
accurate I can conclude the NTP servers are.


Any ideas what might be causing this?

(I have some data plots and could e-mail them if desired)

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions