[ntp:questions] NTP request retry?

Rob nomail at example.com
Wed Jan 29 17:56:04 UTC 2014

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

More information about the questions mailing list