Hal Murray :
>
> > # Requests are automatically retried once, so total timeout with no
> > # response is a bit over 2 * DEFTIMEOUT, or 10 seconds.
>
> Thanks. That sounds reasonable, but I can't translate that into what I'm
> seeing.
>
> Did you check the code? Does it bail on the second tim
> # Requests are automatically retried once, so total timeout with no
> # response is a bit over 2 * DEFTIMEOUT, or 10 seconds.
Thanks. That sounds reasonable, but I can't translate that into what I'm
seeing.
Did you check the code? Does it bail on the second timeout? Is there an
extra re
Hal Murray via devel :
>
> Anybody familiar with the retransmission code?
I think I'm the only person who has touched it.
> It seems to hang occasionally. A wild guess, there is some backoff code in
> there that increases the retransmission timer. That's good. I'm guessing
> that my problem
Hal Murray :
> This is from a day or so ago.
>
> [murray@second ~]$ ntpq -d 4 -nc mru
> ntpq can only work interactively on one host.
> Traceback (most recent call last):
> File "/usr/local/bin/ntpq", line 1635, in
> session.openhost(*interpreter.chosts[0])
> File "/usr/local/lib/python2.
Hal Murray :
> The current peers command is broken. It's printing a big bunch of blanks
> instead of the host name for each slot. It way overflows an 80 character
> line.
Well, that was a symphony of stupid. On my part.
Here's what happened. I fixed the kludgy way I had implemented termsize
Hal Murray :
> The mru list is getting printed out oldest first. I thought you fixed that.
I thought I did too. Testing...
esr@snark:~/software/ntp-rescue/ntpsec$ ntpq -c mru
Ctrl-C will stop MRU retrieval and display partial results.
Retrieved 12 unique MRU entries and 0 updates.
lstint avgint