Hi Sebastian, Did few quick tests using your recommendations and the results is still "overhead 20". Plot: http://imgur.com/a/5c3iv Text: https://drive.google.com/open?id=0B7vEuplJWEIkRVBhX2xGUmNUMVE (NOTE: I used PINGSPERSIZE = 100 instead of 1000, as I didn't have much time)
On 24 April 2017 at 14:35, Sebastian Moeller <moell...@gmx.de> wrote: > Hi Dendari, > > thanks, > > > > On Apr 24, 2017, at 14:08, Dendari Marini <dendar...@gmail.com> wrote: > > > > Hello, > > > > Could you share the two output plots somewhere, so I can have a look at > those? (Also I might want tto ask for the text file that actually was > generated by the ping collector script, just so I can run and > confirm/de-bug things my self). > > > > Sure thing. The plot images: http://imgur.com/a/qDtA0 > > Okay, these _look_ reasonable on first sight... > > > > And the output text file: https://drive.google.com/open?id= > 0B7vEuplJWEIkc1ozbUZRSGstajQ > > …but this actually shows that 8.8.8.8 truncated the size of the ICMP > responses (the runs of “bytes=92” in the log file also it only returned > sizes from 44 to 92 so not exactly what we asked for). I would not really > trust these results, even though the RTTs should be dominated by your slow > egress link. Please redo these against a different ICMP target server ( > netperf-east.bufferbloat.net might do, depending on your location, that > on is on the east coast of the U.S.). I have to admit, that the > hrping/windows overhead extraction did not have much exercise so far and > might be not be robust enough. I will have a look at your log file, but > this really requires a different target server. In the unix script there is > the following: > > > echo "To run measurements supply the TARGET IP address as first > agument to ${0} this script." > echo "Use traceroute 8.8.8.8 to get a list of increasingly distant > hosts, pick the first host out of your network (ideally the DSLAM)." > echo "Test whether the selected host responds to ping: 'ping -s16 -c 1 > target.IP.address.quad' : this needs to actually return non zero RTTs." > echo "If the hosts does not reply to the pings take the next host from > the traceroute (moving closer to 8.8.8.8), repeat until you find a replying > host." > echo "Once the main script is started have a quick look at the > logfile, to see whether the RTTs stay close to the initial test RTT." > echo "If the RTTs have increased a lot, the PINGPERIOD might be too > short, and the host might have put us on a slow path; either increase > PINGPERIOD or try the next host..." > echo "" > echo "Here is the traceroute (might take a while):" > echo "" > traceroute 8.8.8.8 > echo "" > echo "Alternatively you might try to use googles infrastructure by > running: ${0} gstatic.com " > echo "Please note that gstatic.com might not return arbitrarily sized > ICMP probes, so check the log file care-fully.” > > Which unfortunately does not appear in the windows script yet, but this > still seems great advise, please note that at the time this was written, > 8.8.8.8 still replied with “correctly”’ sized ICMP echo responses just like > gstatic.com di initially, now both seem to truncate their responses. This > is somewhat to be expected, but maybe somewhere along the path there is > another server that will still respond properly... > > > Best Regards > Sebastian > > > > > > > On 24 April 2017 at 13:34, Sebastian Moeller <moell...@gmx.de> wrote: > > Hello, > > > > > > > On Apr 24, 2017, at 10:41, Dendari Marini <dendar...@gmail.com> wrote: > > > > > > Hello, > > > > > > Probably correct, but you do not have to resort to believing, you can > actually try to measure that ;) In case I have been too subtle before, have > a look at https://github.com/moeller0/ATM_overhead_detector and follow > the instructions there... > > > > > > I just used your script and it estimated an overhead of 20 bytes, so > should I use "overhead 20 atm" or am I missing something? In the last few > days I've been using "pppoe-llcsnap" ("overhead 40 atm") without any > evident issue, should I change it? > > > > Hmm, 20 seems rather interesting and something I never saw > before. Could you share the two output plots somewhere, so I can have a > look at those? (Also I might want tto ask for the text file that actually > was generated by the ping collector script, just so I can run and > confirm/de-bug things my self). I am not saying 20 is impossible, just that > it is improbable enough to require more scrutiny. > > > > > > Best Regards > > Sebastian > > > > > > > > > > FWIW here's a quick example on ingress ppp that I tested using connmark > > > the connmarks (1 or 2 or unmarked) being set by iptables rules on > outbound > > > connections/traffic classes. > > > > > > Unfortunately I'm really not sure how to apply those settings to my > case, it's something I've never done so some hand-holding is probably > needed, sorry. At the moment I've limited the Steam bandwidth using the > built-in Basic Queue and DPI features from the ER-X. They're easy to set up > but aren't really ideal, would rather prefer Cake would take care about it > more dynamically. > > > > > > Anyway about the Steam IP addresses I've noticed, in the almost three > weeks of testing, they're almost always the same IP blocks (most of which > can be found on the Steam Support website, https://support.steampowered. > com/kb_article.php?ref=8571-GLVN-8711). I believe it would be a good > starting point for limiting Steam, what do you think? > > > > > > On 24 April 2017 at 09:55, Sebastian Moeller <moell...@gmx.de> wrote: > > > Hi David, > > > > > > > On Apr 23, 2017, at 14:32, David Lang <da...@lang.hm> wrote: > > > > > > > > On Sun, 23 Apr 2017, Sebastian Moeller wrote: > > > > > > > >>> About the per-host fairness download issue: while it's kinda > resolved I still feel like it's mainly related to Steam, as normally > downloading files from PC1 and PC2 halved the speed as expected even at > full bandwidth (so no overhead, no -15%). > > > >> > > > >> This might be true, but for cake to meaningfully resolve > bufferbloat you absolutely _must_ take care to account for encapsulation > and overhead one way or another. > > > > > > > > well, one way to account for this overhead is to set the allowed > bandwidth low enough. Being precise on this overhead lets you get closer to > the actual line rate, but if you have enough bandwidth, it may not really > matter (i.e. if you have a 100Mb connection and only get 70Mb out of it, > you probably won't notice unless you go looking) > > > > > > Violent agreement. But note that with AAL5’s rule to always > use an integer number of ATM cells per user packet the required bandwidth > sacrifice to statically cover the worst case gets ludicrous (theoretical > worst case: requiring 2 53 byte ATM cells for on 49 Byte data packet: 100 * > 49 / (53 * 2) = 46.2% and this is on top of any potential unaccounted > overhead inside the 49 Byte packet). Luckily the ATM padding issue is not > as severe for bigger packets… but still to statically fully solve > modem/dslam bufferbloat the required bandwidth sacrifice seems excessive… > But again you are right, there might be users who do not mind to go to this > length. For this reason I occasionally recommend to start the bandwidth at > 50% to certainly rule out overhead/encapsulation accounting issues (mind > you take 50% as starting point from which to ramp up…) > > > > > > Best Regards > > > Sebastian. > > > > > > > > > > > > > > David Lang > > > > > > > > > > > >
_______________________________________________ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake