[ntp:questions] Problems with huffpuff

[Richard B. gilbert]

Eric wrote:
> 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
> 

2uS is a very short delay but it might be possible on a 100 Mbit or 1Gb 
    switched network.  On a 100 Mbit switched LAN (Cisco 1548M) I see 
delays of 300 to 400 uS.  The two machines involved are Sun Ultra 10 
workstations separated by the switch and 15 to 20 feet of cable.  A pair 
of much faster machine might do much better; these are antiques eight or 
nine years old.