Re: [Cake] conntrack lookup continuation

2017-01-31 Thread Jonathan Morton 

> On 31 Jan, 2017, at 16:49, Felix Resch  wrote:
> 
> Since we now already do the conntrack-lookup for the nat keyword, would it be 
> expensive to implement a kind of internal conntrack-mark-and-restore by 
> cake-tin?
> 
> E.g. when traffic leaves throu canke tin#x, the conntrack entry will get a 
> fwmark and return traffic is put in the corresponding tin/bin on the ingress 
> cake.

That’s an interesting idea.  At this point I don’t know how easy it is to 
implement, though.

Certainly we need to clean up some other things first.

 - Jonathan Morton

___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] [Make-wifi-fast] Flent results for point-to-point Wi-Fi on LEDE/OM2P-HS available

2017-01-31 Thread Pete Heist 

> On Jan 31, 2017, at 12:55 AM, Dave Taht  wrote:
> 
> * Question #16: Is there any other testing anyone would like to see
> while I have this rig up?
> 
> 1) ECN on on both sides.
> 2) A voip test
> 3) P2MP (3 or more stations, rtt_fair_var* tests)
> 4) Lowered MCS rates or distance or rain

Ok, I’ll see what I can do on 1, 2 and 4.

#3 might be for another day, another site (Open Mesh at an outdoor camp, 
another story), but I’d like to get to it.

> * Question #15: FreeNet's link to the Internet is 1 Gbps, and AFAIK
> does not experience saturation. The e1000 ethernet driver that the
> Internet router uses supports BQL. Is there any sense in running
> fq_codel or similar on the router, if it does not become saturated?
> 
> You don't need queue management until you need queue management. A
> basic flaw of mrtg's design in your graph here is that it takes
> samples in 5 minute windows. If you are totally nuking your link for 1
> sec out of 5 and the rest nearly idle, you won't see it. A flent test
> in their offices to somewhere nearby over that link will be revealing.
> 
> In general, applying fq_codel on a BQL enabled system is always a
> goodness, it costs next to nothing in CPU to do it that way.
> (outbound). Depending on your measurement of what happens on inbound,
> you might want to do inbound rate shaping….

Ok, I’ll see if they’re game to try that. That would be great if it helped.

> The gains are relative to the bandwidth and the amount of fixed
> buffering in the radio. For example, I can get 320Mbits/sec out of the
> archer c7v2's ath10k, with 10ms latency, at 8 feet. 20 feet, and
> through a wall, it's 200Mbit/100ms latency. I don't like the initial
> shape of that curve! (what I typically see happen on 802.11ac is it
> hitting a wall and not working at all)

My testing was actually through one wall also (drywall). I didn’t have the 
radios right next to one another. But I’m at 2.4 Ghz and I think you’re at 5 
GHz, so walls are going to affect that setup more, of course. I’m surprised how 
much of a latency hit you see through one wall.

> I happen to like ubnt's gear, although their default firmware only
> lasts 5 minutes for me these days. They have very good throughput and
> latency characteristics with decent signal strength. I look forward to
> a benchmark of what you can get from them. (I am still looking for a
> good upgrade from the nanostation M5s)

My PowerBeam M5-400 has been very stable. I think I’ve only rebooted it for 
config changes or on general principle.

> Question #12: What's the reason for Cake's occasional sudden
> throughput shifts, and why do its latencies tend to be higher than
> fq_codel?
> 
> We are still debugging cake. Recently the API got a bit wacked. The
> AQM is tuned for DSL speeds. More data is needed.

Ok, there’s plenty of Cake data in my results to mine, or if Jonathan asks I’ll 
try something else.

> * On the pfifo analysis - I really enjoyed the rush song and it was
> very appropriate for how pfifo misbehaves!
> 
> * Question #9: Does my assertion make sense, that it's "better" to do
> half-duplex queueing on only one end of the link? The side towards the
> Internet?
> 
> Usually the stuff coming from the internet dominates the traffic by a
> 8-20 figure, so coming from might be a worthwhile place to shape.
> 
> I ran out of time before tackling 8-1

Thanks for all the help. After I test more from your suggestions, I’ll re-post 
with results and any remaining questions, but a lot of it’s clearing up for me!

___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] [Make-wifi-fast] flent testers wanted prior to next release

2017-01-31 Thread Toke Høiland-Jørgensen 
Stephen Hemminger  writes:

