While hopefully someone else will get back to you shortly with a more
definite answer, I strongly suspect that the transmission delay of the
NTP packets themselves would be too minimal to make much difference.
Usually around 76 bytes with ethernet overhead included, transmission
over the DSL link would be a little more as that adds on ATM overhead
also, in this case an additional 10 bytes (ATM uses cells of 53 bytes in
size of which 48 bytes is payload 5 bytes is header so a 76 byte NTP
packet is fragmented in 2). 6Mbps is 750,000 bytes/s so 86 bytes
transmits in around 115µs and at 1Mbps that time is closer to 688µs. So
a difference of about half a milisecond.
To make a difference that might be noticeable I think you would need to
see at least some queing on Ethernet, there you have a good chance that
your NTP packet is going to be stuck waiting on a 1500byte full data
packet where even just one of them is several miliseconds to transmit
the choke point is usually the ATM device though as the ethernet link is
the faster link. Perhaps with some cheaper embedded devices with
limited memory for buffer space might cause the ques to be transferred
to the other end of the ethernet link.
Perhaps someone could say for sure though I am just going on the basis
of what my instinct tells me on this one so would be interesting to see
if someone has tried it and got different results.
Also, there is another case where it may happen that something like this
would be beneficial that might make a noticeable difference would be if
the paths through the telecoms operators network between the end user
DSL modem and the ISP providers first hop can be quite asymmetrical can
be quite common as the telecoms operators try to maximize utilization of
such as GigE or 10GigE backhauls when the majority of the data flows are
asymmetrical and thus more usual routing would end up requiring more
total capacity and thus costs. Confirming if this sort of effect exists
can be done by two machines with highly accurate clocks passing and
comparing timestamps. Quantifying this effect to any degree is a whole
different story short of having direct access to your providers DSL
gateway or to a large enough number of synchronized nodes around the net
to work it out statistically.
On 10/09/12 21:57, [email protected] wrote:
Hello All,
I upgraded one of my servers to the development version (4.2.7p304),
mainly so I could play with the new monitoring mechanism. While
messing around with the new config I came across the huffpuff feature
and I'm looking for more information about it.
From what I've read so far I gather that huffpuff is primarily
intended to address differing queuing delays caused by large
downloads/uploads. That shouldn't be much of an issue for my server, I
have QoS on the upstream with ntp packets prioritized, while the
downstream is rarely congested for any significant length of time.
However, this server IS on an asymmetrical ADSL connection, 6mbit/s
down and 1mbit/s up. Does huffpuff do anything to improve accuracy on
such a connection when both sides are idle, or is it exclusively
intended to maintain accuracy when dealing with queuing delays caused
by traffic congestion on one side of the length?
Tim
_______________________________________________
pool mailing list
[email protected]
http://lists.ntp.org/listinfo/pool
_______________________________________________
pool mailing list
[email protected]
http://lists.ntp.org/listinfo/pool
