Re: [Bloat] Rigorous Coffee Shop Bloat Testing
On Wed, 4 Sep 2019 06:24:07 +0300 Jonathan Morton wrote: > > On 4 Sep, 2019, at 6:17 am, Dave Taht wrote: > > > > …and people jump off of cable as soon as > > they can get fiber... but that's due to the RTT more than the bandwidth. > > And also due to the downright predatory pricing/billing practices of the > typical cable ISP. I think an awful lot of people would take any viable > alternative at this point, purely due to that factor. Which is why cable > industry lobbyists are doing their level best to kill municipal fibre. I am convinced that all the hype about 5G will die when people see how the ISP's in the US will want to price it. They will certainly want to charge a premium for 5G to avoid under cutting their current overpriced service. ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Rigorous Coffee Shop Bloat Testing
> On 4 Sep, 2019, at 6:17 am, Dave Taht wrote: > > …and people jump off of cable as soon as > they can get fiber... but that's due to the RTT more than the bandwidth. And also due to the downright predatory pricing/billing practices of the typical cable ISP. I think an awful lot of people would take any viable alternative at this point, purely due to that factor. Which is why cable industry lobbyists are doing their level best to kill municipal fibre. - Jonathan Morton ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Rigorous Coffee Shop Bloat Testing
Kenneth Porter writes: > On 9/3/2019 5:40 PM, Stephen Hemminger wrote: >> There was a recent Wall Street Journal article that faster Internet doesn't >> mean anything. >> https://www.wsj.com/graphics/faster-internet-not-worth-it/ >> >> I just thought "faster Internet just exposes your existing Bufferbloat" > > I hit a paywall trying to read that so I looked up the article title > and found some interesting commentary: > > https://tech.slashdot.org/story/19/08/20/1450204/the-truth-about-faster-internet-its-not-worth-it > > https://stopthecap.com/2019/08/20/wall-street-journal-says-faster-internet-not-worth-it-but-they-ignore-bottlenecks-and-data-caps/ > > Most people are streamers and won't fill a fat pipe. The big winners The market has shifted. With streaming becoming a thing (instead of bittorrent), ISPs had to ensure that there was enough bandwidth during peak hours across their entire platform to keep users from screaming. Once everybody upgraded to "enough", because the usage pattern had shifted, few want or need more. > of fast Internet are people who want to download a huge game and play > it quickly. But those are rare. (I'm a gamer but I'm patient and can Well in the cases of shared internet, more BW (and less bufferbloat) helps a lot. Small businesses such as coffee shops, etc. But they are a much smaller portion of the market than the home. It's semi-worse/semi-better than that - usage has shifted to people's LTE phones for a lot of things, and they forget to enable wifi. I think ISPs have shot themselves in the foot, perhaps permanently. * By shipping buggy gear and bad wifi * Not investing in good ipv4 and ipv6 technologies * By having bad latency, the user experience is comparable to lte apps * By not allowing services in the home, they've shifted to the cloud Growth for ISPs could come from higher upload bandwidths - and I kind of hope they start marketing "FASTER UPLOADS!" "Great Gaming!" "Killer Videoconferencing!" "Multiple security cameras!" etc - Even a mere doubling of upload speeds helps a lot. ... instead of doing that, some are trying to put on data caps and other barriers to using the oversupply of bandwidth they now have with no demand. Certainly there's a big focus on somehow delivering 4k or higher video - and that's really not very perceptible, just a bunch a bits cisco just pulled out of the docsis 10Gbit effort. There's no demand. The demand for (some) fiber exists simply because cablemodems are so bad - and have 5x the baseline RTT as fiber does - and hype. Gfiber and FIOS struggle. Sonic in SF, is doing well, but that's SF for you. "DOCSIS-LL - now with lower RTTs! Buy it now!" > wait a day to play so I'm happy to save money on a cheaper package > that can be used for something else.) I subsist on a really tiny amount of bandwidth, managed of course by cake. > > As you say, when people report slow Internet, it's probably bloat, not > the speed of the package. But faster packages make money for the ISPs. Nobody on the slashdot article chimed in on the bufferbloat front. But whatever. Back in 2012... I thought we'd basically hit "peak bandwidth" at ~40Mbit/user, and we just needed to optimize for RTTs to utilize that always at multiple levels - be that physical rtt on link - or via cdns - or wifi - etc. I'd argued strenously with cablelabs that their benchmarks were wrong - that web page growth was not exponential (avg web page size has only doubled in 7 years) - this is a great resource: https://httparchive.org/reports/state-of-the-web#bytesTotal ... that everything was bound by RTT - that a single queue AQM was smoked by fq due to the reduced RTTs on bidirectional traffic... google published a great benchmark about why RTT was so important... https://www.igvita.com/2012/07/19/latency-the-new-web-performance-bottleneck/ and they didn't fix it. Took years to rollout docsis 3.1, which is still only tiny better uploads rolled out first which helped on generic RTTs Unless usage patterns change - fixing bufferbloat, and back to things like torrent running all the time, or folk migrating services en-mass back into their homes and businesses, I don't see bandwidth related revenue growth for land-line ISPs. Sure, we'll see dsl users continue to migrate to whatever they can, and people jump off of cable as soon as they can get fiber... but that's due to the RTT more than the bandwidth. I do hope - 10 years from now - someone points at what I just said and laughs, showing their 10Gbit home fiber line saturated with brainwave to smellovision full immersion bi-dir traffic, or something like that. And I still hope people get out into the real world into more nice coffeeshops, and hang out. I remember when lan parties were a thing ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Configuring sqm-scripts on OpenWRT
--On Tuesday, September 03, 2019 6:22 PM -0700 Etienne Champetier wrote: No idea if it's up to date, but my google foo gives me https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm Thanks. Somehow I wasn't seeing the luci-app-sqm package in the downloaded list of available packages. I used the Find function to locate it and now get a very nice set of GUI knobs to set it up. I set it to piece of cake, which I can't do on my CentOS 7 box as its kernel is to old to have the module. ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Rigorous Coffee Shop Bloat Testing
On 9/3/2019 5:40 PM, Stephen Hemminger wrote: There was a recent Wall Street Journal article that faster Internet doesn't mean anything. https://www.wsj.com/graphics/faster-internet-not-worth-it/ I just thought "faster Internet just exposes your existing Bufferbloat" I hit a paywall trying to read that so I looked up the article title and found some interesting commentary: https://tech.slashdot.org/story/19/08/20/1450204/the-truth-about-faster-internet-its-not-worth-it https://stopthecap.com/2019/08/20/wall-street-journal-says-faster-internet-not-worth-it-but-they-ignore-bottlenecks-and-data-caps/ Most people are streamers and won't fill a fat pipe. The big winners of fast Internet are people who want to download a huge game and play it quickly. But those are rare. (I'm a gamer but I'm patient and can wait a day to play so I'm happy to save money on a cheaper package that can be used for something else.) As you say, when people report slow Internet, it's probably bloat, not the speed of the package. But faster packages make money for the ISPs. ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Configuring sqm-scripts on OpenWRT
opkg install luci-app-sqm Kenneth Porter writes: > I've been using Linux on a small business server for 20 years and > started messing with shaping back when Wondershaper was a thing, maybe > 10 years ago. I've flashed open source builds into my home router to > get better firmware but haven't really tuned it before. > > I just installed the latest stable OpenWRT on my aging ZyXEL (the > stock firmware was crap) and installed the sqm-scripts opkg. On my > CentOS server I edited /etc/sqm/.conf and use systemd to launch > the shaper. How do I do that on OpenWRT? > > I'm guessing there's no pretty Luci web admin thing for it. Pointers > to how to write one would be welcome. I'm sure others would love > having GUI knobs for it. > > ___ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Rigorous Coffee Shop Bloat Testing
On Tue, 3 Sep 2019 10:29:51 -0700 Dave Taht wrote: > On Tue, Sep 3, 2019 at 8:57 AM Rich Brown wrote: > > > > > On Sep 3, 2019, at 11:22 AM, bloat-requ...@lists.bufferbloat.net wrote: > > > > > > The coffee shop tests were fun, but I(we) needed more rigor when doing > > > them. What I'd typically do is go in, > > > get on the wifi, start 6 minutes worth of tests, get in line, get > > > coffee... > > > > OK. I'll bite. What "six minutes of tests" do you queue up? What do you > > record? > > Still working out what the "right thing" would be. The ecn syn failure > thing was new (didn't know OSX had that stat), getting some caps, > seeing if ipv6 was available, all seem like good ideas, in addition to > bloat protection. > > the most recent script was this - (the data is in my blog-cerowrt repo > on github, also). > > We could turn this into a batch file and try to get more rigorous > about also getting a packet cap. > > Is there a decent android or IOS tool yet? > > #!/bin/sh > > T="Los_Gatos_Starbucks" > F="flent -x -H flent-fremont.bufferbloat.net -t $T" > > $F --te=download_streams=4 tcp_ndown > $F --te=upload_streams=4 --socket-stats tcp_nup > # $F --te=upload_streams=4 tcp_2up_square # not useful enough > $F rrul > $F rrul_be > > > > And how do you broach the subject with the owner? Something like... > > Carefully. The owners are always ready to take a complement or > complaint, and, so long as you catch 'em when > not too busy are usually pretty social in general. > > In many cases they share the wifi with their credit card reader and > when I say that fixing bufferbloat helps, > their eyes light up. That was a specific problem that at least one had > - demonstrable - I saw it take forever > to clear a transaction (and the bloat was 2+ seconds long at the time > - NOT triggered by me) once... he had a synology router, and "applying > QoS" "just worked", and we did other things like reposition the > antenna, also. got me lunch > that did and he punched a whole bunch of holes in my "repeat business" > card > > However the employees usually lack the router's password and clue. > > IF we were to make this a thing (and it does invoke fond memories of > how we first spread wifi around the bay area > and then the world in the early 2000s - I was part of a group called > thirdbreak that generally lept across the counter to help a lot, back > in the days we were so eager to get out of the office and onto wifi > that we were mapping all the locations available - example: > http://www.wififreespot.com/ca.php from those days...), perhaps carry > a portable printer for the test output, biz cards, and so on for the > no-owner-present case. > > I recently hit on the idea of creating stickers - attached is the one > I'm using on my guitar... > > which is a bit too much over the top, I think, generally. > > but plan to give out 0.0.0.0/8 and 240.0.0.0/4 ones next time. > > They are cheap (I used stickermule) and with a cool logo, folk dig > adorning their laptops with them, in general. Still, > we've never found that logo/slogan for fixing bufferbloat - the word > is too long and too negative, though I thought > the inverted wifi logo we use on the cerowrt site a good start. "Better wifi". > > With more folk gathering data... > > Maybe (for example) we'd play off starbucks vs peets - attached is > starbucks (using google wifi) vs another coffeeshop, coffeecat - sigh. > but weirdly enough starbucks's packet cap - although very close to > what a fq_codel'd trace would look like, doesn't actually seem to be a > fq_codeled trace. Still puzzled, need to go back and try that spot > again. > > And I gotta say, it's *really good* to get out of the lab once in a > while and see people, and sometimes, actually fix something, trying a > different coffee shop every week. > > I guess, in the cases where the coffee doesn't become free, I could > deduct it as a business expense. :) > > > "Uh, I think I know why all those heads are popping up..." OR > > "This is a nice network you have here. It'd be a shame if something > > happened to it..." OR > > Oh, that's great! Goes with my costume, too. "Hey buddy, got an ipv6 address?" > > > "I know I look like [don't look like] a pointy-headed geek, but there's > > this thing called bufferbloat..." OR > > "Do you ever get complaints that your wifi is really slow?" > > I might also have an agenda in trying to see how much ipv6 is out > there, and the syn thing is bugging me, too. > So with a more organized set of tests, we could fan out to the coffee > shops of the world and forment another > wifi revolution and turn that world upside down! Who's with me!? There was a recent Wall Street Journal article that faster Internet doesn't mean anything. https://www.wsj.com/graphics/faster-internet-not-worth-it/ I just thought "faster Internet just exposes your existing Bufferbloat" ___ Bloat mailing list Blo
Re: [Bloat] Configuring sqm-scripts on OpenWRT
No idea if it's up to date, but my google foo gives me https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm Le mar. 3 sept. 2019 à 17:09, Kenneth Porter a écrit : > > I've been using Linux on a small business server for 20 years and started > messing with shaping back when Wondershaper was a thing, maybe 10 years > ago. I've flashed open source builds into my home router to get better > firmware but haven't really tuned it before. > > I just installed the latest stable OpenWRT on my aging ZyXEL (the stock > firmware was crap) and installed the sqm-scripts opkg. On my CentOS server > I edited /etc/sqm/.conf and use systemd to launch the shaper. How do > I do that on OpenWRT? > > I'm guessing there's no pretty Luci web admin thing for it. Pointers to how > to write one would be welcome. I'm sure others would love having GUI knobs > for it. > > ___ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
[Bloat] Configuring sqm-scripts on OpenWRT
I've been using Linux on a small business server for 20 years and started messing with shaping back when Wondershaper was a thing, maybe 10 years ago. I've flashed open source builds into my home router to get better firmware but haven't really tuned it before. I just installed the latest stable OpenWRT on my aging ZyXEL (the stock firmware was crap) and installed the sqm-scripts opkg. On my CentOS server I edited /etc/sqm/.conf and use systemd to launch the shaper. How do I do that on OpenWRT? I'm guessing there's no pretty Luci web admin thing for it. Pointers to how to write one would be welcome. I'm sure others would love having GUI knobs for it. ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Rigorous Coffee Shop Bloat Testing
--On Tuesday, September 03, 2019 11:29 AM -0700 Dave Taht wrote: In many cases they share the wifi with their credit card reader and when I say that fixing bufferbloat helps, their eyes light up. That was a specific problem that at least one had - demonstrable - I saw it take forever to clear a transaction (and the bloat was 2+ seconds long at the time - NOT triggered by me) once... he had a synology router, and "applying QoS" "just worked", and we did other things like reposition the antenna, also. got me lunch that did and he punched a whole bunch of holes in my "repeat business" card My favorite cafe owner would just look like a deer in the headlights over this. She doesn't do online at all and just provides the wifi for customers. I'm not sure who set it up for her. Her CC reader is dial-up. I'm pretty new myself to hacking a consumer router so I don't know what's even possible. Likely her router doesn't even have any settings to deal with bloat. What can you do without risking breaking things and ending up with an angry owner? ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
[Bloat] Fwd: Re: Unable to create htb tc classes more than 64K
Turns out that with the "earliest departure time" support in sched_fq,
it is now possible to write a shaper in eBPF, thus avoiding the global
qdisc lock in sched_htb. This is pretty cool, if you ask me! :)
-Toke
--- Begin Message ---
On 8/25/19 7:52 PM, Cong Wang wrote:
> On Wed, Aug 21, 2019 at 11:00 PM Akshat Kakkar wrote:
>>
>> On Thu, Aug 22, 2019 at 3:37 AM Cong Wang wrote:
I am using ipset + iptables to classify and not filters. Besides, if
tc is allowing me to define qdisc -> classes -> qdsic -> classes
(1,2,3 ...) sort of structure (ie like the one shown in ascii tree)
then how can those lowest child classes be actually used or consumed?
>>>
>>> Just install tc filters on the lower level too.
>>
>> If I understand correctly, you are saying,
>> instead of :
>> tc filter add dev eno2 parent 100: protocol ip prio 1 handle
>> 0x0001 fw flowid 1:10
>> tc filter add dev eno2 parent 100: protocol ip prio 1 handle
>> 0x0002 fw flowid 1:20
>> tc filter add dev eno2 parent 100: protocol ip prio 1 handle
>> 0x0003 fw flowid 2:10
>> tc filter add dev eno2 parent 100: protocol ip prio 1 handle
>> 0x0004 fw flowid 2:20
>>
>>
>> I should do this: (i.e. changing parent to just immediate qdisc)
>> tc filter add dev eno2 parent 1: protocol ip prio 1 handle 0x0001
>> fw flowid 1:10
>> tc filter add dev eno2 parent 1: protocol ip prio 1 handle 0x0002
>> fw flowid 1:20
>> tc filter add dev eno2 parent 2: protocol ip prio 1 handle 0x0003
>> fw flowid 2:10
>> tc filter add dev eno2 parent 2: protocol ip prio 1 handle 0x0004
>> fw flowid 2:20
>
>
> Yes, this is what I meant.
>
>
>>
>> I tried this previously. But there is not change in the result.
>> Behaviour is exactly same, i.e. I am still getting 100Mbps and not
>> 100kbps or 300kbps
>>
>> Besides, as I mentioned previously I am using ipset + skbprio and not
>> filters stuff. Filters I used just to test.
>>
>> ipset -N foo hash:ip,mark skbinfo
>>
>> ipset -A foo 10.10.10.10, 0x0x0001 skbprio 1:10
>> ipset -A foo 10.10.10.20, 0x0x0002 skbprio 1:20
>> ipset -A foo 10.10.10.30, 0x0x0003 skbprio 2:10
>> ipset -A foo 10.10.10.40, 0x0x0004 skbprio 2:20
>>
>> iptables -A POSTROUTING -j SET --map-set foo dst,dst --map-prio
>
> Hmm..
>
> I am not familiar with ipset, but it seems to save the skbprio into
> skb->priority, so it doesn't need TC filter to classify it again.
>
> I guess your packets might go to the direct queue of HTB, which
> bypasses the token bucket. Can you dump the stats and check?
With more than 64K 'classes' I suggest to use a single FQ qdisc [1], and
an eBPF program using EDT model (Earliest Departure Time)
The BPF program would perform the classification, then find a data structure
based on the 'class', and then update/maintain class virtual times and
skb->tstamp
TBF = bpf_map_lookup_elem(&map, &classid);
uint64_t now = bpf_ktime_get_ns();
uint64_t time_to_send = max(TBF->time_to_send, now);
time_to_send += (u64)qdisc_pkt_len(skb) * NSEC_PER_SEC / TBF->rate;
if (time_to_send > TBF->max_horizon) {
return TC_ACT_SHOT;
}
TBF->time_to_send = time_to_send;
skb->tstamp = max(time_to_send, skb->tstamp);
if (time_to_send - now > TBF->ecn_horizon)
bpf_skb_ecn_set_ce(skb);
return TC_ACT_OK;
tools/testing/selftests/bpf/progs/test_tc_edt.c shows something similar.
[1] MQ + FQ if the device is multi-queues.
Note that this setup scales very well on SMP, since we no longer are forced
to use a single HTB hierarchy (protected by a single spinlock)
--- End Message ---
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Rigorous Coffee Shop Bloat Testing
> On Sep 3, 2019, at 11:22 AM, bloat-requ...@lists.bufferbloat.net wrote: > > The coffee shop tests were fun, but I(we) needed more rigor when doing > them. What I'd typically do is go in, > get on the wifi, start 6 minutes worth of tests, get in line, get > coffee... OK. I'll bite. What "six minutes of tests" do you queue up? What do you record? And how do you broach the subject with the owner? Something like... "Uh, I think I know why all those heads are popping up..." OR "This is a nice network you have here. It'd be a shame if something happened to it..." OR "I know I look like [don't look like] a pointy-headed geek, but there's this thing called bufferbloat..." OR "Do you ever get complaints that your wifi is really slow?" Thanks. Rich ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] [Cerowrt-devel] talking at linux plumbers in portugal next week
Not sure this is on-topic, but: https://www.prnewswire.com/news-releases/root-cause-analysis-and-incident-report-on-the-august-ddos-attack-300905405.html https://lists.gt.net/nanog/users/206044 > On Sep 3, 2019, at 16:21, Dave Taht wrote: > > On Tue, Sep 3, 2019 at 5:23 AM Mikael Abrahamsson wrote: >> >> On Mon, 2 Sep 2019, Dave Taht wrote: >> >>> with copy-pasted parameters set in the 90s - openwrt's default, last I >>> looked, was 25/sec. >> >> -A syn_flood -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit >> 25/sec --limit-burst 50 -m comment --comment "!fw3" -j RETURN >> -A syn_flood -m comment --comment "!fw3" -j DROP >> >> Well, it's got a burst-size of 50. I agree that this is quite >> conservative. >> >> However, at least in my home we're not seeing drops: >> >> # iptables -nvL | grep -A 4 "Chain syn_flood" >> Chain syn_flood (1 references) >> pkts bytes target prot opt in out source >> destination >> 2296 113K RETURN tcp -- * * 0.0.0.0/0 >> 0.0.0.0/0tcp flags:0x17/0x02 limit: avg 25/sec burst 50 /* !fw3 >> */ >> 0 0 DROP all -- * * 0.0.0.0/0 >> 0.0.0.0/0/* !fw3 */ >> >> But you might be right that in places with a lot more clients then this >> might indeed cause problems. > > Well, *I* long ago had upped those params by 10x and don't see syn > drops either on my backbone. But I rather suspect the rest of the > world just copy-pasted it. It should scale as a function of bandwidth, > I suppose, or get updated as a side effect of setting QoS - or just > get bumped up. Start a bug over with openwrt? Take a hard look at > other firewall designs? > > Like I said, though, my big question was is there a browser stat or > some other easily accessible stat to see how > often syns are rejected? Another context for this was syn negotiation > with ecn on and the fallback. > > Interestingly, I've also seen a pretty big uptick in ecn marking over > the last year or so, on one uplink (we do have a lot of guests that > run apple gear), it's now at over 10% of of the drop ratio on > outbound. > > This box is - I hope - the last cerowrt box running in the universe - > and the only reason it ever goes down is because of a long duration > power failure. I've been meaning to replace it for ages... > > root@lounge:~# uptime > 07:14:53 up 55 days, 17:14, load average: 0.16, 0.09, 0.10 > > outbound: > > qdisc fq_codel 120: parent 1:12 limit 1001p flows 1024 quantum 300 > target 5.0ms interval 100.0ms ecn > Sent 159378714029 bytes 1038654784 pkt (dropped 426065, overlimits 0 > requeues 0) > backlog 0b 0p requeues 0 > maxpacket 1514 drop_overlimit 0 new_flow_count 213282954 ecn_mark 48220 > new_flows_len 0 old_flows_len 1 > > inbound: (where comcast remarks most packets to CS1) > > qdisc fq_codel 120: parent 1:12 limit 1001p flows 1024 quantum 1500 > target 5.0ms interval 100.0ms ecn > Sent 40391986695 bytes 34710741 pkt (dropped 420, overlimits 0 requeues 0) > backlog 0b 0p requeues 0 > maxpacket 1514 drop_overlimit 0 new_flow_count 5687382 ecn_mark 0 > new_flows_len 0 old_flows_len 2 > qdisc fq_codel 130: parent 1:13 limit 1001p flows 1024 quantum 300 > target 5.0ms interval 100.0ms ecn > Sent 2285974845172 bytes 1748071724 pkt (dropped 61231, overlimits 0 > requeues 0) > backlog 0b 0p requeues 0 > maxpacket 1514 drop_overlimit 0 new_flow_count 229072930 ecn_mark 344 > new_flows_len 0 old_flows_len 1 > > >> >> -- >> Mikael Abrahamssonemail: swm...@swm.pp.se > > > > -- > > Dave Täht > CTO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-831-205-9740 > ___ > Cerowrt-devel mailing list > cerowrt-de...@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] talking at linux plumbers in portugal next week
On Tue, Sep 3, 2019 at 8:10 AM Toke Høiland-Jørgensen wrote: > > Dave Taht writes: > > > On Tue, Sep 3, 2019 at 7:45 AM Toke Høiland-Jørgensen wrote: > >> > >> Dave Taht writes: > >> > >> > On Tue, Sep 3, 2019 at 5:23 AM Mikael Abrahamsson > >> > wrote: > >> >> > >> >> On Mon, 2 Sep 2019, Dave Taht wrote: > >> >> > >> >> > with copy-pasted parameters set in the 90s - openwrt's default, last I > >> >> > looked, was 25/sec. > >> >> > >> >> -A syn_flood -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit > >> >> --limit 25/sec --limit-burst 50 -m comment --comment "!fw3" -j RETURN > >> >> -A syn_flood -m comment --comment "!fw3" -j DROP > >> >> > >> >> Well, it's got a burst-size of 50. I agree that this is quite > >> >> conservative. > >> >> > >> >> However, at least in my home we're not seeing drops: > >> >> > >> >> # iptables -nvL | grep -A 4 "Chain syn_flood" > >> >> Chain syn_flood (1 references) > >> >> pkts bytes target prot opt in out source > >> >> destination > >> >> 2296 113K RETURN tcp -- * * 0.0.0.0/0 > >> >> 0.0.0.0/0tcp flags:0x17/0x02 limit: avg 25/sec burst 50 /* > >> >> !fw3 */ > >> >> 0 0 DROP all -- * * 0.0.0.0/0 > >> >> 0.0.0.0/0/* !fw3 */ > >> >> > >> >> But you might be right that in places with a lot more clients then this > >> >> might indeed cause problems. > >> > > >> > Well, *I* long ago had upped those params by 10x and don't see syn > >> > drops either on my backbone. But I rather suspect the rest of the > >> > world just copy-pasted it. It should scale as a function of bandwidth, > >> > I suppose, or get updated as a side effect of setting QoS - or just > >> > get bumped up. Start a bug over with openwrt? Take a hard look at > >> > other firewall designs? > >> > >> FWIW: > >> > >> # iptables -nvL syn_flood > >> Chain syn_flood (1 references) > >> pkts bytes target prot opt in out source > >> destination > >> 195K 12M RETURN tcp -- * * 0.0.0.0/0 > >> 0.0.0.0/0tcp flags:0x17/0x02 limit: avg 25/sec burst 50 /* > >> !fw3 */ > >> 0 0 DROP all -- * * 0.0.0.0/0 > >> 0.0.0.0/0/* !fw3 */ > >> > >> # ip6tables -nvL syn_flood > >> Chain syn_flood (1 references) > >> pkts bytes target prot opt in out source > >> destination > >> 396 41508 RETURN tcp * * ::/0 ::/0 > >> tcp flags:0x17/0x02 limit: avg 25/sec burst 50 /* !fw3 */ > >> 0 0 DROP all * * ::/0 ::/0 > >> /* !fw3 */ > >> > >> rebooted this box today; don't seem to have hit the limit thus far, > >> though... This is on a gigabit link. > > > > Hmm. Try to trigger it with --te=upload_streams=200 ? > > Sure, that triggers it: > > # iptables -nvL syn_flood > Chain syn_flood (1 references) > pkts bytes target prot opt in out source > destination > 197K 12M RETURN tcp -- * * 0.0.0.0/00.0.0.0/0 >tcp flags:0x17/0x02 limit: avg 25/sec burst 50 /* !fw3 */ > 275 16480 DROP all -- * * 0.0.0.0/00.0.0.0/0 >/* !fw3 */ > > > And I get tons of errors from netperf failing to start up. > > However, the protection is only actually enabled for the INPUT chain; > i.e., I had to use the router itself as the netperf target to trigger > the rule. So not sure a rule such as this would be the cause of your > coffee shop failures? Good point. I think in the cerowrt case I'd enabled it for all chains and then noticed, and bumped it up. Limiting syn attempts to the router itself makes more sense than doing it on the forward path. The coffee shop tests were fun, but I(we) needed more rigor when doing them. What I'd typically do is go in, get on the wifi, start 6 minutes worth of tests, get in line, get coffee... I would feel a twinge of guilt when I'd start seeing heads pop up from their laptops while running the rrul test, but in two cases I managed to talk to the owner, help 'em get QoS configured right on their router, show'd 'em the difference, and got a free meal out of it... So, it was only discovering that I'd had that 30% rejection figure via the stats on my osx box that I started speculating as to the cause(s), last week. The other big fear is that because OSX is always attempting to negotiate ECN, that that's a cause. A bit more rigor about this and it could turn into a good paper or blog entry, and it's good to get out more for the sake of science, with table service! > > This is with the default openwrt config, BTW: > > > config defaults > option syn_flood '1' > > > -Toke -- Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 ___ Bloat mailing list Bloat@
Re: [Bloat] Getting bloat tests into open source speedtest
Another bit of good news - guidosarducci over at OpenWrt has packaged up an improved version of the "betterspeedtest.sh" script to work with OpenWrt 18.06. https://forum.openwrt.org/t/speedtest-new-package-to-measure-network-performance/24647/71 shows the announcement of the package. Run it with: speedtest-netperf.sh --help Enjoy! Rich___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] talking at linux plumbers in portugal next week
Dave Taht writes: > On Tue, Sep 3, 2019 at 7:45 AM Toke Høiland-Jørgensen wrote: >> >> Dave Taht writes: >> >> > On Tue, Sep 3, 2019 at 5:23 AM Mikael Abrahamsson wrote: >> >> >> >> On Mon, 2 Sep 2019, Dave Taht wrote: >> >> >> >> > with copy-pasted parameters set in the 90s - openwrt's default, last I >> >> > looked, was 25/sec. >> >> >> >> -A syn_flood -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit >> >> --limit 25/sec --limit-burst 50 -m comment --comment "!fw3" -j RETURN >> >> -A syn_flood -m comment --comment "!fw3" -j DROP >> >> >> >> Well, it's got a burst-size of 50. I agree that this is quite >> >> conservative. >> >> >> >> However, at least in my home we're not seeing drops: >> >> >> >> # iptables -nvL | grep -A 4 "Chain syn_flood" >> >> Chain syn_flood (1 references) >> >> pkts bytes target prot opt in out source >> >> destination >> >> 2296 113K RETURN tcp -- * * 0.0.0.0/0 >> >> 0.0.0.0/0tcp flags:0x17/0x02 limit: avg 25/sec burst 50 /* >> >> !fw3 */ >> >> 0 0 DROP all -- * * 0.0.0.0/0 >> >> 0.0.0.0/0/* !fw3 */ >> >> >> >> But you might be right that in places with a lot more clients then this >> >> might indeed cause problems. >> > >> > Well, *I* long ago had upped those params by 10x and don't see syn >> > drops either on my backbone. But I rather suspect the rest of the >> > world just copy-pasted it. It should scale as a function of bandwidth, >> > I suppose, or get updated as a side effect of setting QoS - or just >> > get bumped up. Start a bug over with openwrt? Take a hard look at >> > other firewall designs? >> >> FWIW: >> >> # iptables -nvL syn_flood >> Chain syn_flood (1 references) >> pkts bytes target prot opt in out source >> destination >> 195K 12M RETURN tcp -- * * 0.0.0.0/0 >> 0.0.0.0/0tcp flags:0x17/0x02 limit: avg 25/sec burst 50 /* !fw3 >> */ >> 0 0 DROP all -- * * 0.0.0.0/0 >> 0.0.0.0/0/* !fw3 */ >> >> # ip6tables -nvL syn_flood >> Chain syn_flood (1 references) >> pkts bytes target prot opt in out source >> destination >> 396 41508 RETURN tcp * * ::/0 ::/0 >> tcp flags:0x17/0x02 limit: avg 25/sec burst 50 /* !fw3 */ >> 0 0 DROP all * * ::/0 ::/0 >> /* !fw3 */ >> >> rebooted this box today; don't seem to have hit the limit thus far, >> though... This is on a gigabit link. > > Hmm. Try to trigger it with --te=upload_streams=200 ? Sure, that triggers it: # iptables -nvL syn_flood Chain syn_flood (1 references) pkts bytes target prot opt in out source destination 197K 12M RETURN tcp -- * * 0.0.0.0/00.0.0.0/0 tcp flags:0x17/0x02 limit: avg 25/sec burst 50 /* !fw3 */ 275 16480 DROP all -- * * 0.0.0.0/00.0.0.0/0 /* !fw3 */ And I get tons of errors from netperf failing to start up. However, the protection is only actually enabled for the INPUT chain; i.e., I had to use the router itself as the netperf target to trigger the rule. So not sure a rule such as this would be the cause of your coffee shop failures? This is with the default openwrt config, BTW: config defaults option syn_flood '1' -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] talking at linux plumbers in portugal next week
On Tue, Sep 3, 2019 at 7:45 AM Toke Høiland-Jørgensen wrote: > > Dave Taht writes: > > > On Tue, Sep 3, 2019 at 5:23 AM Mikael Abrahamsson wrote: > >> > >> On Mon, 2 Sep 2019, Dave Taht wrote: > >> > >> > with copy-pasted parameters set in the 90s - openwrt's default, last I > >> > looked, was 25/sec. > >> > >> -A syn_flood -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit > >> --limit 25/sec --limit-burst 50 -m comment --comment "!fw3" -j RETURN > >> -A syn_flood -m comment --comment "!fw3" -j DROP > >> > >> Well, it's got a burst-size of 50. I agree that this is quite > >> conservative. > >> > >> However, at least in my home we're not seeing drops: > >> > >> # iptables -nvL | grep -A 4 "Chain syn_flood" > >> Chain syn_flood (1 references) > >> pkts bytes target prot opt in out source > >> destination > >> 2296 113K RETURN tcp -- * * 0.0.0.0/0 > >> 0.0.0.0/0tcp flags:0x17/0x02 limit: avg 25/sec burst 50 /* > >> !fw3 */ > >> 0 0 DROP all -- * * 0.0.0.0/0 > >> 0.0.0.0/0/* !fw3 */ > >> > >> But you might be right that in places with a lot more clients then this > >> might indeed cause problems. > > > > Well, *I* long ago had upped those params by 10x and don't see syn > > drops either on my backbone. But I rather suspect the rest of the > > world just copy-pasted it. It should scale as a function of bandwidth, > > I suppose, or get updated as a side effect of setting QoS - or just > > get bumped up. Start a bug over with openwrt? Take a hard look at > > other firewall designs? > > FWIW: > > # iptables -nvL syn_flood > Chain syn_flood (1 references) > pkts bytes target prot opt in out source > destination > 195K 12M RETURN tcp -- * * 0.0.0.0/00.0.0.0/0 >tcp flags:0x17/0x02 limit: avg 25/sec burst 50 /* !fw3 */ > 0 0 DROP all -- * * 0.0.0.0/00.0.0.0/0 >/* !fw3 */ > > # ip6tables -nvL syn_flood > Chain syn_flood (1 references) > pkts bytes target prot opt in out source > destination > 396 41508 RETURN tcp * * ::/0 ::/0 >tcp flags:0x17/0x02 limit: avg 25/sec burst 50 /* !fw3 */ > 0 0 DROP all * * ::/0 ::/0 >/* !fw3 */ > > rebooted this box today; don't seem to have hit the limit thus far, > though... This is on a gigabit link. Hmm. Try to trigger it with --te=upload_streams=200 ? > > -Toke -- Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] talking at linux plumbers in portugal next week
Dave Taht writes: > On Tue, Sep 3, 2019 at 5:23 AM Mikael Abrahamsson wrote: >> >> On Mon, 2 Sep 2019, Dave Taht wrote: >> >> > with copy-pasted parameters set in the 90s - openwrt's default, last I >> > looked, was 25/sec. >> >> -A syn_flood -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit >> 25/sec --limit-burst 50 -m comment --comment "!fw3" -j RETURN >> -A syn_flood -m comment --comment "!fw3" -j DROP >> >> Well, it's got a burst-size of 50. I agree that this is quite >> conservative. >> >> However, at least in my home we're not seeing drops: >> >> # iptables -nvL | grep -A 4 "Chain syn_flood" >> Chain syn_flood (1 references) >> pkts bytes target prot opt in out source >> destination >> 2296 113K RETURN tcp -- * * 0.0.0.0/0 >> 0.0.0.0/0tcp flags:0x17/0x02 limit: avg 25/sec burst 50 /* !fw3 >> */ >> 0 0 DROP all -- * * 0.0.0.0/0 >> 0.0.0.0/0/* !fw3 */ >> >> But you might be right that in places with a lot more clients then this >> might indeed cause problems. > > Well, *I* long ago had upped those params by 10x and don't see syn > drops either on my backbone. But I rather suspect the rest of the > world just copy-pasted it. It should scale as a function of bandwidth, > I suppose, or get updated as a side effect of setting QoS - or just > get bumped up. Start a bug over with openwrt? Take a hard look at > other firewall designs? FWIW: # iptables -nvL syn_flood Chain syn_flood (1 references) pkts bytes target prot opt in out source destination 195K 12M RETURN tcp -- * * 0.0.0.0/00.0.0.0/0 tcp flags:0x17/0x02 limit: avg 25/sec burst 50 /* !fw3 */ 0 0 DROP all -- * * 0.0.0.0/00.0.0.0/0 /* !fw3 */ # ip6tables -nvL syn_flood Chain syn_flood (1 references) pkts bytes target prot opt in out source destination 396 41508 RETURN tcp * * ::/0 ::/0 tcp flags:0x17/0x02 limit: avg 25/sec burst 50 /* !fw3 */ 0 0 DROP all * * ::/0 ::/0 /* !fw3 */ rebooted this box today; don't seem to have hit the limit thus far, though... This is on a gigabit link. -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
[Bloat] Revising the synflood limit
OK, I started a topic over there. It would be good to know how many other firewall tools set a syn limit by default, but that would take way more research. https://forum.openwrt.org/t/the-synflood-limit-is-too-low-for-the-modern-internet/43957 ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] talking at linux plumbers in portugal next week
On Tue, Sep 3, 2019 at 5:23 AM Mikael Abrahamsson wrote: > > On Mon, 2 Sep 2019, Dave Taht wrote: > > > with copy-pasted parameters set in the 90s - openwrt's default, last I > > looked, was 25/sec. > > -A syn_flood -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit > 25/sec --limit-burst 50 -m comment --comment "!fw3" -j RETURN > -A syn_flood -m comment --comment "!fw3" -j DROP > > Well, it's got a burst-size of 50. I agree that this is quite > conservative. > > However, at least in my home we're not seeing drops: > > # iptables -nvL | grep -A 4 "Chain syn_flood" > Chain syn_flood (1 references) > pkts bytes target prot opt in out source > destination > 2296 113K RETURN tcp -- * * 0.0.0.0/0 > 0.0.0.0/0tcp flags:0x17/0x02 limit: avg 25/sec burst 50 /* !fw3 */ > 0 0 DROP all -- * * 0.0.0.0/0 > 0.0.0.0/0/* !fw3 */ > > But you might be right that in places with a lot more clients then this > might indeed cause problems. Well, *I* long ago had upped those params by 10x and don't see syn drops either on my backbone. But I rather suspect the rest of the world just copy-pasted it. It should scale as a function of bandwidth, I suppose, or get updated as a side effect of setting QoS - or just get bumped up. Start a bug over with openwrt? Take a hard look at other firewall designs? Like I said, though, my big question was is there a browser stat or some other easily accessible stat to see how often syns are rejected? Another context for this was syn negotiation with ecn on and the fallback. Interestingly, I've also seen a pretty big uptick in ecn marking over the last year or so, on one uplink (we do have a lot of guests that run apple gear), it's now at over 10% of of the drop ratio on outbound. This box is - I hope - the last cerowrt box running in the universe - and the only reason it ever goes down is because of a long duration power failure. I've been meaning to replace it for ages... root@lounge:~# uptime 07:14:53 up 55 days, 17:14, load average: 0.16, 0.09, 0.10 outbound: qdisc fq_codel 120: parent 1:12 limit 1001p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn Sent 159378714029 bytes 1038654784 pkt (dropped 426065, overlimits 0 requeues 0) backlog 0b 0p requeues 0 maxpacket 1514 drop_overlimit 0 new_flow_count 213282954 ecn_mark 48220 new_flows_len 0 old_flows_len 1 inbound: (where comcast remarks most packets to CS1) qdisc fq_codel 120: parent 1:12 limit 1001p flows 1024 quantum 1500 target 5.0ms interval 100.0ms ecn Sent 40391986695 bytes 34710741 pkt (dropped 420, overlimits 0 requeues 0) backlog 0b 0p requeues 0 maxpacket 1514 drop_overlimit 0 new_flow_count 5687382 ecn_mark 0 new_flows_len 0 old_flows_len 2 qdisc fq_codel 130: parent 1:13 limit 1001p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn Sent 2285974845172 bytes 1748071724 pkt (dropped 61231, overlimits 0 requeues 0) backlog 0b 0p requeues 0 maxpacket 1514 drop_overlimit 0 new_flow_count 229072930 ecn_mark 344 new_flows_len 0 old_flows_len 1 > > -- > Mikael Abrahamssonemail: swm...@swm.pp.se -- Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Getting bloat tests into open source speedtest
Mikael Abrahamsson writes: > On Tue, 3 Sep 2019, Toke Høiland-Jørgensen wrote: > >> Hi everyone >> >> I came across this open source speedtest: https://www.netztest.at/en/ >> (also run by nic.cz and integrated into the Turris Omnia firmware: >> https://www.netmetr.cz/en/ ). >> >> Only issue is that it doesn't test for bufferbloat. So, I opened an >> issue on the upstream repo; this is the link, in case anyone else wants >> to participate in the discussion: >> https://github.com/rtr-nettest/open-rmbt/issues/6 > > This is the swedish local speedtest run by .SE: > > https://github.com/dotse/bbk Hmm, I think my old university actually had a project to add it at some point. Not sure what happened to that... > I've asked them for bufferbloat tests as well, so... if anyone want to do > anything, that'd be nice. > > What codebase does dslreports speedtest use, it seems to have a very nice > bufferbloat test? I think it's proprietary, but I'm not sure... -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] talking at linux plumbers in portugal next week
On Mon, 2 Sep 2019, Dave Taht wrote: with copy-pasted parameters set in the 90s - openwrt's default, last I looked, was 25/sec. -A syn_flood -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 25/sec --limit-burst 50 -m comment --comment "!fw3" -j RETURN -A syn_flood -m comment --comment "!fw3" -j DROP Well, it's got a burst-size of 50. I agree that this is quite conservative. However, at least in my home we're not seeing drops: # iptables -nvL | grep -A 4 "Chain syn_flood" Chain syn_flood (1 references) pkts bytes target prot opt in out source destination 2296 113K RETURN tcp -- * * 0.0.0.0/00.0.0.0/0 tcp flags:0x17/0x02 limit: avg 25/sec burst 50 /* !fw3 */ 0 0 DROP all -- * * 0.0.0.0/00.0.0.0/0 /* !fw3 */ But you might be right that in places with a lot more clients then this might indeed cause problems. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Getting bloat tests into open source speedtest
On Tue, 3 Sep 2019, Toke Høiland-Jørgensen wrote: Hi everyone I came across this open source speedtest: https://www.netztest.at/en/ (also run by nic.cz and integrated into the Turris Omnia firmware: https://www.netmetr.cz/en/ ). Only issue is that it doesn't test for bufferbloat. So, I opened an issue on the upstream repo; this is the link, in case anyone else wants to participate in the discussion: https://github.com/rtr-nettest/open-rmbt/issues/6 This is the swedish local speedtest run by .SE: https://github.com/dotse/bbk I've asked them for bufferbloat tests as well, so... if anyone want to do anything, that'd be nice. What codebase does dslreports speedtest use, it seems to have a very nice bufferbloat test? -- Mikael Abrahamssonemail: swm...@swm.pp.se___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Getting bloat tests into open source speedtest
> On Sep 3, 2019, at 13:45, Toke Høiland-Jørgensen wrote: > > Sebastian Moeller writes: > >> Hi Toke, >> >> +1 >> >>> On Sep 3, 2019, at 13:39, Toke Høiland-Jørgensen wrote: >>> >>> Hi everyone >>> >>> I came across this open source speedtest: https://www.netztest.at/en/ >>> (also run by nic.cz and integrated into the Turris Omnia firmware: >>> https://www.netmetr.cz/en/ ). >> >> I tried to contact the www.netmetr.cz folks (last year), but so far >> crickets... > > Heh, well thanks for trying at least. I figured the upstream open source > project might be the best way to get things fixed; we'll see if they are > responsive :) I would hope so,. My gut feeling is, that we should address this with BEREC (https://berec.europa.eu) as all these national regulator's internet speedtests all closely follow the BEREC recommendations and there might be little perceived freedom for the national implementation according to the BEREC guidelines for changes/additions. Last time I contacted the implementor of the german speedtest (breitbandmessung.de), they basically send me bunch of BEREC documents and deflected my questions towards the EU ;) Best Regards Sebastian > > -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Getting bloat tests into open source speedtest
Sebastian Moeller writes: > Hi Toke, > > +1 > >> On Sep 3, 2019, at 13:39, Toke Høiland-Jørgensen wrote: >> >> Hi everyone >> >> I came across this open source speedtest: https://www.netztest.at/en/ >> (also run by nic.cz and integrated into the Turris Omnia firmware: >> https://www.netmetr.cz/en/ ). > > I tried to contact the www.netmetr.cz folks (last year), but so far > crickets... Heh, well thanks for trying at least. I figured the upstream open source project might be the best way to get things fixed; we'll see if they are responsive :) -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Getting bloat tests into open source speedtest
Hi Toke, +1 > On Sep 3, 2019, at 13:39, Toke Høiland-Jørgensen wrote: > > Hi everyone > > I came across this open source speedtest: https://www.netztest.at/en/ > (also run by nic.cz and integrated into the Turris Omnia firmware: > https://www.netmetr.cz/en/ ). I tried to contact the www.netmetr.cz folks (last year), but so far crickets... > > Only issue is that it doesn't test for bufferbloat. So, I opened an > issue on the upstream repo; this is the link, in case anyone else wants > to participate in the discussion: > https://github.com/rtr-nettest/open-rmbt/issues/6 > > -Toke > ___ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
[Bloat] Getting bloat tests into open source speedtest
Hi everyone I came across this open source speedtest: https://www.netztest.at/en/ (also run by nic.cz and integrated into the Turris Omnia firmware: https://www.netmetr.cz/en/ ). Only issue is that it doesn't test for bufferbloat. So, I opened an issue on the upstream repo; this is the link, in case anyone else wants to participate in the discussion: https://github.com/rtr-nettest/open-rmbt/issues/6 -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
