<html>
<head>
</head>
<body class='hmmessage'><div dir='ltr'>
<div dir="ltr">
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style>
<div dir="ltr">Sebastian and Dave, thanks to both of you for your email. I did some more checking on settings in my modem. The max line rate is listed as 7616kbps down and 512 kbps up in the modem setup page. My ISP labels this as 6 MB service. The actual throughput I was getting is 5700kbps and 450 kbps before SQM. <br><br>>>>So you specified5.7 and 0.45?<br>No, at the time I specified 5130 and 400 based on actual download speeds. <br><br>I did some more testing this evening. Based on Dave's comment I upgraded to the latest build 3.10.26. I also adjusted my ingress and egress speeds to 6854 and 460. When I did this my speeds jumped back up to near normal. So..... I think if I understand correctly you should set your speed to approximately 90% of the listed line rate in your modem.<br><br>> > What info do I need to get from my ISP to best optimize my connection?<br>> <br>>
The actual line rates for down- and uplink as well as the full
encapsulation information: DHCP or PPPoE or PPPoA; >VC-MUX or LLC/SNAP;
VLAN or no vlan.<br><br>My ISP does PPPoE (mine is done on the router instead of the modem - I'm in bridged mode) Encapsulation is LLC. I also found out the interleave is set at 64. As I understand it, that has an affect on latency. Anyhow, I think that should cover the most critical info needed. I currently have my per packet overhead set at 44. <br>I'll have to dig in and read some more so I better understand what this setting does. I did take a brief look at the RRUL tool. I'll be teaching myself how to set it up and use it so I can run some more thorough tests this weekend. <br><br>>>(Note it is possible to empirically measure the overhead on your link,
and I would be happy to help you with this, just contact me if
interested).<br><br>Yes, I'd be interested in learning more!<br><br>I think both of your emails have helped to clarify what my settings need to be and more importantly I am better understanding HOW you arrived at the appropriate values and the interplay between them. If I can help with documentation of the SQM setup page on the wiki please let me know.<br><br><br><br><br><div>> From: cerowrt-users-request@lists.bufferbloat.net<br>> Subject: Cerowrt-users Digest, Vol 13, Issue 2<br>> To: cerowrt-users@lists.bufferbloat.net<br>> Date: Thu, 30 Jan 2014 12:00:01 -0800<br>> <br>> Send Cerowrt-users mailing list submissions to<br>> cerowrt-users@lists.bufferbloat.net<br>> <br>> To subscribe or unsubscribe via the World Wide Web, visit<br>> https://lists.bufferbloat.net/listinfo/cerowrt-users<br>> or, via email, send a message with subject or body 'help' to<br>> cerowrt-users-request@lists.bufferbloat.net<br>> <br>> You can reach the person managing the list at<br>> cerowrt-users-owner@lists.bufferbloat.net<br>> <br>> When replying, please edit your Subject line so it is more specific<br>> than "Re: Contents of Cerowrt-users digest..."<br>> <br>> <br>> Today's Topics:<br>> <br>> 1. Re: SQM Setup and Performance (Sebastian Moeller)<br>> <br>> <br>> ----------------------------------------------------------------------<br>> <br>> Message: 1<br>> Date: Thu, 30 Jan 2014 20:29:50 +0100<br>> From: Sebastian Moeller <moeller0@gmx.de><br>> To: Jeremy Tourville <organ_dr@hotmail.com><br>> Cc: "cerowrt-users@lists.bufferbloat.net"<br>> <cerowrt-users@lists.bufferbloat.net><br>> Subject: Re: [Cerowrt-users] SQM Setup and Performance<br>> Message-ID: <646BCC1A-0C7A-46AB-827D-717AEA0A2174@gmx.de><br>> Content-Type: text/plain; charset=iso-8859-1<br>> <br>> Hi Jeremy,<br>> <br>> On Jan 30, 2014, at 18:06 , Jeremy Tourville <organ_dr@hotmail.com> wrote:<br>> <br>> > Hello, I followed your excellent instructions here -<br>> > http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_SQM_for_CeroWrt_310<br>> > <br>> > I am using build 3.10.24-8<br>> > <br>> > I am using a DSL line rated at 6 Mbps down and 512kbps up. My real throughput without SQM enabled is 5.7Mbps down and 450kbps up.<br>> <br>> This looks interesting, the ATM 48 bytes in 53 byte cell encapsulation used in ADSL only leaves 100*48/53 = 90.57% percent of the specified line rate available for your traffic (but that still contains further per packet overhead). So I would assume that the actual liberate is >6.3Mbps? Do you have any chance of verifying the line rate to the DSLAM? Many modems/dsl-routers have offer a web page that gives some statistics and information like the line rate. You will need the line rate as precise as possible if you want to minimize the bandwidth "sacrifice" needed to keep latencies reasonable (if in doubt err on the too small side though).<br>> <br>> > After enabling SQM my throughput has dropped to approximately 4.5Mbps down and 350 kbps up. <br>> <br>> So you specified5.7 and 0.45? Then the link layer adaptation mechanism will try to account for the 48in53 problem and cut down your available rates by ~10% so the best you can expect is ~5.1 and 0.4. If you specified 90% of the measured speed you are already at 5.7 * 0.9 (90% of measured) = 5.13 * 0.9 (fixed ATM overhead) = 4.617 and 450 * 0.9 (90% of measured) = 405 * 0.9 (fixed ATM overhead) = 364.5. So you can not rally expect much more than you got.<br>> <br>> <br>> > Does this seem like an amount that is expected? (within norms?)<br>> > It would seem reasonable that I should expect some performance loss at the expense of better bufferbloat management based on setting 85-95% of actual download/upload speeds. Please correct me if I am wrong. :-)<br>> <br>> Now, my recommendation for ADSL links (well all ATM based links actually) is to start out with the line rate and reduce from there. (The ATM link layer adjustment effectively reduces to 90% of link rate already as explained above)<br>> <br>> <br>> > But my question is, how much is too much? <br>> <br>> So the multistep procedure is roughly as follows. Start with full line rate and no link layer adjustments: measure the ping RTT to the nearest host that responds with no additional traffic; that gives you the best case latency base line of your link. Next load the link with a speed test and run the ping again; that gives you a bad case (for the worst case you need to saturate both up and downlink at the same time, while measuring the ping RTT). Then activate the link layer adjustments with your line rates specified and repeat the test under load; reduce the rates by 5% and repeat. Most likely you will notice that each reduction in bandwidth will also reduce the latency. You then can see the different possible bandwidth/latency trade-offs possible on your link, just pic the one you are most comfortable with.<br>> Then use your link normally, but every now and then, when the link is loaded repeat the ping test and see whether you are still happy, if not adjust the rates.<br>> <br>> <br>> > The setting of SQM does fix the bufferbloat issue as evidenced by ping testing and times for packets. With SQM on all packets were 100ms or less. <br>> <br>> It is interesting to compare this with the ping time to the same host without any load on your network.<br>> <br>> > With SQM off the times jumped to over 500ms or more during the speed testing. <br>> > <br>> > For reference I have set the parameters as indicated in the screenshots. I have changed only two variables and tested after each change as indicated in the grid below.<br>> > <br>> > Que setup script Per packet overhead test results<br>> > Test #1 simple.qos 40 no buffer, less throughput <100ms, 4.5mbps down<br>> > Test #2 simple.qos 44 no buffer, less throughput <100ms, 4.5mbps down<br>> > Test #3 simplest.qos 40 no buffer, less throughput <100ms, 4.5mbps down<br>> > Test #4 simplest.qos 44 no buffer, less throughput <100ms, 4.5mbps down<br>> <br>> simple.qos and simplest.qos should have no real effect on either latency or bandwidth, matching your results. The overhead is a tiny bit trickier, if you underestimate the overhead you can, under certain conditions, still cause buffer bloat in your modem (but these conditions are tricky to recreate, so underestimation will stochastically show up as latency spies every now and then under load), if you overestimate the overhead you sacrifice more bandwidth than necessary (since the overhead is per packet, this bandwidth sacrifice depends on the typical size of packets you send). The idea is to just pick the rift values for your encapsulation and be done with.<br>> My current understanding is that 48 bytes is the worst case overhead, but I have not yet seen a link with that, 44 bytes however are not uncommon, so 44 is not the worst place to start out with. (Note it is possible to empirically measure the overhead on your link, and I would be happy to help you with this, just contact me if interested).<br>> <br>> > <br>> > I also read your statement- <br>> > >>>"The CeroWrt development team has been working to nail down a no-brainer set of instructions for eliminating bufferbloat - the lag/latency that kills voice & video chat, gaming, and overall network responsiveness. The hard part is that optimal configuration of the Smart Queue Management (SQM) link is difficult - there are tons of options an ISP can set. Although CeroWrt can adapt to any of them, it's difficult to find out the exact characteristics of the link you have."<br>> > <br>> > What info do I need to get from my ISP to best optimize my connection?<br>> <br>> The actual line rates for down- and uplink as well as the full encapsulation information: DHCP or PPPoE or PPPoA; VC-MUX or LLC/SNAP; VLAN or no vlan.<br>> <br>> > <br>> > I also recognize that this could be an issue that requires multiple changes at once. <br>> <br>> You are doing fine, all it needs is a few experiments/measurements to find the best values after that you can basically stick to those.<br>> <br>> > I am curious to know from the experts what your thoughts are on this. <br>> <br>> That would be Dave then (all I know about is the atm issues, as I still have an adel link)<br>> <br>> Best Regards<br>> Sebastian<br>> <br>> > Many thanks in advance!<br>> > <br>> > -Jeremy<br>> > _______________________________________________<br>> > Cerowrt-users mailing list<br>> > Cerowrt-users@lists.bufferbloat.net<br>> > https://lists.bufferbloat.net/listinfo/cerowrt-users<br>> <br>> <br>> <br>> ------------------------------<br>> <br>> _______________________________________________<br>> Cerowrt-users mailing list<br>> Cerowrt-users@lists.bufferbloat.net<br>> https://lists.bufferbloat.net/listinfo/cerowrt-users<br>> <br>> <br>> End of Cerowrt-users Digest, Vol 13, Issue 2<br>> ********************************************<br></div></div>
</div>
</div></body>
</html>