David Woolley wrote:
> E-Mail Sent to this address will be added to the BlackLists wrote:
>
>>
>> I can perhaps see idling the connection to keep it open when the
>> poll rate is at ~ 1 minute, however what about when the poll
>> rate decreases to ~ 17 minutes? (or less often if so configured)
>
Danny Mayer wrote:
How many connections do you think it takes to overwelm a server? Even on
an idle connection TCP normally requires at least a minute of timeout
If you enable keep alives, the default timeout is several hours. If you
don't enable keepalives, there is no idle traffic at all.
E-Mail Sent to this address will be added to the BlackLists wrote:
> David Woolley wrote:
>> Danny Mayer wrote:
>>> More importantly, TCP requires a 3-way handshake
>>> before it can deliver the packet, so there is setup
>>> time, delivery and tear-down time involved as well
>>> just to deliver
Rob wrote:
It would be very unwise to use TCP for something like NTP.
Information sent by an application via a TCP socket will be re-sent by
Agreed, but the thread had gone off topic.
___
questions mailing list
questions@lists.ntp.org
http://lists.
David Woolley wrote:
> E-Mail Sent to this address will be added to the BlackLists wrote:
>
>>
>> I can perhaps see idling the connection to keep it open when the
>> poll rate is at ~ 1 minute, however what about when the poll
>> rate decreases to ~ 17 minutes? (or less often if so configured)
E-Mail Sent to this address will be added to the BlackLists wrote:
I can perhaps see idling the connection to keep it open when the
poll rate is at ~ 1 minute, however what about when the poll
rate decreases to ~ 17 minutes? (or less often if so configured)
There are no network cost in keep
David Woolley wrote:
> Danny Mayer wrote:
>> More importantly, TCP requires a 3-way handshake
>> before it can deliver the packet, so there is setup
>> time, delivery and tear-down time involved as well
>> just to deliver one small packet.
>
> One wouldn't set up a TCP connection for each messag
David Mills wrote:
Not true. The dispersion does increase, but the server is valid until
the dispersion exceeds the select threshold, usually in four or five
more missed messages.
That's why I said the quality measures are invalidated, rather than the
server is invalidated. I probably shou
Danny Mayer wrote:
More importantly, TCP requires a 3-way handshake before it can deliver
the packet, so there is setup time, delivery and tear-down time involved
as well just to deliver one small packet.
One wouldn't set up a TCP connection for each message!
Rick Jones wrote:
> David Woolley wrote:
>> For a start, if it dropped a source on the first missing reply it
>> would result in clock hopping, which is undesirable. UDP is
>> unrliable, and you cannot rely on getting every query returned.
>
> In that sense then, even TCP is unreliable for it ca
David,
Not true. The dispersion does increase, but the server is valid until
the dispersion exceeds the select threshold, usually in four or five
more missed messages.
Dave
David Woolley wrote:
David Woolley wrote:
Looking at the, slightly out of date, 4.2.4p4, a reachability of 1/8
is
David Woolley wrote:
Looking at the, slightly out of date, 4.2.4p4, a reachability of 1/8 is
still acceptable. Rejection during startup will be based on a high
On a further look, it looks like the source's quality measures are
invalidated after three consecutive missed replies.
E-Mail Sent to this address will be added to the BlackLists wrote:
On 1/11/2010 2:24 PM, David Woolley wrote:
BlackLists wrote:
I see nothing "wrong" with having several, {I've done it}
as long as it is understood that are always included in
the combining algorithm and don't get discarded. A
On 2010-01-11, Michael Moroney wrote:
> Can anyone point me to anything similar to "How to explain NTP to Project
> Managers" esp. explaining how a preferred clock server is included even
> though the LAN cable is known to be dangling from the rack. Most of which
> I find with Google is too techn
On 1/11/2010 2:24 PM, David Woolley wrote:
> BlackLists wrote:
>> I see nothing "wrong" with having several, {I've done it}
>> as long as it is understood that are always included in
>> the combining algorithm and don't get discarded. AFAICT
>
> Nothing is guaranteed when you go outside the spec
David Woolley wrote:
> For a start, if it dropped a source on the first missing reply it
> would result in clock hopping, which is undesirable. UDP is
> unrliable, and you cannot rely on getting every query returned.
In that sense then, even TCP is unreliable for it cannot guarantee
getting ever
Michael Moroney wrote:
Can anyone point me to anything similar to "How to explain NTP to Project
Managers" esp. explaining how a preferred clock server is included even
Unfortunately its primary author fancies himself as a mathematician, so
the main documentation is a mathematical treatise. H
I see nothing "wrong" with having several, {I've done it}
as long as it is understood that are always included in
the combining algorithm and don't get discarded. AFAICT
At least in 4.2.4p4, they are never included in the combining algorithm.
If one ignores some complications due to loc
Can anyone point me to anything similar to "How to explain NTP to Project
Managers" esp. explaining how a preferred clock server is included even
though the LAN cable is known to be dangling from the rack. Most of which
I find with Google is too technical. This is confusing to me as well,
with th
E-Mail Sent to this address will be added to the BlackLists wrote:
I see nothing "wrong" with having several, {I've done it}
as long as it is understood that are always included in
the combining algorithm and don't get discarded. AFAICT
Nothing is guaranteed when you go outside the specif
On 1/9/2010 1:24 AM, David Woolley wrote:
> Michael Moroney wrote:
>> server 10.136.3.70 prefer
>> server 10.136.3.71 prefer
>
> You are only supposed ot have, at most, one prefer source.
>> server 10.98.63.50
>> server 10.98.63.150
(Shrug)
I see nothing "wrong" with having several, {I've done it
Michael Moroney wrote:
that synchronizes with the four clocks, and ntpq> peers shows one of the
primaries with a "*" in the first column meaning it was synchronized to as
time source, the other 3 show "+" as expected, meaning they are usable
sources. We disconnect the antenna of the selected cl
Michael Moroney wrote:
David Woolley writes:
If it remains the best choice it could take up to 8192 seconds before
all the samples are flushed from the FIFO and it becomes completely
ineligible. There is logic to discourage early switching, as clock
hopping is, itself, considered a bad thi
David Woolley wrote:
OK. This is why this configuration is NOT simple! My original
comments, and my reply to Michael, are based on not using prefer. You
Sorry, reply to Richard.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp
E-Mail Sent to this address will be added to the BlackLists wrote:
However, if a prefer peer is among the survivors, the combining
algorithm is not used. Instead, the offset of the prefer peer
is used exclusively as the final synchronization source."
OK. This is why this configu
Richard B. Gilbert wrote:
Michael Moroney wrote:
David Woolley writes:
Michael Moroney wrote:
that synchronizes with the four clocks, and ntpq> peers shows one of
the
primaries with a "*" in the first column meaning it was synchronized
to as
time source, the other 3 show "+" as expected,
Michael Moroney wrote:
Very simple.
driftfile SYS$SPECIFIC:[TCPIP$NTP]TCPIP$NTP.DRIFT
server 10.136.3.70 prefer
server 10.136.3.71 prefer
That's not simple. You are only supposed ot have, at most, one prefer
source.
server 10.98.63.50
server 10.98.63.150
__
On 1/8/2010 6:34 PM, Michael Moroney wrote:
> BlackLists writes:
>> I suspect you will have to supply your .conf file,
>> or otherwise explain your minclock minsane prefer, ...
>> settings, if you want many useful answers.
>
> Very simple.
>
> driftfile SYS$SPECIFIC:[TCPIP$NTP]TCPIP$NTP.DRIFT
>
> s
On 2010-01-09, Michael Moroney wrote:
> David Woolley writes:
>
>>Michael Moroney wrote:
>
>>> that synchronizes with the four clocks, and ntpq> peers shows one of the
>>> primaries with a "*" in the first column meaning it was synchronized to as
>>> time source, the other 3 show "+" as expected,
Hello Richard ,
On Fri, 8 Jan 2010, Richard B. Gilbert wrote:
Michael Moroney wrote:
David Woolley writes:
Michael Moroney wrote:
that synchronizes with the four clocks, and ntpq> peers shows one of the
primaries with a "*" in the first column meaning it was synchronized to
as
t
Michael Moroney wrote:
David Woolley writes:
Michael Moroney wrote:
that synchronizes with the four clocks, and ntpq> peers shows one of the
primaries with a "*" in the first column meaning it was synchronized to as
time source, the other 3 show "+" as expected, meaning they are usable
sour
David Woolley writes:
>Michael Moroney wrote:
>> that synchronizes with the four clocks, and ntpq> peers shows one of the
>> primaries with a "*" in the first column meaning it was synchronized to as
>> time source, the other 3 show "+" as expected, meaning they are usable
>> sources. We discon
E-Mail Sent to this address will be added to the BlackLists
writes:
>I suspect you will have to supply your .conf file,
> or otherwise explain your minclock minsane prefer, ...
> settings, if you want many useful answers.
Very simple.
driftfile SYS$SPECIFIC:[TCPIP$NTP]TCPIP$NTP.DRIFT
server 1
On 1/8/2010 12:45 PM, Michael Moroney wrote:
> Now the question: For the next test, we disconnect the
> LAN cable of the selected primary clock, and we expect
> the next poll to fail and the client to give up on it
> and to select the other primary clock.
> No, we just see the time from the
34 matches
Mail list logo
