[ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.
rick.jones2 at hp.com
Mon Mar 19 18:15:11 UTC 2012
Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:
> unruh wrote:
> > And it sounds like you have assymetric delays. Note that most ISPs
> > deliver very different rates for up vs down, and that may well
> > come with assymetric delays. (eg 600Kb/s, vs 30Mb/s for my cable
> > access)
> That is 1:50 which means that you must be very lucky indeed to ever get
> those 30 Mbit down:
> The most efficient protocol for bulk transfers is still FTP, if you
> get zero packet drops FTP can run with one ACK packet (about 64
> bytes) for every pair of received data packets (2x1514 max).
> The ratio between those two numbers is just over 1:50, so in order
> to ever get nearly the full 30 Mbit down, you must have perfect
> saturation of the uplink just to send the ACK packets, and any
> background traffic, even something as simple as NTP of email polling
> will interfere.
> You should never accept much more than 10:1 speed difference between
> down and up.
I will agree with that, but will also point-out there are some stacks
with explicit ACK avoidance heuristics (Solaris and HP-UX), and that
Large Receive Offload/GRO in Linux will cause what I believe are
called "stretch ACKs" that take one beyond ack-every-other to
With the prevalence of timestamps being enabled in TCP, I think a TCP
over "Ethernet" will be larger than the minimum frame size - 32 bytes
of TCP header (12 bytes of timestamp, not sure about
padding/alignment), 20 bytes of IPv4 header, and 14 bytes of ethernet
header, for a total of 66 bytes. Make that IPv6 and add another 20
bytes to arrive at 86, IIRC.
The glass is neither half-empty nor half-full. The glass has a leak.
The real question is "Can it be patched?"
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
More information about the questions