> On Tue, 31 Jan 2017 17:35:40 +0100
> Toke Høiland-Jørgensen  wrote:
>
>> Stephen Hemminger  writes:
>> 
>> > On Tue, 20 Dec 2016 11:02:44 -0800
>> > Dave Taht  wrote:
>> >  
>> > Has anyone automated or orchestrated flent? I would love to get several
>> > projects doing daily build flent runs. Both upstream kernel, net-next,
>> > and Intel Clear Linux has nightly build and test.  
>> 
>> Flent has a built-in batch mode that lets you automate running several
>> tests in a row including setup/teardown scripts etc... Is that what you
>> mean?
>
> That is start, was hoping someone had already done the nightly run
> kind of environment.

Ah, right. No, I think the main thing missing for that is some way to
collect the results that is a bit more systematic than just dumping data
files to disk... Have some ideas for that, but have not started writing
code yet; contributions welcome! ;)

-Toke
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] [Make-wifi-fast] flent testers wanted prior to next release

2017-01-31 Thread Stephen Hemminger 
On Tue, 31 Jan 2017 17:35:40 +0100
Toke Høiland-Jørgensen  wrote:

> Stephen Hemminger  writes:
> 
> > On Tue, 20 Dec 2016 11:02:44 -0800
> > Dave Taht  wrote:
> >  
> >> Toke has been busy adding new features to the flent network test tool.
> >> I consider it *almost* stable enough for a new release. Some of the
> >> development has been focused on making the flent-gui much faster and
> >> more responsive (as our data sets have got larger), others on
> >> providing better default command line output, and there's other fixes
> >> across the board, including QT5 support.
> >> 
> >> In particular, I fear we've broken windows users of flent. I would
> >> dearly like it if some more folk out there using flent could pull the
> >> latest git version and see if there are any new bugs or regressions in
> >> it, any of the the 87 tests, and the plotters, before freezing the
> >> code for a new year's release.
> >> 
> >> github: https://github.com/tohojo/flent
> >> main site: https://flent.org/
> >> 
> >> While you are at it, please feel free to stress out any of the flent
> >> servers as a target, give the new cake a shot and compare it against
> >> htb+fq_codel or your aqm of choice, or fiddle with the new wifi code,
> >> and share your data. tcp_nup, tcp_ndown, rrul, rrul_be remain the main
> >> tests, but the square wave one is turning out interesting :)
> >> 
> >> And if you have any feature requests or bugs to file, please get them
> >> in soon to the github!
> >> 
> >> We could also use better documentation and tutorials for use... some
> >> more example scripts leveraging things like the cpu_stats and
> >> qdisc_stats tools, and so on,
> >> 
> >> Active public servers include:
> >> 
> >> flent-freemont.bufferbloat.net
> >> ( this is colocated with flent-bbr-west which has bbr on by default - an
> >> interesting test might be testing both these servers at the same time
> >> via the rtt_fair* tests from your location)
> >> 
> >> flent-dallas.bufferbloat.net
> >> flent-london.bufferbloat.net
> >> flent-tokyo.bufferbloat.net
> >> flent-newark.bufferbloat.net
> >> 
> >> There are also netperf-west and netperf-east and netperf-eu and no
> >> doubt a few others.
> >> 
> >> We plan to add a few BBR enabled servers over the holidays.
> >> 
> >> The changelog so far:
> >> 
> >> 
> >> - Support PyQt5 in the GUI (and prefer it over PyQt4). If PyQt5 is not
> >> found, fall back to PyQt4.
> >> 
> >> 
> >> - Add new SummaryFormatter that outputs mean and median values for
> >> each data series. This is the new default formatter, meaning that its
> >> output will be shown after a test run if no other formatter (or plot)
> >> is specified.
> >> 
> >> - Support multiprocessing in the GUI. When loading several plots at
> >> once, plotting will now be passed off to separate worker processes.
> >> 
> >>   This allows plotting to use all the available processors on the
> >> machine, and speeds up loading of many plots tremendously (initial
> >> load is sped up by an order of magnitude). This change also means that
> >> re-plotting on config changes will be done dynamically in the
> >> background, which makes the GUI more responsive.
> >> 
> >> - Make text completely black in the default colour scheme. This
> >> increases contrast, and helps legibility, especially on printed
> >> figures.
> >> 
> >> 
> >> - Some internal code changes: Port command line parser from the old
> >> optparse class to the newer argparse, and fix a bunch of linter
> >> 
> >>   
> >
> > Has anyone automated or orchestrated flent? I would love to get several
> > projects doing daily build flent runs. Both upstream kernel, net-next,
> > and Intel Clear Linux has nightly build and test.  
> 
> Flent has a built-in batch mode that lets you automate running several
> tests in a row including setup/teardown scripts etc... Is that what you
> mean?
> 
> -Toke

