Andre Guibert de Bruet wrote this message on Fri, Jun 10, 2005 at 09:03 -0400: > >I've tried everything from forcing full-duplex media, to tweaking any any > >every > >suggested tcp setting I could get at, none have an impact on the limit. > >I'll > >leave > >those details out for now in the interest of not too long an email. > > > >Right now I'd be happy enough with RTFM and/or someone else who at least > >recognizes the problem. > > Interesting problem. This report however, does not belong on this list > (stable_at_ or net_at_ might be more appropriate ones). May I suggest doing > performance testing without any of the NAT/firewall rules in place? The > asym nature of your DSL loop doesn't matter unless you are saturating your > link both ways; downloads only go as fast as packets can get ACK'ed. > > I would be willing to elaborate off list. I finally decided to write a d/l limiter. It uses a divert sockets to catch the ack's and then delay the ack's till it believes there is enough room in the downstream pipe for it.. Of course, with variable latency of the connections, you won't always get a nice steady stream of incoming packets... They are a couple of python scripts and require's dsong's dpkt: http://resnet.uoregon.edu/~gurney_j/jmpc/python/acklimit.py http://resnet.uoregon.edu/~gurney_j/jmpc/python/divert.py It doesn't have the smartest queuing system, just a standard FIFO. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."Received on Fri Jun 10 2005 - 16:20:18 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:36 UTC