[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