[ntp:questions] NTP request retry?

William Unruh unruh at invalid.ca
Wed Jan 29 20:37:40 UTC 2014

On 2014-01-29, Rob <nomail at example.com> wrote:
> detha <detha at foad.co.za> wrote:
>>> It is apparent that the problem does not occur when the link is busy, but
>>> I still don't know the cause.
>>> It may also be some power-saving mechanism, for example.
>> First step is to prove that the problem goes away when the link is kept
>> busy with totally unrelated traffic, to be sure it has nothing to do with
>> the ntp client or server. That is what running a ping from client to
>> server was supposed to accomplish.
> Yes, I also tested it before when running a tail -f on some file and
> then it did not happen either.
> Right now I have clamped the poll to 64 seconds and results are perfect.
> I'll try to increase that to 256 and see what happens.
>> If keeping the link open with a ping helps, second step is to determine
>> what times out. Run a ping from somewhere else to the server, or from the
>> client to somewhere else. If running a ping from the client to somewhere
>> else makes the problem go away, it could be some power-saving thing
>> getting in the way. If not, it /might/ be ARP; time to start running
>> tcpdump on both client and server, and compare the captures.
> I did that before.  I am not sure what will happen when a client tries
> to send a query and has no ARP entry.  Will the send appear in the tcpdump

Arp is only relevant for traffic on the local net. If a computer has no
arp entry, it will send out a request on the local net asking who has
that IP address. the computer that has it sends back a response saying
it does which contains the mac address of that computer, the local
machine then puts that into its arp tables, and for as long as it is
relevant, then uses that to send directly to the mac address. That
questioning of course takes time. 

> or not.  I'm inclined to think not, because tcpdump has the option to
> display the full header including MAC address and this is not known at
> the time.  So probably tcpdump logs only when ARP has completed.

No. I see "whohas" messsages in my tcp dumps all the time.

> In my trace I saw unanswered queries, so it could be that ARP was not
> the cause.  The tcpdump on the server did not show the corresponding
> incoming queries.

>> When troubleshooting this type of thing, don't forget switches. I've
>> recently encountered so-called 'green' switches that shut down ports with
>> no traffic, and occasionally forget to turn them on again.
> The switch is oldish and probably not affected by this.  Also, the WiFi
> is used by other clients so its port will remain primed.  So is the
> server.  If this problem occurs, it should only affect the wired client.
> The only thing the two clients have in common is that they both are
> a Raspberry Pi.  They run different Linux distributions, different
> kernels, different interfaces (one wired one usb-WiFi).  Ok the NTP
> version is also the same (4.2.6p5).
> And they both are mostly idle.
> Even if there is a sleep mode in the ethernet driver, and it has a
> bug that causes the first packet transmitted from sleep mode to be
> lost (this could be inferred from another reply in the thread), I
> would be surprised if the WiFi would be affected exactly the same way.
> And I am used to wacky performance from WiFi, but not from wired 100Mbit
> ethernet.

More information about the questions mailing list