On 9/11/2012 15:01, Matt Joyce wrote:
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.
I calculated the overhead of IPv4 NTP packets on an ADSL link somewhat
higher than your estimate:
14 bytes - ethernet header
8 bytes - PPPoE header
20 bytes - IP header
8 bytes - UDP header
48 bytes - NTP data
For a total of 98 bytes, requiring three ATM cells for transport. The
bottom line is 159 bytes are sent across the wire for each NTP packet,
which seems quite inefficient. Of course the calculation is different
if your ISP doesn't use PPPoE.
Frontier has me provisioned at 6944kbit/s down and 1152kbit/s up, so it
presumably takes 179 µs to download an NTP packet vs. 1078 µs to upload one.
My interest here is mostly academic, though if I ever come into
possession of a GPS or WWV receiver I'd like to run a stratum 1 server
for the pool. In that case, would the differing latency be enough to
send bad time to my clients? I've been told it cancels out for WAN
clients when you run a stratum 2 server, but not for a stratum 1 server
on an asymmetrical link.
_______________________________________________
pool mailing list
[email protected]
http://lists.ntp.org/listinfo/pool
