Problems with huffpuff - NTP

This is a discussion on Problems with huffpuff - NTP ; 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 ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Problems with huffpuff

  1. Problems with huffpuff


    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@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


  2. Re: Problems with huffpuff

    Eric wrote:
    > Any ideas about whether 2uS is even a possible ntp delay value on a
    > 100mb lan


    If 2uS is two microseconds, 2uS is not possible even for a single-byte
    netperf TCP_RR test over a 100Mb LAN so I suspect the same holds true
    for NTP.

    A minimum sized Ethernet Frame is 60 bytes, or 480 bits. At 100
    Mbit/s that takes 4.8 microseconds just to toggle onto the wire.
    Given the need to have two of those, and adding-in host delays and
    such, and that just won't be anywhere near two microseconds.

    Here is a single-byte netperf TCP_RR between a pair of fast systems
    connected via a _gigabit_ link:

    hpcpc107:~# netperf -t TCP_RR -H 192.168.9.108
    TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.9.108 (192.168.9.108) port 0 AF_INET : first burst 0
    Local /Remote
    Socket Size Request Resp. Elapsed Trans.
    Send Recv Size Size Time Rate
    bytes Bytes bytes bytes secs. per sec

    16384 87380 1 1 10.00 14644.22
    16384 87380

    Invert the transactions/s and that is just shy of 70 microseconds
    round-trip. Given that gigabit would toggle those bits 10X faster
    than 100BT, we can ass-u-me that most of the delay is actually
    somewhere other than the wire in the test above, and then that the
    dleay for 100BT would be roughly the same. (of course, as the request
    and response sizes increase, link bitrate will become a component of
    the delay greater than epsilon)

    rick jones
    --
    denial, anger, bargaining, depression, acceptance, rebirth...
    where do you want to be today?
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  3. Re: Problems with huffpuff

    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@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.


+ Reply to Thread