That is start, was hoping someone had already done the nightly run kind of 
environment.
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] [Make-wifi-fast] flent testers wanted prior to next release

2017-01-31 Thread Toke Høiland-Jørgensen 
Stephen Hemminger  writes:

> On Tue, 20 Dec 2016 11:02:44 -0800
> Dave Taht  wrote:
>
>> Toke has been busy adding new features to the flent network test tool.
>> I consider it *almost* stable enough for a new release. Some of the
>> development has been focused on making the flent-gui much faster and
>> more responsive (as our data sets have got larger), others on
>> providing better default command line output, and there's other fixes
>> across the board, including QT5 support.
>> 
>> In particular, I fear we've broken windows users of flent. I would
>> dearly like it if some more folk out there using flent could pull the
>> latest git version and see if there are any new bugs or regressions in
>> it, any of the the 87 tests, and the plotters, before freezing the
>> code for a new year's release.
>> 
>> github: https://github.com/tohojo/flent
>> main site: https://flent.org/
>> 
>> While you are at it, please feel free to stress out any of the flent
>> servers as a target, give the new cake a shot and compare it against
>> htb+fq_codel or your aqm of choice, or fiddle with the new wifi code,
>> and share your data. tcp_nup, tcp_ndown, rrul, rrul_be remain the main
>> tests, but the square wave one is turning out interesting :)
>> 
>> And if you have any feature requests or bugs to file, please get them
>> in soon to the github!
>> 
>> We could also use better documentation and tutorials for use... some
>> more example scripts leveraging things like the cpu_stats and
>> qdisc_stats tools, and so on,
>> 
>> Active public servers include:
>> 
>> flent-freemont.bufferbloat.net
>> ( this is colocated with flent-bbr-west which has bbr on by default - an
>> interesting test might be testing both these servers at the same time
>> via the rtt_fair* tests from your location)
>> 
>> flent-dallas.bufferbloat.net
>> flent-london.bufferbloat.net
>> flent-tokyo.bufferbloat.net
>> flent-newark.bufferbloat.net
>> 
>> There are also netperf-west and netperf-east and netperf-eu and no
>> doubt a few others.
>> 
>> We plan to add a few BBR enabled servers over the holidays.
>> 
>> The changelog so far:
>> 
>> 
>> - Support PyQt5 in the GUI (and prefer it over PyQt4). If PyQt5 is not
>> found, fall back to PyQt4.
>> 
>> 
>> - Add new SummaryFormatter that outputs mean and median values for
>> each data series. This is the new default formatter, meaning that its
>> output will be shown after a test run if no other formatter (or plot)
>> is specified.
>> 
>> - Support multiprocessing in the GUI. When loading several plots at
>> once, plotting will now be passed off to separate worker processes.
>> 
>>   This allows plotting to use all the available processors on the
>> machine, and speeds up loading of many plots tremendously (initial
>> load is sped up by an order of magnitude). This change also means that
>> re-plotting on config changes will be done dynamically in the
>> background, which makes the GUI more responsive.
>> 
>> - Make text completely black in the default colour scheme. This
>> increases contrast, and helps legibility, especially on printed
>> figures.
>> 
>> 
>> - Some internal code changes: Port command line parser from the old
>> optparse class to the newer argparse, and fix a bunch of linter
>> 
>> 
>
> Has anyone automated or orchestrated flent? I would love to get several
> projects doing daily build flent runs. Both upstream kernel, net-next,
> and Intel Clear Linux has nightly build and test.

Flent has a built-in batch mode that lets you automate running several
tests in a row including setup/teardown scripts etc... Is that what you
mean?

-Toke
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] [Make-wifi-fast] Flent results for point-to-point Wi-Fi on LEDE/OM2P-HS available

2017-01-31 Thread Pete Heist 

> On Jan 31, 2017, at 12:21 AM, Dave Taht  wrote:
> 
> A backstory of how I got involved in the bufferbloat effort was that I
> deployed some shiny "new" and "faster" wireless-n radios (6 years
> ago)... and my WISP network in Nicaragua collapsed in rain - which was
> about 6 months after I'd made the cutover from g and from motorola's
> radios. The signal strength was within expected parameters, the
> achieved rates were half to 1/3 what they were dry, but latencies
> climbed to over 30 seconds in some cases. I had *no* idea what was
> going wrong at the time, and it wasn't until 6 months after I closed
> the business that I ran into Jim Gettys, and the rest is history.

