Hi Fred,
On Jan 6, 2014, at 15:22 , Fred Stratton <fredstrat...@imap.cc> wrote:
> The line rate is 11744/1022 kb/s, but changes moment to moment. SNR is 12.1
> decibel. I am using 11000/950 kb/s as settings.
So 100 * 11000 / 11744 = 93.66% of downlink line rate and 100* 950 /
1022 = 92.95 % of uplink line rate; quite impressive given the common wisdom of
85% :).
> I shall try your suggestion when there is something worth watching live, to
> provide a valid comparison, which may not be before 21:30 CET on Sunday.
Oh, take your time, this is really not essential, butit would be a nice
data point for figuring out how important the correct overhead estimate really
is in real life, theory being theory and all…
Best Regards
Sebastian
>
> On 06/01/14 14:12, Sebastian Moeller wrote:
>> Hi Fred,
>>
>>
>> On Jan 6, 2014, at 10:52 , Fred Stratton <fredstrat...@imap.cc> wrote:
>>
>>> I have been operating the latest build with 6relayd disabled. The henet /48
>>> I have been allocated is subnetted correctly, presumably by dnsmasq.
>>>
>>> I adopted the suggestions to use nfq_codel and an egress target of 25ms ,
>>> with an overhead of 40 on a PPPoE connection. I chose to watch the first 2
>>> episodes of the 3 part third series of 'Sherlock', live on iPlayer, and
>>> these streamed correctly and uninterrupted for 90 minutes. This was not
>>> previously possible. (Quite whether they were up to the standard of
>>> previous episodes is another matter.)
>>>
>>> I can watch iPlayer with little stutter whilst downloading Arch Linux by
>>> torrent, downloading other files at the same time.
>>>
>>> So, for a relatively slow ADSL2+ line, the current build works well.
>> Out of curiosity, to what percentage of the "current line rate" (you
>> know the one reported by your modem) you shaped up- and downlink? And in
>> case you have too much time on your hand, how does the same feel with an
>> overhead of 10 (to see how bad an overhead underestimate would feel for a
>> user), since you currently happen to have a quite sensitive subjective
>> latency evaluation system set up :)…
>>
>> Best Regards
>> Sebastian
>>
>>>
>>> On 06/01/14 03:29, Dave Taht wrote:
>>>> On Sat, Jan 4, 2014 at 10:40 AM, Fred Stratton <fredstrat...@imap.cc>
>>>> wrote:
>>>>> Link Names:
>>>>>
>>>>> For consistency, if ADSL is used as a portmanteau term, them VDSL should
>>>>> be
>>>>> used as the equivalent for VDSL and VDSL2.
>>>>>
>>>>> CeroWRT has to decide whether it is an experimental build, or something
>>>>> that
>>>>> will eventually be used in production, so these decisions can be made
>>>>> consistently.
>>>> Well, what I was aiming for was for us to get the sqm scripts and gui
>>>> up to where they were better than the standard openwrt qos scripts and
>>>> then push them up to openwrt to where they could be more widely
>>>> deployed.
>>>>
>>>> Aside from being able to dynamically assign priorities in the gui, we
>>>> are there. Except that nfq_codel is currently getting better results
>>>> than fq_codel at low bandwidths, and I'm tempted to pour all of
>>>> simple.qos into C.
>>>>
>>>> As for cero's future - certainly since all the snowden revelations
>>>> I've been going around saying that "friends don't let friends run
>>>> factory firmware". I would like a stable build of sqm and cerowrt to
>>>> emerge, and to then go off and work on improving wifi. Regrettably
>>>> what seems to be happening is more backwards than forwards on the
>>>> former, and ramping up on the ath9k and ath10k is taking more time
>>>> than I'd like, and it seems likely I'll be working on those primarily
>>>> on another platform and only eventually pushing the results out to
>>>> cero, mainline kernel
>>>>
>>>> So it's still at the "keep plugging away" point for sqm, ipv6, cero in
>>>> general, with the stable release always just out of sight.
>>>>
>>>> Tackling the ipv6 problem is next on my agenda on cero, and getting a
>>>> test suite going is next on my day job.
>>>>
>>>>> I concur with your ADSL setup suggestion as default. I have been running
>>>>> the
>>>>> Sebastian Moeller ping script overnight to calculate ADSL overhead for the
>>>>> last several days. After several hours of curve fitting using Octave, an
>>>>> overhead result is displayed. This novel approach works well.
>>>> It would be nice to get to where we could autoconfigure a router using
>>>> tools like these with no human intervention. This includes bandwidth
>>>> estimation.
>>>>
>>>>> The overhead for the particular setup I use was 40 for PPPoE, and 10 for
>>>>> PPPoA.
>>>>>
>>>>> The default you suggest is a suitable starting point, I suggest.
>>>>>
>>>>>
>>>>> On 04/01/14 18:16, Rich Brown wrote:
>>>>>> QUESTION #5: I still don’t have any great answers for the Link Layer
>>>>>> Adaptation overhead descriptions and recommendations. In an earlier
>>>>>> message,
>>>>>> (see
>>>>>> https://lists.bufferbloat.net/pipermail/cerowrt-devel/2013-December/001914.html
>>>>>> and following messages), Fred Stratton described the overheads carried by
>>>>>> various options, and Sebastian Moeller also gave some useful advice.
>>>>>>
>>>>>> After looking at the options, I despair of giving people a clear
>>>>>> recommendation that would be optimal for their equipment. Consequently, I
>>>>>> believe the best we can do is come up with “good enough” recommendations
>>>>>> that are not wrong, and still give decent performance.
>>>>>>
>>>>>> In this spirit, I have changed Draft #3 of the “Setting up SQM” page to
>>>>>> reflect this understanding. See
>>>>>> http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310
>>>>>>
>>>>>> ADSL/ATM link: Choose “ADSL/ATM", and set Per Packet Overhead to
>>>>>> 40
>>>>>> VDSL2 link: Choose “VDSL”, and set Per Packet Overhead to 8
>>>>>> Other kind of link (e.g., Cable, Fiber, Ethernet, other not
>>>>>> listed): Choose “None (default)”, and set Per Packet Overhead to 0
>>>>>>
>>>>>> NB: I have changed the first menu choice to “ADSL/ATM” and the second to
>>>>>> “VDSL” in the description. I would ask that we change to GUI to reflect
>>>>>> those names as well. This makes it far easier/less confusing to talk
>>>>>> about
>>>>>> the options.
>>>>>>
>>>>>> As always, I welcome help in setting out clear recommendations that work
>>>>>> well for the vast majority of people who try CeroWrt. Thanks.
>>>>>>
>>>>>> Rich
>>>>>> _______________________________________________
>>>>>> 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
>>>>
>>> _______________________________________________
>>> 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
