Hi David,
On Jan 7, 2014, at 13:11 , David Personette <[email protected]> wrote: > I was going to test the recommended bridge settings for overhead (32 IIRC), > because as far as I can tell there is no PPPoE involved. I've never seen it > in the modems config (in the brief period it has an IP before I put it in > bridge mode as well so the routable IP goes to my actual router), or needed > to configure it on my router. Ah, so there are 2 major variations of "bridged": 1) LLC/SNAP: Bridged - 32 (ATM - 18, ethernet 14, possibly FCS - 4+padding) 2) VC-MUX: Bridged - 24 (ATM - 10, ethernet 14, possibly FCS - 4+padding) (he FCS padding potentially turns this into 4 variations, but it should be really rare, or so I heard). You could just slowly reduce the overhead and see how the link behaves; honestly I do not know how prominent a slight overhead underestimate would feel, so by all means go ahead and try :). If you have a mac or linux computer on your network, you could try to measure the overhead with the attached ping_sweeper5_dp.sh script (needs editing). Then you could run tc_stab_parameter_guide_04.m in matlab or octave (on the matlab command prompt change into the directory containing the script and the log file run "[ tmp ] = tc_stab_parameter_guide_04( fullfile(pwd, 'ping_sweep_ADSL2_20140104_122844.txt'))" ; make sure to replace ping_sweep_ADSL2_20140104_122844.txt with the name of your log file. The measurement will take around 3 hours (for 10000 samples per size, for your link 1000 would be enough) and wants an undisturbed network (I typically run this over night); the parsing of the log file will also consume 20 minutes or more, the actual analysis will take a few seconds… If you go that route I would love it if you could share your log file, since I only have one old bridged LLC/SNAP example. (I intend to put all scripts and an instruction on the wiki, with example plots for the different results). Best Regards Sebastian
tc_stab_parameter_guide_04.m
Description: Binary data
ping_sweeper5_dp.sh
Description: Binary data
> > I am seeing my effective bandwidth be higher by about 50/KBs on downloads. On > Netflix, my Roku used to try HD upon starting playback then (after 20-30 > seconds thinking about it) fail back to SD, but now the HD streams are > working flawlessly for hours. > > -- > David P. > > > > On Tue, Jan 7, 2014 at 6:34 AM, Sebastian Moeller <[email protected]> wrote: > Hi David, > > > On Jan 7, 2014, at 12:08 , David Personette <[email protected]> wrote: > > > I'm in the US, but live in a relatively rural area. My only internet > > options are DSL and satellite. The local provider is Century Link (it used > > to be Sprint, but they sold their copper phone business off). I have the > > fastest service that they offer (based on distance from the DSLAM), 4 down > > / .5 up. > > And you are not alone, a considerable percentage of the population > wherever you look is hanging on such connections. So cerowrt should really > help those folk as well as luckier ones. > > > > > I have had SmokePing monitoring my latency to the first hop outside my > > network for over a year now (I've been on CeroWRT the whole time). My > > baseline (no load) latency is 31ms. I used to have AQM throttling back to > > 80% of my already pathetic bandwidth. I would still regularly see periods > > lasting minutes to hours when latency would be 80 - 120ms. > > > > I only recently grokked what you were talking about with tc_stab since I > > got back from the holidays with the family, I set things up as you > > suggested for Fred (nfq_codel, "target 25ms" in advanced egress, ATM, per > > packet overhead 40, > > The exact number depends on the encapsulation your ISP uses, 40 is > right for a typical PPPoE over LLC/SNAP connection, if that is correct for > your link you are fine, otherwise contact me if you want to empirically find > out the proper value for your link. > > > and set my SQM bandwidth limits to 95%). Since the 30th my "worst case" > > latency has been 41ms. > > the fq_codels really are great if in control of the bottleneck, > really good work by bright people! > > > Plus I get to use more of my actual bandwidth. > > Well, that I am not so sure. By enabling link layer ATM the router > will automatically take care of the ATM cell overhead for you (basically > reducing the effective rate to ~90% of the link, in other words you get the > same effect by shaping to 90%). It will also handle the per packet overhead > and the nasty potential padding of the last ATM cell (both have a stronger > effect on small packets and are hard to actually account for by static rate > reduction; link layer ATM comes again to the rescue by taking these two into > account individually for each packet based on the packet size). So > effectively 95% with link layer adjustments might mean a lower wire rate than > 80% without; the important thing is that with the link layer adjustments the > link capacity is estimated correctly avoiding the modem's and the DSLAM's > buffers to fill and cause buffer bloat. > > > I REALLY wish that I'd made the time to read your emails about setting up > > the ATM overhead earlier. > > Oh, I can understand, when I learned about this some years ago (by > stumbling over Russel Stuart's website and Jesper Brouer's thesis) it > immediate changed my internet experience (I was on a 3 down / 0.5 up > connection at that time). :) > > Best Regards > Sebastian > > > > > Thank you. > > > > -- > > David P. > > > > > > > > On Mon, Jan 6, 2014 at 9:27 AM, Sebastian Moeller <[email protected]> wrote: > > Hi Fred, > > > > > > On Jan 6, 2014, at 15:22 , Fred Stratton <[email protected]> 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 <[email protected]> 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 <[email protected]> > > >>>> 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 > > >>>>>> [email protected] > > >>>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel > > >>>>> _______________________________________________ > > >>>>> Cerowrt-devel mailing list > > >>>>> [email protected] > > >>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel > > >>>> > > >>> _______________________________________________ > > >>> Cerowrt-devel mailing list > > >>> [email protected] > > >>> https://lists.bufferbloat.net/listinfo/cerowrt-devel > > > > > > > _______________________________________________ > > Cerowrt-devel mailing list > > [email protected] > > https://lists.bufferbloat.net/listinfo/cerowrt-devel > > > >
_______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