Quite an interesting story, could be in the project background somewhere. :)

> I never got around to writing it up, I just gave a couple talks on the
> subject and moved onto fixing bufferbloat thoroughly. We got
> distracted by trying to solve it on the ISP backbones before tackling
> wifi in this past year.

Yeah, I also don’t want to waste too much time trying to improve latency in 
their point-to-point Wi-Fi backhaul links unless it’s going to help. I suppose 
the questions are:

1) Are their backhaul links stable enough in all conditions to hold a steady 
enough rate that soft rate limiting is practical without sacrificing too much 
throughput AND
2) Is the sfq setup Ubiquiti has in their gear “good enough” in managing 
bufferbloat that it wouldn’t make much of a difference anyway.

As for the final connection to my residence, it's 3km NLOS through some 
deciduous trees close to me, so I have a better signal in winter with no 
leaves. While it’s pretty good all things considered (actual 20 Mbps up, 30 
Mbps down when things are well), bitrate can vary maybe 20% because of the 
link, and more because of other network load. So even if fq_codel with soft 
rate limiting does help, which it does, it’s not as practical for my final 
connection to do it. Just thought of it now, but I wonder if I can run LEDE on 
my PowerBeam M5-400.

Anyway, that’s why I thought backhaul links are a better candidate for soft 
rate limiting (since they’re usually line-of-sight), if it even helps at all 
(TBD).

> ... As for the performance of openmesh being pretty good... they were
> the first group to test the fq_codel intermediate queues and ATF code
> way back in september, :) - it's not clear to me if that's what you
> were testing or not or they shipped an update yet.

Just to be clear, I was only testing LEDE on OM2P-HS. I’d like to test Chaos 
Calmer (or Open Mesh’s stock firmware), so I’m not mixing the testing of the 
ath9k changes with the qdiscs, but I’ll see if I get to this along with the 
Ubiquiti testing.

> A good test to run is to lower the mcs rates (set the rateset
> manually, or add distance, and/or rain) and to see how flat latency
> remains. This is also a better test of real-world conditions, if you
> can get some reports back on the actual mcs rates being achieved in
> the field, and use those.

This, I’m definitely going to try.

Although I can’t make it rain in my office :) I can use ‘iw dev wlan0 set 
bitrates ht-mcs-2.4 X’, where X is the MCS level. This appears to be effective, 
and I could even write a “rain.sh" and change it on the fly to see what happens.

> It would be my hope that 802.11e is off (rrul will show this, and we
> still do badly with it on)

802.11e is on, as it’s the default in LEDE and I didn’t change it. I can 
certainly turn that off and compare.

> You can probably within this deployment shape the uplinks to some
> fairly low value and get good performance more the time.
> 
> I do not have any real hope for being able to make wifi better with
> soft-shapers. It's a gordian knot - you need to respond rapidly to
> changes in rate, both up and down, and mix up flows thoroughly,
> optimize your aggregates to go to one station at a time and switch to
> the next, and that's what we got with codel close to the hardware as
> it is now in lede. [1]
> 
> If it helps any, this is the best later talk I've given on these subjects:
> 
> https://www.youtube.com/watch?v=Rb-UnHDw02o 
> 

I understand. Enjoyed that talk thoroughly, thanks!

> UBNT's gear (commonly used by wisps) has some neat tricks to manage
> things better, when I last took apart their qos system it was an
> insane set of sfqs with sf’s.

So that was one of my questions, is that setup “good enough” that external rate 
limiting and shaping isn’t worth it, even with a stable connection. TBD.

___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] [Make-wifi-fast] Flent results for point-to-point Wi-Fi on LEDE/OM2P-HS available

2017-01-31 Thread Pete Heist 

> On Jan 30, 2017, at 10:44 PM, Toke Høiland-Jørgensen  wrote:
> 
> Oh my, this is quite a lot of tests. Nice :)

It’s also a thumbs up for the ath9k driver changes that nothing went wrong 
during the testing. It takes about 15 hours for a full run and I probably did 
that 4-5 times total.

