[Cerowrt-users] dnsmasq lease renewal and other issues with Berlin current

[Dave Taht]

On May 6, 2013 12:46 PM, "Fred Stratton" <fredstratton at imap.cc> wrote:
>
>
>
> Begin forwarded message:
>
>> From: Fred Stratton <fredstratton at imap.cc>
>> Subject: Re: [Cerowrt-users] dnsmasq lease renewal and other issues with
Berlin current
>> Date: 6 May 2013 17:39:01 BST
>> To: "cerowrt-users-request at lists.bufferbloat.net" <
cerowrt-users-request at lists.bufferbloat.net>
>>
>>
>> On 6 May 2013, at 16:46, Dave Taht <dave.taht at gmail.com> wrote:
>>
>>> 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.
>>
>> I shall attempt to sparingly edit the wiki, after surmounting the
learning curve. The linguistic complaint is about the native English
speakers.
>>>
>>> I have subscOn May 6, 2013 10:42 AM, "Fred Stratton"
<fredstratton at imap.cc> wrote:
>>> >
>>> > 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.
>>> >
>>> > dnsmasq is used in other router software, including the shabby builds
of tomatousb. It performs as expected in that context.
>>> >
>>> > 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.
>>>
>>> Hmm. I have not seen this behavior but I do not run wireless much right
now...
>>>
>>>
>> 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.

First we had to fix the theory. Ethernet was next. Cable after that.
Wireless work is just starting

>>> > dnsmasq also points to dns servers supplied by the ISP. It is
difficult, or impossible, to substitute other server addresses.
>>>
>>> You just override the default for ge00.
>>
>>
>> Shall retry.
>>>
>>> >
>>> > The wiki, apart from using the possessive incorrectly, like the
developers, does not cover the setup of AQM on the Berlin build at all.
>>>
>>> Berlin is presently a development build. Documentation lags.
>>>
>>> Stable is Modena.
>>> > 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.
>>>
>>> Discussed on the list. All you have to do with Berlin is set it up via
the AQM tab.
>>
>> I also has to set up  /etc/hotplug.d appropriately, or the chosen AQM
values do not load, as evidenced by running
>>
>> tc disc show

Hmm. It is enabled? It doesn't work on a fresh boot?

These options in Berlin are 2 weeks old so

I note that cerowrt-devel is the main list
For most things.
>>
>>>
>>> > I have an ADSL line, subject to RFI, with the target SNR set to 12
decibel.
>>> >
>>> > 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.
>>>
>>> The core numbers we care about are your uplink and downlink settings.
>>>
>>> Which are?
>>>
>>>
>> originally uplink latency 5000ms, downlink latency 700ms
>>
>> best values with efq_codel/simplest.qos
>>
>> uplink latency 700ms downlink latency 40 ms
>>
>> 8100 kb/s down, 750 mob/s up with AQM off.

So try 7300 down 600 up. Latency to where is 40 ms?

>>> Rule of thumb is to try 85% of your rated bandwidth for those and work
up from there.
>>>
>>> Enable the ADSL option.
>>>
>>>
>> I understood that the ADSL option just decremented the input values by
fifteen per cent.

No it accounts for ATM packetization at least in theory.

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.

>> Further decrements do not really alter the latencies.

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)

The rrul tests should go to about 40.

I assume that there is another device I. The loop here?
>>>
>>> Also on this list on berlin was discussed that perhaps htb is
malfunctioning at very low rates.
>>> >
>>> > This is is the exact opposite of the Taeht roadshow demo.
>>>
>>> The roadshow is on cable at 20 Mbit down 5 up. There is no magic
solution for ever lower bandwidths than that.
>>>
>>> I have been fiddling with much despair with a model for under 4 Mbit.
>>>
>>> Lastly efq-codel is emphatically the wrong thing in this case. It is
just where i stick the crazier ideas.
>>>
>>> Please stick  to fq-codel or nfq codel.
>>>
>>>
>> Appreciate that I have tried all three.  I note what you say about
efq_codel.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> I shall test further configurations, and repost when I find something
positive or informative.
>>
>>> >
>>> > _______________________________________________
>>> > Cerowrt-users mailing list
>>> > Cerowrt-users at lists.bufferbloat.net
>>> > https://lists.bufferbloat.net/listinfo/cerowrt-users
>>
>>
>
>
> _______________________________________________
> Cerowrt-users mailing list
> Cerowrt-users at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-users/attachments/20130506/c654a191/attachment-0002.html>