Hi William,

On Jul 30, 2012, at 11:34 AM, William Katsak wrote:

> Hello,
> 
> I am playing with a CeroWRT (3.3.8-6) router on my vacation in Russia and am
> seeing some weird behavior with simple_qos.sh that I am unsure if I
> should attribute to a
> bug, or to an Internet connection that is "just that bad".
> 
> Background:
> - The router is on my wife's parents' ADSL line (according to the modem,
> ~3000/500). The modem is a D-Link DSL-2500U.
> 
> - Even though the link is 3000/500, and I can get speedtest.net to
> report 2.5mbps/0.42mbps on a clean connection (direct or Cero with no
> QOS on), as soon as I use a host that is outside of Rostelecom (local
> service), it drops to 0.9/0.4mbps. This is consistent with Netalyzr
> test: Upload 430 Kbit/sec, Download 970 Kbit/sec. This suggests that
> even though the DSL link is higher bitrate, the ISP doesn't have the
> outgoing bandwidth or is rate-limiting it somehow.
> 
> - I don't necessarily intend to leave the router running Cero here,
> but I want to get a handle on the latency situation, as it makes Skype
> pretty messy...I am hoping to roll what I learn into a more stable
> build of OpenWRT.
> 
> I have tried several different configurations of the modem including:
> 1) Default: Modem does PPPoE and hands out 192.168.1.xxx addresses. I
> tried just letting Cero route through that address.
> 2) PPP-IP extension: This has the effect of the modem handling the
> PPPoE connection and handing out the single "real" IP address over
> DHCP. In this case Cero would see the Internet IP on ge00.
> 3) Bridging: Allow Cero to establish the PPPoE connection and manage it.
> 
> Right now I am in PPP-IP extension mode on the modem, and GUI QOS on
> the router. This seems to be reliable and also keeps the latency down,
> although I would imagine that PPPoE on the router and the GUI QOS
> would be fine too, but obviously I would rather use simple_qos.
> 
> The problem:
> 
> When I try simple_qos.sh, I see this:
> 
> insmod: can't insert 'cls_fw': File exists
> insmod: can't insert 'sch_htb': File exists
> RTNETLINK answers: No such file or directory
> RTNETLINK answers: No such file or directory
> 
> If I run it again, the RTNETLINK errors go away...I assume this is
> just an annoyance.
> 
> This gives me super stable ping times, etc. but a lot of websites hang
> loading, and the connection is unusable. If I reboot the router, the
> connection works fine again, although the high latency comes back.
> 
> So, with all that out there, I have some questions with simple_qos:
> 
> 1) If I am using PPPoE on the router, do I need to do IFACE=pppoe-ge00
> or still just ge00?
> 2) Should I set PPOE to "yes"?

        Since your DSL connection is running PPPOE you should set PPOE to yes 
in any case IF your DSL connection uses ATM as link layer (most probable). This 
will just make sure that the shaper calculus the right packet seizes to account 
against your link rates.  But check against 
http://ace-host.stuart.id.au/russell/files/tc/tc-atm/ to figure out the prier 
value for overhead, as that depends on the specifics of your DSL connection. I 
found that http://www.linuxhowtos.org/manpages/8/tc-stab.htm also is quite 
interesting to read to better understand the overhead parameter. But 
unfortunately simple_qos does not (yet) use the generic tc-stab method but the 
atm link layer adjustments specific for HTB. (Since I am on cable right now I 
have no way of testing whether the tc-stab method also works with HTB). 
Especially for small packets (like VoIP) if you do not account for the the fact 
that ATM always sends out integer 48byte cells and will pad if necessary, you 
will cause severe queueing 
 way below reaching the nominal link rate, as the shaper does not account for 
a) the padding nor b) the 5byte ATM overhead per ATM-cell (at least I think 
that is the case).
        You should do this in any case so that shaping actually has a chance to 
work reliably and repeatably independent on the size distribution of your 
shaped packages.

> 3) Is it possible that no matter what I do, the buffers at the speed
> drop between Rostelecom and their bandwidth provider is hurting me
> somehow?

        If I understand correctly, yes this is going to hurt you, so if your 
intended VoIP traffic leaves the Rostelecom net you might need to specify 
974/430 for the shaped rates instead of 3000/512. But that sounds like 
something that is easy to test. Since your achievable uplink (430) is still 
quite close to your link rate (500) I would still recommend to look at getting 
link layer and overhead specified correctly in simple_qos.

> 4) If 3, what to do other than yell at them?

        As an emergency stop-gap measure shape your rates to what the network 
path you are most interested in can deliver? That said I, isn't that what codel 
is supposed to do automatically???

> 
> Overall, is anyone using Cero with a PPPoE connection with good
> results? What kind of configuration do you have?

        No, but I used cerowrt with a bridged ATM-based DSL connection in the 
past which shares most of the issues with PPPOE over ATM. BTW stock openwork 
does not account properly for ATM either so if you switch to openwork you will 
need to edit some of the QOS scripts to work well with DSL. (Last time I looked 
the "calculate overhead" checkbox did something statistic I failed to fully 
understand).

> 
> Sorry for the info dump, but if there is indeed a problem going on
> with PPPoE connections, I am more than willing to be a guinea pig
> until August 10th. I would appreciate any ideas!


        Oh, by the way I have some half done octave program to figure out the 
actual overhead from a ping sweep, let me know if you are interested...

Best Regards
        Sebastian

> 
> Thanks!
> 
> -Bill Katsak
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Reply via email to