> Few general points on running tests:
> 
> - Yeah, as you note Flent has a batch facility. Did you not use this
>  simply because you couldn't find it, or was there some other reason?
>  Would love some feedback on what I can do to make that more useful to
>  people... While I have no doubt that your 'flenter.py' works, wrapping
>  a wrapper in this sense makes me cringe a little bit ;)

I actually didn’t notice it existed until I was about 85% done and scanning the 
Flent man page for some other reason. I cringed, but at that point I just stuck 
with what I had. I don’t know if Flent can also make some basic html report 
with the graphs and setup output, but that was useful to write for myself. 
Flent’s metadata feature sounds useful and I’ll try that.

> - I'm not sure if you're checking that applying your qdiscs actually
>  works? For the WiFi interfaces with 'noqueue' you *cannot* apply a
>  different qdisc (which also answers your question #2).

Hmm. Unless I’m missing something, what I’m seeing is that I _can_ add another 
qdisc, only that it’s ineffective unless soft rate limiting is used. As 
evidence, here's my nolimit test of fq_codel:

http://www.drhleny.cz/bufferbloat/fq_codel_nolimit/index.html 


Under the sections qos_om1 and qos_om2, you can see that fq_codel has been 
added to wlan0 from the tc output. But the latency is the same 25 ms as the 
default, so I’m not controlling the queue, and that was true for any qdisc 
without rate limiting.

But, here's ‘40mbit full-duplex rate limiting on the AP and station with 
htb+fq_codel’:

http://www.drhleny.cz/bufferbloat/fq_codel_fd-wifi-both_40mbit/index.html 


With this, I could reduce latency to about 9ms, so it did “something”. And 
pfifo with 40mbit rate limiting did the “something” that it usually does, 
bloating things up to 200+ ms:

http://www.drhleny.cz/bufferbloat/pfifo_fd-wifi-both_40mbit/index.html 


So I don’t see any evidence that I can’t add a qdisc to the Wi-Fi devices, only 
that I have to use soft limiting for it to be effective.

Now, HTB rate limiting seems to break down on the OM2P-HS at bitrates above 
about 50mbit, when the actual throughput starts to fall away from the set 
limit, but that’s another story.

> Question 1 (and partly #13): Yeah, the version of LEDE you're running
> already has the FQ-CoDel-based queueing in the ath9k driver. The
> baseline you're seeing is consistent with the results we've been getting
> in testing. This is also seen by any gains you get being paired with
> quite a hefty hit in throughput. So with this driver, I would say it's
> not worth it. However, this is going to be different on a setup without
> the WiFi queueing fixes.

Ok, that explains a lot, thanks. I was still able to see about a 50% reduction 
in latency (from ~25 ms to ~12ms) with a 13% drop in throughput (from ~92 Mbps 
to ~80Mbps), when doing half-duplex rate limiting to 85Mbps and fq_codel’ing on 
the external router. See:

http://www.drhleny.cz/bufferbloat/fq_codel_hd-eth-ap_85mbit/index.html 


vs the default:

http://www.drhleny.cz/bufferbloat/default/index.html 


I can get down to 10ms if I give up another 5 Mbps, or lower values with more 
severe throughput sacrifices.

But this is with a stable RSSI of around -50 and low noise. I understand that 
fq-codel’ing in the driver must be superior in its handling of rate changes, 
retries or other external factors, and that point-to-multipoint is a different 
story. But maybe some of FreeNet’s line-of-sight point-to-point links may also 
be stable enough such that fixed software rate limiting is usable for them, I’m 
not sure yet.

It’s not critical, but why am I able to see this level of reduction when 
there’s already fq-codel in the driver? 25ms is very good, I only wonder where 
I’m getting the extra 10-15ms from, out of interest. :)

> Question 5: For TCP you can't get packet loss from user space; you'll
> need packet captures for that. So no way to get it from Flent either.
> You can, however, get average throughput. Look at the box plots; if you
> run multiple iterations of the same test, you can plot several data
> files in a single box_combine plot, to get error bars. `flent
> file.flent.gz -f summary` (which is the default if you don't specify a
> plot) will get you averages per data series; or you can extract it from
> the

[Cake] conntrack lookup continuation

2017-01-31 Thread Felix Resch 
Hoi! 

(longtime lurker here)

Since we now already do the conntrack-lookup for the nat keyword, would it be 
expensive to implement a kind of internal conntrack-mark-and-restore by 
cake-tin?

E.g. when traffic leaves throu canke tin#x, the conntrack entry will get a 
fwmark and return traffic is put in the corresponding tin/bin on the ingress 
cake.

cheers
felix
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] [Make-wifi-fast] flent testers wanted prior to next release

