<p dir="ltr"><br>
On May 6, 2013 12:46 PM, "Fred Stratton" <fredstratton@imap.cc> wrote:<br>
><br>
><br>
><br>
> Begin forwarded message:<br>
><br>
>> From: Fred Stratton <fredstratton@imap.cc><br>
>> Subject: Re: [Cerowrt-users] dnsmasq lease renewal and other issues with Berlin current<br>
>> Date: 6 May 2013 17:39:01 BST<br>
>> To: "<a href="mailto:cerowrt-users-request@lists.bufferbloat.net">cerowrt-users-request@lists.bufferbloat.net</a>" <<a href="mailto:cerowrt-users-request@lists.bufferbloat.net">cerowrt-users-request@lists.bufferbloat.net</a>><br>
>><br>
>><br>
>> On 6 May 2013, at 16:46, Dave Taht <<a href="mailto:dave.taht@gmail.com">dave.taht@gmail.com</a>> wrote:<br>
>><br>
>>> The wiki is editable with a registration and the vast majority of bufferbloat folk are not native English speakers. Please feel free to correct whatever you may.<br>
>><br>
>> I shall attempt to sparingly edit the wiki, after surmounting the learning curve. The linguistic complaint is about the native English speakers.<br>
>>><br>
>>> I have subscOn May 6, 2013 10:42 AM, "Fred Stratton" <fredstratton@imap.cc> wrote:<br>
>>> ><br>
>>> > I have subscribed to this list because I am irritated by the incorrect spelling of 'its' as 'it's' on the developer list. So much for the educational system in North America. You do not understand the possessive.<br>
>>> ><br>
>>> > dnsmasq is used in other router software, including the shabby builds of tomatousb. It performs as expected in that context.<br>
>>> ><br>
>>> > On both the Modena and Berlin builds of Cerowrt, dnsmasq fails to renew dhcp leases after an unknown period on a given radio network. If a different network is used, a new lease can be obtained as evidenced by the return of internet connectivity. A remedy is to restart dnsmasq from the command line via ssh.<br>
>>><br>
>>> Hmm. I have not seen this behavior but I do not run wireless much right now...<br>
>>><br>
>>><br>
>> The understanding I had was that a primary focus was on improving the problem on wireless. I have therefore configured the local network with that goal in mind, disconnecting the wired component.</p>
<p dir="ltr">First we had to fix the theory. Ethernet was next. Cable after that. Wireless work is just starting<br></p>
<p dir="ltr">>>> > dnsmasq also points to dns servers supplied by the ISP. It is difficult, or impossible, to substitute other server addresses.<br>
>>><br>
>>> You just override the default for ge00.<br>
>><br>
>><br>
>> Shall retry.<br>
>>><br>
>>> ><br>
>>> > The wiki, apart from using the possessive incorrectly, like the developers, does not cover the setup of AQM on the Berlin build at all.<br>
>>><br>
>>> Berlin is presently a development build. Documentation lags.<br>
>>><br>
>>> Stable is Modena. <br>
>>> > It does not mention that activation requires modifying /etc/hotplug.d to specify a device, and that simple_qos.sh, and the QoS panel, both should not be used.<br>
>>><br>
>>> Discussed on the list. All you have to do with Berlin is set it up via the AQM tab.<br>
>><br>
>> I also has to set up /etc/hotplug.d appropriately, or the chosen AQM values do not load, as evidenced by running <br>
>><br>
>> tc disc show </p>
<p dir="ltr">Hmm. It is enabled? It doesn't work on a fresh boot?</p>
<p dir="ltr">These options in Berlin are 2 weeks old so</p>
<p dir="ltr">I note that cerowrt-devel is the main list<br>
For most things.<br>
>><br>
>>><br>
>>> > I have an ADSL line, subject to RFI, with the target SNR set to 12 decibel.<br>
>>> ><br>
>>> > AQM with efq_codel and simplest.qos reduce uplink delay from 5000ms to 700ms. There are massive delays and breaks in streaming video when attempting to run traffic streams concurrently.<br>
>>><br>
>>> The core numbers we care about are your uplink and downlink settings.<br>
>>><br>
>>> Which are?<br>
>>><br>
>>><br>
>> originally uplink latency 5000ms, downlink latency 700ms<br>
>><br>
>> best values with efq_codel/simplest.qos<br>
>><br>
>> uplink latency 700ms downlink latency 40 ms<br>
>><br>
>> 8100 kb/s down, 750 mob/s up with AQM off.</p>
<p dir="ltr">So try 7300 down 600 up. Latency to where is 40 ms? <br></p>
<p dir="ltr">>>> Rule of thumb is to try 85% of your rated bandwidth for those and work up from there.<br>
>>><br>
>>> Enable the ADSL option.<br>
>>><br>
>>><br>
>> I understood that the ADSL option just decremented the input values by fifteen per cent.</p>
<p dir="ltr">No it accounts for ATM packetization at least in theory.</p>
<p dir="ltr">However in simplest.QoS there may be a bug in the r2q handling in htb at below 1 Mbit. You can try commenting that out.</p>
<p dir="ltr">>> Further decrements do not really alter the latencies.</p>
<p dir="ltr">It is not clear to me how you are measuring. You should on a simple test see 10ms or so added latency in your case (a ping and an upload)</p>
<p dir="ltr">The rrul tests should go to about 40.</p>
<p dir="ltr">I assume that there is another device I. The loop here?<br>
>>><br>
>>> Also on this list on berlin was discussed that perhaps htb is malfunctioning at very low rates.<br>
>>> ><br>
>>> > This is is the exact opposite of the Taeht roadshow demo.<br>
>>><br>
>>> The roadshow is on cable at 20 Mbit down 5 up. There is no magic solution for ever lower bandwidths than that.<br>
>>><br>
>>> I have been fiddling with much despair with a model for under 4 Mbit.<br>
>>><br>
>>> Lastly efq-codel is emphatically the wrong thing in this case. It is just where i stick the crazier ideas.<br>
>>><br>
>>> Please stick to fq-codel or nfq codel.<br>
>>><br>
>>><br>
>> Appreciate that I have tried all three. I note what you say about efq_codel.<br>
>><br>
>> I am staying with ADSL, and not moving to cable, which is traffic-shaped, and tainted by the hand of Branson. FTTC is currently a quasi-monopoly, and therefore out of consideration also.<br>
>><br>
>> I submit that cable is irrelevant for most of the world, as its installation cost is prohibitive. Cable does not make money outside America. The majority of users are likely to be using ADSL, with a proportion moving to fibre in time, or to 4G, pace higher download allowances.<br>
>><br>
>> Yes, Modena behaves far better than Berlin on an ADSL line at present, but saying that serves no purpose in the forward progress of the project.<br>
>><br>
>> I shall test further configurations, and repost when I find something positive or informative.<br>
>><br>
>>> ><br>
>>> > _______________________________________________<br>
>>> > Cerowrt-users mailing list<br>
>>> > <a href="mailto:Cerowrt-users@lists.bufferbloat.net">Cerowrt-users@lists.bufferbloat.net</a><br>
>>> > <a href="https://lists.bufferbloat.net/listinfo/cerowrt-users">https://lists.bufferbloat.net/listinfo/cerowrt-users</a><br>
>><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> Cerowrt-users mailing list<br>
> <a href="mailto:Cerowrt-users@lists.bufferbloat.net">Cerowrt-users@lists.bufferbloat.net</a><br>
> <a href="https://lists.bufferbloat.net/listinfo/cerowrt-users">https://lists.bufferbloat.net/listinfo/cerowrt-users</a><br>
><br>
</p>