Some comments about procedure. I mention the distro I currently use, so one aspect is distro specific: Choose a server which actually returns pings. I used 'mtr' on one run to choose a server, but did not check it with ping. A mistake. The data collection run took circa 5 hours. The resultant data file is at ~/ , as you would expect. Octave has a graphical front end to manipulate it, qtOctave, available via Ubuntu Software Centre. I ran this combo under Ubuntu 13.10, on a NUC with a Sandy Bridge Celeron processor. The parsing of the data file took 5-6 hours, and the actual calculation 20 or 30 seconds at the end. The initial process produces a *.mat file, so, if required, recalculation time is short. You will appreciate that linux systems produce graphs that are not necessarily easily saved. I used the Print Screen key and trimmed the *.png file with a graphics program -Pinta. On 07/01/14 13:43, David Personette wrote: > Hi Sebastian, > > I have both Linux and Mac (all my systems are Linux, the Mac is my > work laptop). I don't have Matlab, so I'll try to get it working in > Octave (haven't really used it before). If it's something that can > help others in the community, then I'll definitely run it. Assuming > that I don't forget, I'll run it tonight and have it for you tomorrow. > Thanks for the clear explanations. > > -- > David P. > > > > On Tue, Jan 7, 2014 at 8:02 AM, Sebastian Moeller > wrote: > > Hi David, > > > On Jan 7, 2014, at 13:11 , David Personette > 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 > > > > > > > > > > > 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 > > wrote: > > Hi David, > > > > > > On Jan 7, 2014, at 12:08 , David Personette > 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 > > wrote: > > > Hi Fred, > > > > > > > > > On Jan 6, 2014, at 15:22 , Fred Stratton > 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 > 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 > 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 > > > > > > > > > >