2017-01-31 Thread Toke Høiland-Jørgensen 
"Klatsky, Carl"  writes:

> Finally had some time to get to this request. I downloaded the current git
> version of Flent and was able to launch the flent-gui on Windows. I had some 
> old
> test *.flent.gz results files which loaded just fine. I tried to open the test
> files that were linked from Pete Heist mail "[Cake] Flent results for
> point-to-point Wi-Fi on LEDE/OM2P-HS available". Those files did not load for
> some reason.
>
> Note, in Windows I am only using Flent to view results files in the
> GUI. I do not use it to launch tests from Windows.

It would be helpful if you could turn on debug logging and exception
debugging in the GUI, or run with -L logfile.txt from the command line,
and post the resulting log entries (after trying to load the files that
didn't work) somewhere... :)

-Toke
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] flent testers wanted prior to next release

2017-01-31 Thread Klatsky, Carl 
Finally had some time to get to this request.  I downloaded the current git 
version of Flent and was able to launch the flent-gui on Windows.  I had some 
old test *.flent.gz results files which loaded just fine.  I tried to open the 
test files that were linked from Pete Heist mail "[Cake] Flent results for 
point-to-point Wi-Fi on LEDE/OM2P-HSavailable".  Those files did not 
load for some reason.

Note, in Windows I am only using Flent to view results files in the GUI.  I do 
not use it to launch tests from Windows.

Regards,
Carl Klatsky

-Original Message-
From: Cake [mailto:cake-boun...@lists.bufferbloat.net] On Behalf Of Dave Taht
Sent: Tuesday, December 20, 2016 2:03 PM
To: bloat ; flent-us...@flent.org; 
cerowrt-de...@lists.bufferbloat.net; cake@lists.bufferbloat.net; 
make-wifi-f...@lists.bufferbloat.net
Subject: [Cake] flent testers wanted prior to next release

Toke has been busy adding new features to the flent network test tool.
I consider it *almost* stable enough for a new release. Some of the development 
has been focused on making the flent-gui much faster and more responsive (as 
our data sets have got larger), others on providing better default command line 
output, and there's other fixes across the board, including QT5 support.

In particular, I fear we've broken windows users of flent. I would dearly like 
it if some more folk out there using flent could pull the latest git version 
and see if there are any new bugs or regressions in it, any of the the 87 
tests, and the plotters, before freezing the code for a new year's release.

github: https://github.com/tohojo/flent
main site: https://flent.org/

While you are at it, please feel free to stress out any of the flent servers as 
a target, give the new cake a shot and compare it against
htb+fq_codel or your aqm of choice, or fiddle with the new wifi code,
and share your data. tcp_nup, tcp_ndown, rrul, rrul_be remain the main tests, 
but the square wave one is turning out interesting :)

And if you have any feature requests or bugs to file, please get them in soon 
to the github!

We could also use better documentation and tutorials for use... some more 
example scripts leveraging things like the cpu_stats and qdisc_stats tools, and 
so on,

Active public servers include:

flent-freemont.bufferbloat.net
( this is colocated with flent-bbr-west which has bbr on by default - an 
interesting test might be testing both these servers at the same time via the 
rtt_fair* tests from your location)

flent-dallas.bufferbloat.net
flent-london.bufferbloat.net
flent-tokyo.bufferbloat.net
flent-newark.bufferbloat.net

There are also netperf-west and netperf-east and netperf-eu and no doubt a few 
others.

We plan to add a few BBR enabled servers over the holidays.

The changelog so far:


- Support PyQt5 in the GUI (and prefer it over PyQt4). If PyQt5 is not found, 
fall back to PyQt4.


- Add new SummaryFormatter that outputs mean and median values for each data 
series. This is the new default formatter, meaning that its output will be 
shown after a test run if no other formatter (or plot) is specified.

- Support multiprocessing in the GUI. When loading several plots at once, 
plotting will now be passed off to separate worker processes.

  This allows plotting to use all the available processors on the machine, and 
speeds up loading of many plots tremendously (initial load is sped up by an 
order of magnitude). This change also means that re-plotting on config changes 
will be done dynamically in the background, which makes the GUI more responsive.

- Make text completely black in the default colour scheme. This increases 
contrast, and helps legibility, especially on printed figures.


- Some internal code changes: Port command line parser from the old optparse 
class to the newer argparse, and fix a bunch of linter


--
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake