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) > Ouch! > 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 ack-every-several-or-many. 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. rick jones -- 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... _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions