[ntp:questions] Problems with huffpuff
Eric
nospam-01 at jensenresearch.com
Tue Feb 27 19:24:03 UTC 2007
I have a cluster of NTP servers, mostly Win2K or Cisco, separated into three or more
lan segments connected by routers. I have attempted to use the huffpuff option to
correct for short periods when high traffic between segments or hosts introduces
asymmetric delays across the routers and switches.
It works as hoped sometimes, but eventually it appeared to introduce its own systemic
offset into the ntp process. Specifically, using the windows port with a HP 2524
ethernet switch, the delay figure between ntpds on the same segment is usually on the
order of 200uS.
But occasionally, the delay figure is 0, or very small, like 2uS.
My current theory is that these very low delays, which I think are anomolous or at
the least very infrequent, give a false indication to the huffpuff filter about what
the minimum delay actually is. After that, all regular 200uS polls are treated as
asymetrically delayed and the offset of the ntp loop becomes -200uS. The server in
the example below is not currently using huffpuff, and the server with the short
delay, which is the only referenced server that is on the same subnet, is not a part
of the solution set.
Here is a example from NTPQ -c RV & PEERS:
status=06f4 leap_none, sync_ntp, 15 events, event_peer/strat_chg,
version="ntpd 4.2.0a at 1.1370-o Apr 12 14:10:45 (UTC+02:00) 2005 (12)",
processor="unknown", system="WINDOWS/NT", leap=00, stratum=3,
precision=-19, rootdelay=19.365, rootdispersion=14.451, peer=50369,
refid=u17-eth0.jrc.lan,
reftime=c98efd89.ef3a3364 Tue, Feb 27 2007 13:57:13.934, poll=6,
clock=c98efe89.d45d97d9 Tue, Feb 27 2007 14:01:29.829, state=4,
offset=-0.242, frequency=9.715, jitter=0.359, noise=0.002,
stability=0.001
remote refid st t when poll reach delay offset jitter
==============================================================================
-ntsrv08.jrc.lan ntps11i.jrc.lan 2 u 49 64 377 1.922 0.347 0.422
-ntsrv01.jrcpsn. ntps11i.jrc.lan 2 u 63 64 377 1.474 0.434 0.423
+u5-eth0.jrc.lan ntps11i.jrc.lan 2 u 2 64 377 3.644 -0.262 0.086
-u71-eth0.jrc.la ns8.jensenresea 2 u 53 64 377 2.430 0.380 0.177
-gw.jrc.lan ns1.jensenresea 2 u 6 64 377 3.998 0.864 0.197
*u17-eth0.jrc.la ntp2.usno.navy. 2 u 59 64 377 4.030 -0.268 0.306
+ntsrv05.jrc.lan ntps11i.jrc.lan 2 u 25 64 377 1.955 0.209 0.415
-fw-int.sea.lan tick.jrc.us 3 u 33 64 377 15.699 1.518 0.258
-ntsrv07.jrc.lan u71-eth0.jrc.la 3 u 13 64 377 0.002 0.264 0.209 <====
LOCAL(0) LOCAL(0) 12 l 25 64 377 0.000 0.000 0.002
bcast-int.jrc.l .BCST. 16 u - 64 0 0.000 0.000 0.002
Any ideas about whether 2uS is even a possible ntp delay value on a 100mb lan, or if
such an infrequent short delay could derail huffpuff?
- Eric
More information about the questions
mailing list