[ntp:questions] very slow convergence of ntp to correct time.

Rick Jones rick.jones2 at hp.com
Mon Jan 28 21:47:21 UTC 2008

Brian Utterback <brian.utterback at sun.com> wrote:
> Rick Jones wrote:
> > Eric <nospam-01 at jensenresearch.com> wrote:
> >> Then there is the MAC cache in your switches, which generally
> >> purge after 1-5 minutes.  This can often be adjusted higher, but
> >> that can sometimes cause issues for others when they are
> >> reconfiguring part of the network.
> > 
> > I suppose if STP gets involved, but just on its own, the
> > forwarding table in a switch being aged should only mean that the
> > next frame to that MAC will go out all (enabled) ports on the
> > switch until that MAC is seen again as a source.  That shouldn't
> > affect timing really.
> > 
> > rick jones

> There is some blurring of device type going on. The problem is not
> which port to send to, but rather which MAC address to send to. This
> is more of a problem with routers than switches, but with VLANS and
> whatever these days, the device uin question might be both.

I interpreted Eric's text differently.  Since a device acting as a
"switch" is only operating at layer 2, it doesn't do any lookups on
what the destination MAC should be.  Indeed, a device operating as a
"router" could be doing an ARP lookup, but I ass-u-me-d that was
covered by a prior paragraph of Eric's.

> In any case, if the needed MAC is not available, there has to be an
> ARP request and response before the packet can be sent, but this
> delay is not evident in the return trip for the NTP response packet,
> introducing an asymmetric delay, the worst thing that happen to
> NTP.

> I reported this problem many years ago and suggested using burst at
> that time, but thought that it would be overkill and asked for a way
> to tune it to a fewer number of packets in the burst.  Dave was
> reticent and I was newer to the project then and didn't want to push
> it. Perhaps it is time.

I'll probably quite easily display my profound NTP ignorance here :)
But if there is assymetric delay stemming from an ARP resolution,
won't it affect all the packets in the burst?  Unless the tranmission
time of the burst getting out of NTP is >> the ARP resolution time,
the entire burst is going to be blocked waiting on the ARP resolution.

Now, if this burst was really "send a couple; wait for a reply; send a
couple more" then one might ass-u-me (I do love that spelling :) that
the "couple more" didn't have ARP-induced assymetry.

rick jones
I probably tweak on "switch" vs "router" much the same way an NTP
person tweaks on "accuracy" vs "precision" :)
web2.0 n, the dot.com reunion tour...
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...

More information about the questions mailing list