Hello Derek, Thanks for trying SQM.
On Dec 28, 2014, at 03:29 , Derek & Vicky <[email protected]> wrote: > I've installed and configured the SQM QOS module for my Bleeding Edge, r43718 > access point. The access point runs on the sunxi A20 processor with 1 > Ethernet and 1 USB powered Wifi adapter. A 5 port switch with VLAN 802.1q > support is connected to the 1 Ethernet port to give the access point extra > wired network ports. > > I was looking for configuration documentation for this module that would > guide the basic configuration options. So for the basic setup http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_SQM_for_CeroWrt_310 should be interesting. This was written for cerowrt, but with the exception of the interface names this should also apply to openwrt. It should explain some of the options a bit better. > The module has advanced options too, but I assume that they are for specific > setups to get the extra bit of performance. The idea/hope for SQM scripts was to get a default that works for everybody; I am not sure whether we fully reached that goal. > Particular documentation for what interface to enable the SQM QOS for? (Wifi? > Ethernet connected to the WAN?) Will this still work if the broadband > provider equipment is not in bridge mode? So, SQM scripts can be configured on multiple interfaces concurrently, so it depends on your specific topology; in general one would configure & active SQM for the interface connected to the upstream (typically the ISP). Bridged or not bridged should not make a big difference, though I have not tested that myself (cerowrt routes all interfaces instead of bridging them). But most people configure SQM for their internet access on the WAN port of the “first” router (better the router that feeds all other network nodes). Now as far as I can tell even openwrt does not bridge the “WAN” port with the rest. > > > Lastly for the Download speeds and Upload speeds what is the recommended way > to calculate the values to enter? 90% of DSL connection speed? Or 95% of > real observed/tested speeds(like tested with iperf)? That depends on how much time you want to invest here, many people are quite happy with setting the uplink/egress to 95% of the line rate and downlink/ingress to 90% of line rate; but you should definitively measure the effect of the selected shaping rates on the latency under load: https://www.bufferbloat.net/projects/cerowrt/wiki/Quick_Test_for_Bufferbloat has some pointers on how to measure this, personally I would recommend the netperf-wrapper suite (which also works great with internal nerserver instances). NOTE on a ADSL link you really should fill out the “Link Layer Adaptation” tab with the proper values (select ATM for “Which link layer to account for:"). (The wist case for the overhead in theory seems to be 48 bytes and in real life 44 bytes). If you are unsure whether your link runs ATM let me know I have a quite time consuming method to detect ATM framing (and overhead) if you can not get the relevant information from your ISP. The link layer adjustments are critical for ATM-based links as the link rates the modem reports are net rates and ATM drags in a lot of overhead (partly depending on the size of the current packet) that will need to fit into the net rate (ATM's 48 in 53 encapsulation alone eats up ~9% of the net link rates), so if you you do not use the link layer adjustments starting values are 85% and 80% of link rates. If you have enough time the bet approach is then to measure the performance of your link under load, for netperf-wrapper I use: date ; ping -c 10 netperf-eu.bufferbloat.net ; ./netperf-wrapper --ipv4 -l 300 -H netperf-eu.bufferbloat.net rrul -p all_scaled --disable-log -t your_fancy_name_for_plots_and_files_replace_this And then I use “netperf-wrapper —gui” to look at the results (the icmp_cdf, ping_cdf, all_scaled, and box_totals plots are quite helpful in my experience). > > My initial test results indicate that the QOS does work, not sure how well. > My test case was a huge upload over about 4 hours, most likely over https. > The DSL upload speed is 1Mbps, download 9Mbps. Ah, for that upload speed it should help to set “Latency target for egress, e.g. 5ms [units: s, ms, or us]; leave empty for default, or auto for automatic selection.” to “auto” in the “Show Dangerous Configuration” subsection of the “Show Advanced Configuration” subsection of the "Queue Discipline” tab. Rationale: fq_codel typically considers a flow not “congested” if in an interval of 100ms no packet is longer held in the queue than 5ms (called target) but at speeds < 3 Mbps a single packet takes longer than 5ms and hence fq_codel will keep dropping packets from flows even though they are not really experiencing congestion but just a slow link ;). “Auto” will basically look at the configured shaped rate and set target to allow one packet to clear the queue. > First test case - QOS disabled. Other devices were unable to connect > websites or pickup pop mail. Server not found and server not available > messages. > Second - QOS enabled on WAN port egress speed set at 700kbps - Other devices > were able to connect with out issue. Network traffic monitoring shows that > the upload was being limited to 700 kbps. > Third test - QOS enabled on WAN port with egress speed set at 850kbps - Other > devices were able to connect most of the time, but periodically they would > receive a Server not found and server not available message. Over all this sounds pretty much as expected for a quick and dirty test. > > Is this the best way to configure the SQM module? These results expected? I would recommend setting up netperf-wrapper and use test durations of at least a minute (I prefer at least 5 minutes/300seconds) with methodologicaly changing the shaping parameters; start from something conservative, say 80% and then increase the rates step by step while looking the the results from netperf-wrappers RRUL test. RRUL will try to saturate uplink and downlink (with 4 TCP flows each) while also testing the effect on the latency of unrelated ICMP and UDP “ping” probes; ideally the average ping time only increases by the sum of ingress and egress target (so 10ms for the default, and probably around 20ms for your link). Just to recap, SQM scripts has a much better grip on latencies in its queueing than typical enduser equipment and CPE, so the goal is to make sure the bottleneck of your internet connection is not between DSLAM/MSAN/BRAS and modem, but between the commuter running SQM scripts and the rest of your internal network. To make that happen the shaped rates need to be configured such that (on average) there is no queue developing upstream of the SQM-router. For egress that is relatively simple and with proper link layer adjustments I was able to set the egress shaping rate to 99% (and even 100%) of the uplink link rate as reported by my DSL modem. For ingress it gets a bit murkier as you have less control about what gets send your way from the outside (especially when you run a server or under a D/DOS attack) so typically people set the ingress shaping a bit lower to 85 to 90%, but please test your link properly ;) Please let me know whether this clear things up for you and do not hesitate to ask further question… Best Regards Sebastian > > Thanks > Derek > _______________________________________________ > openwrt-devel mailing list > [email protected] > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
