Hi, I''ve written a small javascript ADSL throughput calculator: http://nukunuku.yamamaya.is-a-geek.org/~ranma/adsl.html Feel free to submit alternative presets (I currently have presets for three german telecom speed variants: T-DSL (1000|2000|3000), derived from http://www2.lancom.de/kb.nsf/5d445c701b3ff52dc1256e7700297e5c/27c6ee1c3e3f74b0c1256e94004a433e?OpenDocument). Comments, suggestions, spelling nitpicks? -- Tobias PGP: http://9ac7e0bc.uguu.de
Tobias Diedrich wrote:> Hi, > > I''ve written a small javascript ADSL throughput calculator: > http://nukunuku.yamamaya.is-a-geek.org/~ranma/adsl.html > > Feel free to submit alternative presets (I currently have presets > for three german telecom speed variants: T-DSL (1000|2000|3000), > derived from > http://www2.lancom.de/kb.nsf/5d445c701b3ff52dc1256e7700297e5c/27c6ee1c3e3f74b0c1256e94004a433e?OpenDocument). > > Comments, suggestions, spelling nitpicks? >Looks good - one picky point - if your overhead means only 4 bytes padding at default mtu are needed, then reducing mtu to be "optimal" for IP and above levels may be less efficient from the point of view of the tcp data because of the reduced payload vs fixed overheads. I haven''t done the maths on that :-) Andy.
Andy Furniss wrote:> Tobias Diedrich wrote: > >> Hi, >> >> I''ve written a small javascript ADSL throughput calculator: >> http://nukunuku.yamamaya.is-a-geek.org/~ranma/adsl.html >> >> Feel free to submit alternative presets (I currently have presets >> for three german telecom speed variants: T-DSL (1000|2000|3000), >> derived from >> http://www2.lancom.de/kb.nsf/5d445c701b3ff52dc1256e7700297e5c/27c6ee1c3e3f74b0c1256e94004a433e?OpenDocument). >> >> >> Comments, suggestions, spelling nitpicks? >> > > Looks good - one picky point - if your overhead means only 4 bytes > padding at default mtu are needed, then reducing mtu to be "optimal" for > IP and above levels may be less efficient from the point of view of the > tcp data because of the reduced payload vs fixed overheads. > > I haven''t done the maths on that :-)Which I should have done first :-) If timestamps are off it''s still about 1 1/3 bytes per frame more efficient. If they are on (default on linux costing 12 bytes) the smaller mtu is about 1 byte per frame less efficient. Andy.
At Wed, 15 Jun 2005 00:02:32 +0200, Tobias Diedrich wrote: Hi> Comments, suggestions, spelling nitpicks?Maybe http://www.adsl-optimizer.dk/thesis/ http://www.adsl-optimizer.dk/thesis/main_final.ps chapter 5, will give you extra information. --- Yours Per Marker Mortensen <per@markermortensen.dk>
Per Marker Mortensen wrote:> http://www.adsl-optimizer.dk/thesis/ > http://www.adsl-optimizer.dk/thesis/main_final.ps > > chapter 5, will give you extra information.Hmm, I still haven''t read all of it, but I''d like to make two comments. 1) I don''t think the kernel patch is needed as you can fold that information into the rate table AFAICS (See the patch at the end of this mail). Then again, depending on the overhead value you''d of course have a slight inaccuracy (in case the overhead is not divisible by 2^cell_log). Thus in my patch I just assume the worst. 2) AFAICS you only looked at upstream shaping, right? At least from my experience I can say that for my ADSL link (3456kbit down / 448kbit up raw ATM speed, shared by 5 users) it is quite easy to saturate the downstream with a bittorrent download. So some sort of downstream shaping is needed too. Unfortunately the IMQ patch seems to panic the kernel when it starts dropping packets. I am currently using a shellscript which monitors the downstream traffic and starts lowering the upstream bandwidth limit when downstream usage is above a threshold, which for now has stopped the complaints from the two World of Warcraft gamers. :-) Patch to iproute2 attached (it compiles, otherwise untested [1]). [1] And because I need a side-effect of my slightly older patch to the kernel currently running on the router I don''t think it will get testing from me for now... :-/ -- Tobias PGP: http://9ac7e0bc.uguu.de _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
At Fri, 17 Jun 2005 03:11:35 +0200, Tobias Diedrich wrote: Hi> 1) > I don''t think the kernel patch is needed as you can fold that > information into the rate table AFAICS (See the patch at the end > of this mail). Then again, depending on the overhead value you''d > of course have a slight inaccuracy (in case the overhead is not > divisible by 2^cell_log). Thus in my patch I just assume the > worst.I do not remember the details (is my office mate''s thesis and not mine), but from what I remember it will actually more than slightly inaccurate. The thing is that the rate table is off-by-one with respect to 2^cell_log - see section 6.1.2 of the thesis. If you use the patch in the thesis, the calculations will be 100% accurate.> 2) > AFAICS you only looked at upstream shaping, right?Its the focus of my office mates thesis, but there is also a chapter that looks at posible downstream problems.> At least from my experience I can say that for my ADSL link > (3456kbit down / 448kbit up raw ATM speed, shared by 5 users) > it is quite easy to saturate the downstream with a bittorrent > download. So some sort of downstream shaping is needed too.From what I have seen in different places it is actually normally not a problem. But 4/8Mbps/768kbps ADSL''s are also very common here i DK. The problem always seem the be the upstream capacity and the extreme usage P2P programs.> Unfortunately the IMQ patch seems to panic the kernel when it > starts dropping packets. I am currently using a shellscriptThere is actually no need to use IMQ, or there are at least other ways. Several places I have just setup the queue disciplines on the interface towards the LAN. If you need communication between the LAN and the router, you can make a special HTB leaf for that, and map packages with iptables. --- Yours Per Marker Mortensen <per@markermortensen.dk>
Tobias Diedrich wrote:> Per Marker Mortensen wrote: > > >>http://www.adsl-optimizer.dk/thesis/ >>http://www.adsl-optimizer.dk/thesis/main_final.ps >> >>chapter 5, will give you extra information. > > > Hmm, I still haven''t read all of it, but I''d like to make two > comments. > > 1) > I don''t think the kernel patch is needed as you can fold that > information into the rate table AFAICS (See the patch at the end > of this mail). Then again, depending on the overhead value you''d > of course have a slight inaccuracy (in case the overhead is not > divisible by 2^cell_log). Thus in my patch I just assume the > worst.You end up either being a cell too safe around the optimal sizes even if, like you, your overhead is divisible by cell log. So you either have to undo your tweaking or underaccount for some packet sizes. It''s still better than doing nothing if you really can''t change your kernel - Ed Wildgoose posted a similar patch some time ago.> > 2) > AFAICS you only looked at upstream shaping, right? > At least from my experience I can say that for my ADSL link > (3456kbit down / 448kbit up raw ATM speed, shared by 5 users) > it is quite easy to saturate the downstream with a bittorrent > download. So some sort of downstream shaping is needed too. > Unfortunately the IMQ patch seems to panic the kernel when it > starts dropping packets.If imq is unstable on your kernel you could try shaping download on egress / use a modified dummy device or use a policer on ingress. Bittorrent is harder to shape than most things. Andy.
> > Bittorrent is harder to shape than most things.I think the issue is lots of connections all going into fast start? I liked Andy''s idea of having a seperate queue for the first few Kbytes of new connections and pegging it with a VERY short queue length. This means that connections in fast start will get a packet drop very early on unless they play very nicely I guess one could do something like making it the very lowest priority class in a standard HTB setup with near zero guaranteed rate and then it would be self throttling, the first few connections can come in, mop up all the bandwidth, and new connections after that get packet loss very early on (because they only get the leftovers), forcing them to slow down much more quickly. Once they have transferred some small amount of data they fall back into your normal traffic shaping queues and everything proceeds as normal. I guess for an even better approach, only do this nasty trick on your "bulk" incoming connections... If anyone gives this a serious test then please do report back with your findings Ed W
Ed W wrote:>> >> Bittorrent is harder to shape than most things. > > I think the issue is lots of connections all going into fast start? > > I liked Andy''s idea of having a seperate queue for the first few Kbytes > of new connections and pegging it with a VERY short queue length. This > means that connections in fast start will get a packet drop very early > on unless they play very nicelyGetting new connections out of slow start like this helps my ingress shaping for browsing - not bittorrent, though, it cycles through existing connections doing tit for tat, speculative and when new chuncks are available so they go in and out of slow start after they have passed data already. See the last few paragraphs of the protocol for the choking rule. http://www.bittorrent.com/protocol.html Andy.