Re: [Bloat] better testing, linux 3.6.1, cerowrt credits, other stuff
Dave Taht writes: > Moving rapidly up on my own list of priorities is developing at least > a spec for better tests. Help? This is probably not what you meant, but I thought I'd use this occasion to post it anyway: I am doing a project about bufferbloat at my university (I'm a master student), which involves testing for bufferbloat and testing various qdisc's performance in a controlled environment. I've been doing my tests by running concurrent netperf instances (so far TCP_STREAM, TCP_MAERTS and TCP_RR) and collecting the results. To make this a bit easier I've written a small Python script to automate running the various netperf instances and collecting the results. I thought I'd share it here in case anyone else thinks it's useful. It's quite crude, but works slightly better than a shell script for my purposes. :) The code is available on github: https://github.com/tohojo/netperf-wrapper Oh, and in case you have any testing you'd like me to do, I'd be happy to incorporate it. I can pretty much organise the project any way I want, and it would be cool to do something that's useful for things other than satisfying my own curiosity. ;) Cheers, -Toke -- Toke Høiland-Jørgensen t...@toke.dk pgpa9p8XezatS.pgp Description: PGP signature ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] [Codel] better testing, linux 3.6.1, cerowrt credits, other stuff
Rick Jones writes: Hi Rick Thanks for your feedback. > The script looks reasonable. Certainly cleaner than any Python I've > yet written :) I might be a little worried about skew error though > (assuming I've not mis-read the script and example ini file). That is > why I use the "demo mode" of netperf in > http://www.netperf.org/svn/netperf2/trunk/doc/examples/bloat.sh though > it does make the post-processing rather more involved. Ah, I see. I'll look into that. As far as I can tell from that script, you're basically running it with the demo mode enabled, and graphing the results with each line as a data point? There's a comment about using negative values for -D to increase accuracy at a cost of performance. Is this cost significant? And if it is, would there be any reason why it wouldn't be possible to just use positive values and then fix the error by interpolating values to be at fixed intervals when graphing? > I see you are running the TCP_RR test for less time than the > TCP_STREAM/TCP_MAERTS test. What do you then do to show the latency > without the bulk transfer load? I ran the TCP_RR test by itself to get a baseline result. The idea with the different lengths is to start the streams, wait two seconds, and then run the roundtrip so that it finished two seconds before the streams (i.e. the roundtrip test is only running while the streams are). This is for my test setup, which is just a few computers connected with ethernet; so no sudden roundtrip variances should occur. I can see how it would be useful to get something that can be graphed over time; I'll try to look into getting that working. > I was thinking of trying to write a version of bloat.sh in python but > before I did I wanted to know if python was sufficiently available in > most folks bufferbloat testing environments. I figure in > "full-featured" *nix systems that isn't an issue, but what about in > the routers? Is there any reason why it wouldn't be possible to run the python script on a full-featured machine and run the netperf instances via an ssh tunnel on the router (on a different interface than the one being tested, of course)? And since Dave replied while I was writing this, I'll just continue straight on: > That said, there is a start at lua wrappers as well as various > post-processing scripts for things like gnuplot in my deBloat repo on > github. The last time I got serious about getting something more > conventionally publishable is in > https://github.com/dtaht/deBloat/tree/master/test/results I'll go digging in there for ideas for tests to add. And probably just have a general look around. > But: It became obvious fast that long RTT tests were needed, which > I've been trying to establish the infrastructure to do I assume that by "infrastructure" you mean "(netperf) servers far away"? What would be needed for a test server in terms of resources (bandwidth and otherwise)? I could try and persuade my university to let me setup a test server on their network (which is in Denmark)... > I'm tickled Toke is also dumping stuff into org-mode, which makes > publishing content much easier from emacs. Well, I'm keeping my notes in org mode, so it seemed like the thing to do. My plan was (is) to add other output formatter(s) if I needed to output to something different. > Coherently tracking certain other variables (such as the actual tc > qdisc line and sampling tc -s statistics across an interval) across > tests is also needed. This is on the router, I assume? Is that just running the tc command and parsing the output? And if so, any ideas for a good way to timestamp it? `date && tc -s` or? -Toke -- Toke Høiland-Jørgensen t...@toke.dk pgpmQisrgsubE.pgp Description: PGP signature ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] [Codel] better testing, linux 3.6.1, cerowrt credits, other stuff
Rick Jones writes: > Mostly. The smallest step size in rrdtool is one second, so I create > rrd's with that as the step size, but I try for sub-second samples > from the interval results to mitigate (or try to) some of rrdtools > averaging. Right. I now have the runner script parsing netperf demo output and aligning the time steps, complete with interpolation and everything (I think; I've looked at the numbers and it seems reasonable, but I'll try graphing the raw numbers along with the interpolated values and see if it looks good there too). I've tried running it with a long _RR test and then after a few seconds starting the _STREAM and _MAERTS tests. That produces output like the attached table. The next step will probably be adding some kind of graphing capability; probably using matplotlib. It should also be fairly straight forward to add parsers for different kinds of data, time series or otherwise. But that will probably be something I'll look at as I need them, and/or when I get around to poking around Dave's test repository. Anyway, feedback is quite welcome. Running the sample config files in the repository should be possible by just changing the -H parameter for netperf. The code is, as before, at: https://github.com/tohojo/netperf-wrapper -Toke -- Toke Høiland-Jørgensen t...@toke.dk | Time | IN | OUT | RR | |--+--+---+-| | 0.0 | None | None | 2218.57 | | 0.5 | None | None | 2253.46 | | 1.0 | None | None | .40 | | 1.5 | None | None | 2138.08 | | 2.0 | None | None | 2195.81 | | 2.5 | None | None | 2162.87 | | 3.0 | None | None | .10 | | 3.5 | None | None | 2109.51 | | 4.0 | None | None | 2227.86 | | 4.5 | None | None | 2132.96 | | 5.0 | 7.97 | 7.93 | 253.65 | | 5.5 | 9.16 | 6.50 | 21.16 | | 6.0 | 9.25 | 6.09 | 11.56 | | 6.5 | 9.25 | 6.11 |9.52 | | 7.0 | 9.21 | 6.31 |8.44 | | 7.5 | 9.25 | 6.26 |7.03 | | 8.0 | 9.24 | 5.69 |5.41 | | 8.5 | 9.24 | 6.15 |4.97 | | 9.0 | 9.27 | 5.97 |4.40 | | 9.5 | 9.24 | 6.16 |3.97 | | 10.0 | 9.23 | 6.09 |3.66 | | 10.5 | 9.27 | 5.98 |3.40 | | 11.0 | 9.23 | 5.91 |3.14 | | 11.5 | 9.25 | 5.86 |2.89 | | 12.0 | 9.27 | 5.92 |2.83 | | 12.5 | 9.21 | 6.58 |2.69 | | 13.0 | 9.26 | 7.11 |2.46 | | 13.5 | 9.20 | 7.57 |2.36 | | 14.0 | 9.22 | 8.55 |2.29 | | 14.5 | 9.15 | 27.59 |2.17 | | 15.0 | None | None |2.05 | | 15.5 | None | None | 189.71 | | 16.0 | None | None | 1514.06 | | 16.5 | None | None | 2231.55 | | 17.0 | None | None | 2232.87 | | 17.5 | None | None | 2213.76 | | 18.0 | None | None | 2217.52 | | 18.5 | None | None | 2212.16 | | 19.0 | None | None | 2180.91 | pgppBTkamdWIQ.pgp Description: PGP signature ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] plots
Dave Taht writes: > The *.svg of high bandwidths is nice, the *.ps of low is not so much. Yeah, I see your point. > 1) I think the way to fix the upload plot is to use a larger sample > interval, like 1 second, when dealing with low bandwidths. Well, the reason for missing data is that netperf "misses its deadlines" so to speak. I.e. we tell it to output intermediate results every 0.1 seconds, and it only does so every 0.5. As I understood Rick's explanation of how netperf's demo mode works, the problem with missing deadlines is that netperf basically tries to guess how much data it will send in the requested interval, and then after having sent that much data it checks the time to see if it's time to output an intermediate result. So if the data transfer rate is slower than expected, the deadline will be missed. Using negative numbers for the interval makes it check the time every time it sends something, but it still needs to send a bit of data between every check, and if that takes too long the holes will appear. Using a longer sampling interval for the entire plot might alleviate this, I suppose, but since we're measuring bytes sent per second, doing so amounts to averaging subsequent points; so is there any reason why we can't just do the averaging over the data we already have (i.e. just increase the interpolation interval)? If we do want to increase the actual sampling interval, do you propose to do so only for low-bandwidth tests? Because in this case we would either need to detect when the bandwidth is low and adjust parameters, or there would have to be two versions of the test: a low-bandwith and a high-bandwith version. > 2) I am really hating losing the outliers entirely. In particular, > > Getting a second ping plot that used a cdf would be more accurate and > revealing. I agree that this is not optimal, and I've been thinking that I would like to decouple the data gathering part from the plotting part a bit. I.e. making it possible to specify a test that gathers a lot of data (could add in tc stats for instance) and saves it, and then specify several sets of plots to do on that data. CDF would be one of them, another one could be a simpler plot that plots the average (or total) upload and download with just the ping, similar to the simple plots we did with just two streams. And I'm sure we can come up with more. Export would still be there, of course; in fact, I was planning to switch to using json as the native storage format. I still have a way to go on my project writing before I get to doing the tests for myself, but I can try and interleave some work on netperf-wrapper to get the above changes in there? :) -Toke -- Toke Høiland-Jørgensen t...@toke.dk pgpaKrxiXql0U.pgp Description: PGP signature ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
[Bloat] Update of netperf-wrapper testing tool - new features, CDF plots
Hey everyone I've just pushed an update to the netperf-wrapper testing tool which allows several different plots to be created from the same dataset, including CDF plots from ping times. The reworked configuration file format also allows for more flexibility in specifying tests (since the configuration format is now full Python source), which allows more options to be specified on the command line when running the tests (such as test length, proper ipv4/6 handling with -4 and -6 parameters, etc). Test data is now also saved in a json format at each test run (along with relevant metadata), hopefully making it easier to keep track of test data, and possibly at some point in the future allowing for interoperability with other tools. Get the source from github (https://github.com/tohojo/netperf-wrapper) and give it a spin. The main test is the rrul stress test (prototyping Dave's draft specification), but simple one- or two-stream TCP tests are also available. To get started and run the rrul test, seeing a CDF plot of the ping times, execute the following commands: git clone https://github.com/tohojo/netperf-wrapper.git cd netperf-wrapper ./netperf-wrapper.py -H -p ping_cdf rrul Provided there's a 'python2' executable available in the PATH, that matplotlib is installed correctly, and that a netperf built with demo mode is available, this will run the rrul test and pop up an interactive plot browser of the results. It will also save the test data in rrul-.json.gz for later export to csv, plotting etc. See ./netperf-wrapper.py -h and the README file for further options. -Toke -- Toke Høiland-Jørgensen t...@toke.dk pgpEqADAgL9Tu.pgp Description: PGP signature ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] FQ_Codel lwn draft article review
Dave Taht writes: > I keep noting that the next phase of the rrul development is to find a > good pair of CIR one way measurements that look a bit like voip. > Either that test can get added to netperf or we use another tool, or > we create one, and I keep hoping for recommendations from various > people on this list. Come on, something like this exists? Anybody? I came across this in the iperf documentation: "Jitter calculations are continuously computed by the server, as specified by RTP in RFC 1889. The client records a 64 bit second/microsecond timestamp in the packet. The server computes the relative transit time as (server's receive time - client's send time). The client's and server's clocks do not need to be synchronized; any difference is subtracted out in the jitter calculation. Jitter is the smoothed mean of differences between consecutive transit times." http://iperf.fr/#tuningudp Iperf seems to output jitter measurements on the *server* side when doing UDP transfers. So incorporating this into netperf-wrapper would require either some way to notify a server to start up an iperf instance sending to the client (and finding some way to persuade firewalls/NATs on the way to let the packets through), or create a server-side wrapper that monitors the server-side output and sends it to the client on request via some sort of rpc. The latter should be pretty straight forward, I suppose. And if I recall correctly, you did want to measure the upstream jitter? -Toke -- Toke Høiland-Jørgensen t...@toke.dk pgpLrbMjkipCm.pgp Description: PGP signature ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] FQ_Codel lwn draft article review
Toke Høiland-Jørgensen writes: > The latter should be pretty straight forward, I suppose. And if I recall > correctly, you did want to measure the upstream jitter? Following up on this, I've created a proof of concept python script that starts an iperf server in the background, parses the output, and presents a command line interface that dumps the parsed data in json format when asked for a transfer ID (source port number). The script is available here: https://github.com/tohojo/netperf-wrapper/blob/master/misc/iperf-server.py It should be pretty easy to make it listen to a socket instead and allow clients to request 'their' data. If anyone thinks this will be useful, I'll be happy to poke some more at it. :) -Toke -- Toke Høiland-Jørgensen t...@toke.dk pgpsdKehJYMA2.pgp Description: PGP signature ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] [Cerowrt-devel] FQ_Codel lwn draft article review
dpr...@reed.com writes: > iperf is a "hot rod" test. The UDP versions ignores congestion signals > entirely, and thus is completely irrelevant to bufferbloat. Well I wasn't going to run it at full speed (whatever that might mean), but limit it to a relatively low speed, to get the jitter measurements for UDP in the hope they'd be a decent indication for how a voip call might fare on the same connection. If you have ideas for a better tool, I'm all ears. :) The other tests are done with netperf and good old ping. -Toke -- Toke Høiland-Jørgensen t...@toke.dk pgpFZvrmGDl0D.pgp Description: PGP signature ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] [Cerowrt-devel] FQ_Codel lwn draft article review
Oliver Hohlfeld writes: > The jitter measurements you have in mind will give you an idea on the > jitter specific to the chosen traffic scenario, nothing more --- and > in particular not the VoIP quality (although low vs. high jitter could > /indicate/ certain /possible/ quality degradations). Well no, in this sense the only "real" test for voip quality is picking up the (soft)phone and talking to someone. However, since the context here is automated measuring tools (preferably generating solid quantitative, comparable data), that is hardly feasible. I guess the goal of a comprehensive testing suite is to gather as many indicators of quality degradations (in the widest possible sense) as possible and testing for them under a variety of traffic conditions. I am by no means an expert on VoIP, but someone suggested measuring jitter could be useful, and I've proposed a possible way to do that (using iperf udp flows at a low-ish bandwidth). Since for the purpose of this particular discussion I seem to be in the test tool building business (at least for the time being), what I really need before going forward with this is someone to comment on (a) if using iperf udp flows is a valid way to measure jitter, (b) if measuring jitter is actually something someone wants to do and (c) if there are other tests that would be useful for testing VoIP (or general) conditions instead of / in addition to the jitter measurements. So far I don't have an answer to (a), only negative answers to (b) and nothing concrete for (c). So for the time being I'm shelving the idea, and will just note that it seems quite feasible to return to it should someone change their mind on (b) :) -Toke -- Toke Høiland-Jørgensen t...@toke.dk pgpSnsJWURolF.pgp Description: PGP signature ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Bufferbloat Paper
Stephen Hemminger writes: > The tone of the paper is a bit of "if academics don't analyze it to > death it must not exist". The facts are interesting, but the > interpretation ignores the human element. If human's perceive delay > "Daddy the Internet is slow", then they will change their behavior to > avoid the problem: "it hurts when I download, so I will do it later". Well severe latency spikes caused by bufferbloat are relatively transient in nature. If connections were constantly severely bloated the internet would be unusable and the problem would probably (hopefully?) have been spotted and fixed long ago. As far as I can tell from their graphs, ~5% of connections to "residential" hosts exhibit added delays of >=400 milliseconds, a delay that is certainly noticeable and would make interactive applications (gaming, voip etc) pretty much unusable. Now, I may be jumping to conclusions here, but I couldn't find anything about how their samples were distributed. However, assuming the worst, if these are 5% of all connections to all peers, each peer will have a latency spike of at least 400 milliseconds for one second every 20 seconds (on average). Which is certainly enough to make a phone call choppy, or get you killed in a fast-paced FPS. It would be interesting if a large-scale test like this could flush out how big a percentage of hosts do occasionally experience bufferbloat, and how many never do. -Toke -- Toke Høiland-Jørgensen t...@toke.dk pgp5ycyXa5SZQ.pgp Description: PGP signature ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Bufferbloat overview article
Tristan Seligmann writes: > https://mithrandi.net/blog/2013/02/a-brief-history-of-bufferbloat/ Nice writeup. :) > I'll probably also take a crack at packaging some of the tools > (such as netperf-wrapper) that aren't currently available as Debian > packages. Excellent! I'll be happy to include the packaging-specific files into the netperf-wrapper git repository (there's currently a PKGBUILD for Arch Linux there); just email me, or send a pull request on github. :) -Toke pgpLf8zWhqXHQ.pgp Description: PGP signature ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
[Bloat] Packages of netperf 2.6 and netperf-wrapper for Arch and Debian/Ubuntu
I've finally managed to package netperf-wrapper and an up-to-date (i.e. 2.6) version of netperf for Arch, Debian and Ubuntu Linux. For those interested, the packages are available in a set of package repositories located at http://archive.tohojo.dk/ . There are README files explaining the use and right package manager incantations to use them. I've tested these packages on Arch, on Debian Squeeze and Ubuntu 12.04 (precise) and 12.10 (quantal). Comments / testing etc is of course welcome; this is my first foray into Debian packaging. The Arch repository has a packaged version of Dave's debloat script as well, with a systemd unit file to run it. I'm planning to package that up for Debian and Ubuntu as well, but am taking a break for the night after fighting the deb packaging tools for way too long... ;) -Toke pgpLsz5LH0KtI.pgp Description: PGP signature ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
[Bloat] Describing fq_codel
I recently had occasion to describe the scheduling mechanism in fq_codel
in plain text. I thought this might be useful to have for general
reference somewhere, so I'm posting it here to elicit comments and have
a plan to post it to the bufferbloat wiki somewhere afterwards.
See below.
-Toke
FQ_CODEL
The fq_codel queueing discipline in Linux is an implementation of a
somewhat modified stochastic fairness queueing algorithm, with CoDel
added as an AQM for the individual queues. As such, it consists of two
parts: the scheduler which selects which queue to dequeue a packet from,
and the CoDel AQM which works on each of the queues built in to the
qdisc. The subtleties of fq_codel are mostly in the scheduling part,
which is the subject of this description. For a description of CoDel,
refer to Kathy and Van's paper[1].
The interaction between the scheduler and the CoDel algorithm are fairly
straight forward: At initiation (i.e. at boot, or when fq_codel is first
installed on the interface, or its parameters are changed), the list of
queues is initialised so that each queue has a separate set of CoDel
state variables. By default, 1024 queues are created, and packets are
hashed into them at enqueue time. Each queue maintains the CoDel state
variables throughout its lifetime, and so acts the same as the non-fq
CoDel variant would (including retaining the control law state when the
queue drains, etc).
As for the scheduler, it is different from a straight-forward conceptual
SFQ scheduler[2] in a number of respects:
- fq_codel is byte-based, employing a deficit round-robin mechanism[3]
between queues. The quantum is configurable, but defaults to the
interface MTU. This means that if one flow sends packets of size
MTU/3, and another sends MTU-sized packets, the first flow will
dequeue three packets each time it gets a turn, whereas the second
flow only dequeues one. This is kept track of by maintaining a byte
dequeue deficit for each queue, which is first initialised to the
quantum value, and decreased by the packet size on each dequeue from
the queue.
- Queue space is shared: there's a global limit on the number of packets
the queues can hold, but not one per queue. If the space runs out at
enqueue time, the queue with the largest number of *bytes* in it will
get a packet dropped. This means that the packet being enqueued will
pretty much never be dropped; rather a different packet is dropped,
and not necessarily from the same queue. Packets are always dropped
from the head of a queue.
- fq_codel maintains two lists of active queues, called "new" and "old"
queues ("new" and "old" being the terms used in the code). When a
packet is added to a queue that is not currently active, that queue is
added to the list of new queues. This is the source of some subtlety
in the packet scheduling at dequeue time, explained below.
- Most of fq_codel's scheduling is done at packet dequeue time. It
consists of three parts: selecting a queue from which to dequeue a
packet, actually dequeuing it (employing the CoDel algorithm in the
process), and some final bookkeeping.
For the first part, the scheduler first looks at the list of new
queues; for each queue in that list, if that queue has a negative
deficit (i.e. it has already dequeued a quantum of bytes (or more)),
its deficit is increased by one quantum, and the queue is put onto the
end of the list of old queues, and the routine starts again.
Otherwise, that queue is selected for dequeue. If the list of new
queues is empty, the scheduler proceeds down the list of old queues in
the same fashion (checking the deficit, and either selecting the queue
for dequeuing, or increasing the deficit and putting the queue back at
the end of the list).
After having selected a queue from which to dequeue a packet, the
CoDel algorithm is invoked on that queue. This applies the CoDel
control law in the usual fashion, and may discard one or more packets
from the head of the queue, before returning the packet that should be
dequeued (or nothing if the queue is or becomes empty while being
handled by the CoDel algorithm).
Finally, if the CoDel algorithm did not return a packet, the queue is
empty, and the scheduler does one of two things: if the queue selected
for dequeue came from the list of new queues, it is moved to the end
of the list of old queues. If instead it came from the list of old
queues, that queue is removed from the list, to be added back (as a
new queue) the next time a packet arrives that hashes to that queue.
Then, (since no packet was available for dequeue), the whole dequeue
process is restarted from the beginning.
If, instead, the scheduler *did* get a packet back from the CoDel
algorithm, it updates the byte deficit for the selected queue before
returning the packet to the lower layers of the kernel networking
stack for sending.
The new/old queue distinction has a partic
[Bloat] Internet in Sweden is pretty good...
So I got a new flat in Sweden with ethernet-to-the-wall 100/100 Mbps internet (for ~$50/month. The municipality owns the infrastructure and providers offer service; I had 9 different providers to pick from). Did some measurements with my laptop plugged in to it. One plot is just plugging in the laptop without fiddling with any settings (other than having fq_codel as the system-wide default qdisc): http://files.toke.dk/bufferbloat/data/karlstad/rrul-2014-02-08T010909.617794.Laptop_plugged_into_apt_wall.png The second one is after putting in an HTB shaper: http://files.toke.dk/bufferbloat/data/karlstad/rrul-2014-02-08T142522.645782.Laptop_htb_105_110Mbps.png And a CDF for comparison: http://files.toke.dk/bufferbloat/data/karlstad/cdf_comparison.png All the data is available at http://files.toke.dk/bufferbloat/data/karlstad/ including the HTB script that set things up. In conclusion: Wh! :D Now to find a router that can handle HTB at those speeds... -Toke signature.asc Description: PGP signature ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Describing fq_codel to a layperson
Rich Brown writes: > So I'm posting this version to elicit comments and have a plan to post > it to the bufferbloat wiki somewhere afterwards. Hi Rich I like the writeup, however I'm probably not the best person to validate how it will sound to an outsider... One things, though... > Imagine a ski shop with one employee. That employee handles > everything: small purchases, renting skis, installing new bindings, > making repairs, etc. He also handles customers in first-come, > first-served order, and accepts all the jobs, even if there's already > a big backlog. Imagine, too, that he never stops working with a > customer until their purchase is complete. He never goes out of order, > never pauses a job in the middle, not even to sell a Chapstick. Sometimes I feel like this describes way too many actual ski shops (or maybe not ski shops, but certainly other establishments)... I.e. I'm not sure it is really that obvious of an absurdity as one would think; maybe stating more explicitly what a ski shop 'ought' to do would help? -Toke signature.asc Description: PGP signature ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Describing fq_codel
Jesper Dangaard Brouer writes: > Thank you Toke for this excellent description, it is really good! Thanks! > And where do you plan to put this excellent description (so its more > accessible to mankind)? Planning to stick it on the bufferbloat wiki somewhere, once I deem people have had enough of a chance to comment. So probably sometime in the coming week. Will link it here once I do :) -Toke signature.asc Description: PGP signature ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Describing fq_codel
Toke Høiland-Jørgensen writes: > Planning to stick it on the bufferbloat wiki somewhere, once I deem > people have had enough of a chance to comment. So probably sometime in > the coming week. Will link it here once I do :) Right, so stuck it on the wiki pretty much as it was posted to the list. Link: http://www.bufferbloat.net/projects/codel/wiki/Technical_description_of_FQ_CoDel -- also linked from the front page of the CoDel wiki. :) -Toke signature.asc Description: PGP signature ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
[Bloat] Draft on fq_codel submitted
Hi everyone This is to notify you of the availability of a draft explaining the fq_codel algorithm. It is available from here: http://datatracker.ietf.org/doc/draft-hoeiland-joergensen-aqm-fq-codel/ Thanks, -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] AQM creeping into L2 equipment
Dave Taht writes: > The standard test that I'm most interested in is the 2 ports into 1 topology: > > SOURCE > | > SWITCH > || > BOX1 BOX2 Did a couple of tests of this with the default configuration of a Cisco WS-C2960X-24TD-L switch. Graphs and data files here: http://kau.toke.dk/experiments/cisco-switch/cisco-c2960x.html Conclusion: My test boxes need offloads and quite a bit of driver queueing to drive the 1Gbps link, which makes it difficult to say anything about the switch... Haven't fiddled with the QoS settings, but from what I can see they are rather limited, and takes a great deal of fiddling to setup (at least for someone who, like me, has pretty much zero experience with Cisco gear). If someone has suggestions for other switch configurations that would be worthwhile testing (as well as some help on how to configure it), I'll be happy to run the tests. -Toke signature.asc Description: PGP signature ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] AQM creeping into L2 equipment
Dave Taht writes: > I find it puzzling that you still lose the measurement flows early on. > Setting some QoS on via WTD might be interesting. Well if you can be more specific, I'll be happy to. Was looking for a way to have per-protocol QoS settings, but there does not seem to be any From the documentation (only IP-based). > If you have a later OS than 3.13 on the sources/sinks you might want > to try sch_fq (and sch_pfifo_fast for reference) - the improvements to > Linux's TCP are such that on a short path like this that the control > loop stays very tight - only two TSO offloads per flow, really > accurate use of tcp timestamps, etc. Added a result set with sch_fq in place of fq_codel to the bottom of the same page. Doesn't appear to make much of a difference... > See also if you have hardware flow control enabled (via ethtool) If by that you mean pause frames, ethtool seems to think not: Settings for eth2: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supported pause frame use: No Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Port: Twisted Pair PHYAD: 1 Transceiver: internal Auto-negotiation: on MDI-X: off Supports Wake-on: d Wake-on: d Current message level: 0x0007 (7) drv probe link Link detected: yes -Toke signature.asc Description: PGP signature ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] AQM creeping into L2 equipment
Dave Taht writes: > I imagine with the new tcp's pfifo_fast is going to be sub 8ms also. Yeah, turns out I botched the qdisc setup (put it on the wrong interface on one of the servers) for the case with no switch. So the ~6ms was with pfifo_fast in one end. Updated the original graphs for the host-to-host. Data capture files are here: http://kau.toke.dk/experiments/cisco-switch/packet-captures/ -- no idea why the client seems to capture three times as many packets as the server. None of them seem to think they've dropped any (as per tcpdump output). Will add dumps from going through the switch in a bit... > Is your hardware fast enough to run tcpdump -s 128 -w whatever.cap -i > your interface during an entire rrul test without dropping packets? > (on client and server) Well, as above, tcpdump doesn't say anything about dropped packets; but since the client dump is way bigger, perhaps the server-side does anyway? -Toke signature.asc Description: PGP signature ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] AQM creeping into L2 equipment
"Steinar H. Gunderson" writes: > I'm a bit confused if a normal machine these days can't easily > saturate gigabit (and capture it to SSD without further problems), > though. Well, they're not entirely new; the machines I'm using are lab machines that have been replaced and are now recommissioned as my test-bed. /proc/cpuinfo says they're 'Intel(R) Core(TM)2 Quad CPUQ6600 @ 2.40GHz'. No SSD, either... They have no issues *saturating* gigabit (as long as the BQL max_limit is not set too low), but capturing, not so much... -Toke signature.asc Description: PGP signature ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
[Bloat] iOS meshing
So, apparently iOS7 has built-in mesh network capability: http://www.cultofmac.com/271225/appreciated-ios-7-feature-will-change-world/ Anyone knows anything about it? :) -Toke signature.asc Description: PGP signature ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
[Bloat] The systemd people have started doing networking
So systemd recently grew a networking component, which is apparently now capable of doing DHCP requests in 750 us... https://plus.google.com/+TomGundersen/posts/eztZWbwmxM8 Haven't had a chance to play with it yet, but if it means my laptop will be able to acquire a network connection immediately after waking up from suspend, I'll be quite happy :) -Toke signature.asc Description: PGP signature ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] [aqm] the side effects of 330ms lag in the real world
Jim Gettys writes: > Now, if someone gives me real fiber to the home, with a real switch fabric > upstream, rather than gpon life might be somewhat better (if the switches > aren't > themselves overbuffered But so far, it isn't. As a data point for this, I have fibre to my apartment building and ethernet into the apartment. I get .5 ms to my upstream gateway and about 6 ms to Google. Still measured up to ~20 ms of bufferbloat while running at 100 Mbps... http://files.toke.dk/bufferbloat/data/karlstad/cdf_comparison.png However, as that graph shows, it is quite possible to completely avoid bufferbloat by deploying the right shaping. And in that case fibre *does* have a significant latency advantage. The best latency I've seen to the upstream gateway on DSL has been ~12 ms. -Toke signature.asc Description: PGP signature ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] How is bufferbloat prevented/fixed for UDP?
Forums1000 writes: > 1) With UDP, you cannot uniquely identify a flow? This prevents an > AQM-algorithm to drop packets for an (several) offending UDP flow(s). For most cases UDP flows are determined by port number pairs, same as TCP. Multiple flows can be multiplexed over one "connection", but this is no different from TCP. > 2) Unlike TCP, UDP does not back down when encountering packet loss This is true; i.e. not back-off mechanism is built into the protocol. However, it is quite possible to build in such a mechanism in whatever protocol is running *on top of* UDP. Indeed this is done for things like real-time media protocol, and also bittorrents uTP protocol runs on top of UDP. So I guess the answer is "it all depends". As an aside, if you *do* have an unresponsive UDP flow (whether misconfigured or malignant), having a flow queueing mechanism like that of fq_codel helps a lot; the bad UDP flow is then isolated and only hurts itself, so to speak. :) -Toke signature.asc Description: PGP signature ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Comcast upped service levels -> WNDR3800 can't cope...
Jonathan Morton writes: > Looking at the code, HTB is considerably more complex than TBF in > Linux, and not all of the added complexity is due to being classful > (though a lot of it is). It seems that TBF has dire warnings all over > it about having limited packet-rate capacity which depends on the > value of HZ, while HTB has some sort of solution to that problem. Last I checked, those warnings were out-dated. Everything is in nanosecond resolution now, including TBF. I've been successfully using TBF in my experiments at bandwidths up to 100Mbps (on Intel Core2 x86 boxes, that is). -Toke signature.asc Description: PGP signature ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Comcast upped service levels -> WNDR3800 can't cope...
Jonathan Morton writes: > These tests were all run using nttpc. I wanted to finally try out > RRUL, but the wrappers fail to install via pip on my Gentoo boxes. > I'll need to investigate further before I can make pretty graphs like > everyone else. The pip package of netperf-wrapper is, unfortunately, quite outdated. I keep meaning to do a new release and upload it; will try to get around to it real soon now! :) -Toke signature.asc Description: PGP signature ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] [Cerowrt-devel] Fixing bufferbloat: How about an open letter to the web benchmarkers?
Dave Taht writes: > What if we could publish an open letter to the benchmark makers such > as speedtest, explaining how engineering for their test does *not* > make for a better internet? The press fallout from that letter, would > improve some user education, regardless if we could get the tests > changed or not. > > Who here would sign? I would! :) -Toke signature.asc Description: PGP signature ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
[Bloat] Announcing version 0.7.0 of the netperf-wrapper testing tool
Hey everyone This is to announce version 0.7.0 of the netperf-wrapper testing tool. It has been almost a year since the last numbered version release, and this release adds a bunch of new features, including several new plot types, a GUI for exploring multiple data sets, a batch run mode for configuring reproducible test runs and several new test configurations. And of course a whole bunch of bug fixes and minor tweaks. As before, the package can be downloaded from Github or pypi: https://github.com/tohojo/netperf-wrapper/releases https://pypi.python.org/pypi/netperf-wrapper or simply run `pip install netperf-wrapper`. Additionally, packages for Debian, Ubuntu and Arch Linux are available From the Open Build Service repository. Instructions at: http://software.opensuse.org/download.html?project=home:tohojo:netperf-wrapper&package=netperf-wrapper As always, comments, feature requests and bug reports are welcome! -Toke signature.asc Description: PGP signature ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] RED against bufferbloat
Michael Welzl writes: > but that's FQ (or FQ_CoDel's changed FQ variant), much more than the > AQM mechanism in use (as we have also seen presented by Toke at the > last ICCRG meeting). Well, actually, that presentation did also include an evaluation of the AQMs in an asymmetrical scenario. And that shows that while generally ARED does perform fairly well, it tends to be a bit on the aggressive side. In the asymmetrical case this results in too many drops on the slow side of the asymmetrical link (typically upload), hurting throughput in the other direction due to lost ACKs. There's also some other issues in there, with PIE and CoDel in particular, most notably their reactions when conditions change: it can take tens of seconds for the algorithms to get queueing latency under control in this case. Slides for the IETF presentation available here: http://www.ietf.org/proceedings/91/slides/slides-91-iccrg-4.pdf There's also a longer version of the talk (from the Stanford Netseminar) available on Youtube: https://www.youtube.com/watch?v=kePhqfKA3SM > But this discussion is about AQM mechanisms, not (changed)FQ. While the academic side of me enjoys studying AQMs (and I'm still far from anything resembling a thorough understanding of them), the practical "I just want my network to work" side of me has become increasingly convinced (in part by doing the experiments in the above mentioned talk) that FQ is more important than AQM in many scenarios. As such, I think that excluding FQ from the conversation is mostly of, well, academic interest ;) -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] RED against bufferbloat
Mikael Abrahamsson writes: > To me, FQ is important especially for lower speeds. This also maps > well into the CPU based nature of FQ (that it's hard to do in > "silicon"). Well my research has been mainly focused on the consumer / edge case. I.e. things a Linux box can drive in hardware, so up to 100Mbit to a Gbit depending on the size of the box. In these cases, fq_codel adds no measurable overhead compared to the CPU load of just pushing the packets. > We're not going to see FQ_CODEL on a 200 interface large router > designed to push 100 gigabit/s of traffic, at least not in any > interesting price point. Maybe not; but note that recent work in the Linux kernel makes it quite capable of pushing 40GigE, and I believe sched_fq (which does 'real' fairness queueing with a queue per flow, not hash buckets as fq_codel does) has been shown to scale to millions of concurrent flows. > Can we do bidirectional traffic FQ_CODEL on the CPE to try to achieve > basically zero loss in the AR policer for any normal kind of use > scenario using TCP. I have not seen any simulations looking at this. Well this is basically what we're doing with the SQM scripts in CeroWRT: put a software rate limiter in the CPE and configure it to a slightly lower value than whatever the cable/DSL modem runs at. This works quite well, but the software rate limiter is fairly CPU hungry, so small boxes struggle. I had to substitute a full x86 box for my Netgear router to run at 100Mbit for my home connection. > Because my belief is that even though we might say we love FQ here, > we're not going to see high speed FQ on higher end ISP aggregation > routers. So if we want FQ, we're going to have to do it in the CPEs. Well OpenWRT turns on fq_codel by default now. :) And yeah, I'm not holding by breath for big iron vendors to include fq_codel in their products. But that doesn't mean it can't go into CPEs. And end hosts and access points. And inside tunnels (VPN daemons for instance). -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] RED against bufferbloat
Michael Welzl writes: > +1, certainly it has a big influence. This has been well known for > many years though, and documented broadly, perhaps most notably by Jim > Roberts. Being "well known for many years" in the academic community unfortunately doesn't translate into deployment. Which is why I think there should be a place for both approaches: the "let's simplify and get a thorough base understanding" and the "let's run this on real stuff and see what happens". > Here I disagree, for two reasons: > > 1) The AQM part kicks in per flow. So, whenever you have one flow, the > behavior of FQ_AQM and AQM will be the same. Investigating what an AQM > mechanism does to one flow is then worthwhile. > > 2) Not everyone will always want FQ everywhere. There are potential > disadvantanges (e.g. the often mentioned with-a-VPN-I'm-only-1-flow problem). > What's necessary is to quantify them - to see how the effect of FQ (or > FQ_CoDel's changed FQ) plays out, and you've done a great start there in my > opinion. I didn't mean that investigating AQM behaviour is not worthwhile, far from it. But I believe that FQ needs to play a much larger role than it does currently in solving the larger problem of network (latency) behaviour under load. And completely separating the two is academic; not in the derogatory sense (as in "a problem not worth discussing"), but in the literal sense (as in "the thing we do in academia"). -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] RED against bufferbloat
Mikael Abrahamsson writes: > I am very much aware that this is being done (I have done it myself), > but my question was if someone had actually done this in a lab and > found out how well it works in RRUL tests etc. So you mean comparing the scenario where the AQM runs on both sides of the bottleneck to one where it runs as an ingress shaper on one side only? -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] RED against bufferbloat
Mikael Abrahamsson writes: > Right now I hear more about "virtualised CPE" to save cost (ie move > part of the CPE implementation to the data center) than to spend more > money on features in the CPE. Erm, how does that work? What part of the functionality can reasonably be moved to the data center? The configuration web interface? -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] RED against bufferbloat
Mikael Abrahamsson writes: > Basically you extend the home L2 domain via some kind of tunnel or > vlan to a server, and run the CPE there. > > The only thing left in the home is basically L2 bridging between WAN, > LAN and Wifi and the possibiliy of configuring settings such as Wifi > SSID, crypto etc. Ah, I see. Yeah, that does seem to be the wrong direction... :( -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] [Cerowrt-devel] marketing #102 - giving netperf-wrapper a better name?
>seemingly still whatever the programmer called it when he wrote the >first sketchy version, one step up from "foo"' This is accurate, BTW. I'm terrible at naming... Do yeah, what Dave said - suggestions welcome! :) -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] setting queue depth on tail drop configurations of pfifo_fast
>I would like to reduce the tail drop queue size to 100 packets (down >from the default of 1000) and see how that impacts the test. 3 seconds >of bloat is pretty bad, and I would like to compare how ABR works at at >1 second and at 200-300 ms. Did you re-initiate the pfifo_fast qdisc after changing txqlen? IIRC, it picks up the len at init time, and so won't update automatically when you change it... -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Latency Measurements in Speed Test suites
Jonathan Morton writes: > The number-one desirable feature is to carry on measuring the latency > while the throughput test is ongoing. This is relevant to anyone who > wants to make a VoIP call or play an online game while using the > connection for something else. If you have several people in one > household, it’s often hard to coordinate their activity to avoid such > multitasking. +1 on this! Otherwise pretty cool test; no plugins and manages to push quite a bit of data, at least in the upload direction: http://www.dslreports.com/speedtest/199468 -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
[Bloat] The Great Renaming (of netperf-wrapper): Final contenders
Hi everyone The Great Renaming (of netperf-wrapper) has now entered its final phase (i.e., I have to make a decision now). There's a couple of contenders for a new name, see below. I'd like some feedback on which you prefer. A simple "This one!" is fine, but reasoning about why is also appreciated, of course :) So, without further ado, the contenders are: - "ENT: The Extensible Network Tester". Possible name clash: https://packages.debian.org/sid/ent - "Exnett: The EXtensible NETwork Tester" Avoids the name clash; the second t is important for this. - "Flent: The Flexible Network Tester" 'Flent' is also the sound a bufferbloated network makes when subjected to testing :) - "NetBasher" For the first three, the abbreviation would probably be the everyday name, name of the executable, etc, with the expansion added in descriptions where appropriate. Please comment by Thursday, as I have a deadline for something that needs to include the name then... Thanks in advance! :) -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] RRUL for netperf (bad hack)
"Eggert, Lars" writes: > (I was interested in the delay an application sees on top of a TCP > stream, which is not something Toke's excellent netperf-wrapper tool > can currently do, AFAIK.) You're quite right. If a version of this makes it upstream in netperf, I'm quite happy to add in a parser for it so it can be used with the other tests in netperf-wrapper :) -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] The Great Renaming (of netperf-wrapper): Final contenders
Toke Høiland-Jørgensen writes: > The Great Renaming (of netperf-wrapper) has now entered its final phase > (i.e., I have to make a decision now). Thank you to everyone who chimed in on this, both on and off list! Netperf-wrapper will henceforth be known as "Flent: The Flexible Network Tester". Expect a release under the new name (along with a proper announcement, moving of the source code repository, etc) in the coming weeks! :) Cheers, -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] DSLReports Speed Test has latency measurement built-in
jb writes: > The graph below the upload and download is what is new. (unfortunately > you do have to be logged into the site to see this) it shows the > latency during the upload and download, color coded. (see attached > image). So where is that graph? I only see the regular up- and down graphs. http://www.dslreports.com/speedtest/320936 It shows up for this result, though... http://www.dslreports.com/speedtest/319616 -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] DSLReports Speed Test has latency measurement built-in
jb writes: > Oh my apologies, I see from your log you are using firefox+linux. Nope, chromium. The first of the two links is mine. The other one I pasted from one of the previous mails on the list; and that *does* show the under-load latency measurements. -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] DSLReports Speed Test has latency measurement built-in
jb writes: > But all is ok now, the current test does the latency thing > irregardless. Yup, works: http://www.dslreports.com/speedtest/321853 -- cool! So from that it looks like it does the under-load ping to somewhere else than the nearest endpoint? Also, can you tell what the cause of that spike just as the upload starts is? > (Unless you click 3g or GPRS). Well as someone who likes to break networks, having these measurements on 3g and GPRS as well would be interesting ;) What's the reasoning behind turning them off for those? -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] DSLReports Speed Test has latency measurement built-in
Toke Høiland-Jørgensen writes: > Yup, works: http://www.dslreports.com/speedtest/321853 -- cool! Oh, and here is a test with a FIFO queue and shaping turned off: http://www.dslreports.com/speedtest/322208 The upload latency figures are definitely iffy, but the download ones seem to match roughly what I've measured myself on this link. Also, I just noticed the legend on the latency-under-load graph says "Upoading" :) -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] DSLReports Speed Test has latency measurement built-in
Mikael Abrahamsson writes: > On Sun, 19 Apr 2015, Toke Høiland-Jørgensen wrote: > >> The upload latency figures are definitely iffy, but the download ones >> seem to match roughly what I've measured myself on this link. > > Also, I don't trust parallel latency measures done by for instance > ICMP ping. Yes, they indicate something, but what? Why not? They can be a quite useful measure of how competing traffic performs when bulk flows congest the link. Which for many applications is more important then the latency experienced by the bulk flow itself... I do agree, though, that other types of measurements are also needed. Ideally we should have good latency characteristics for *both* competing traffic and the bulk flows themselves. -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] DSLReports Speed Test has latency measurement built-in
Jonathan Morton writes: >> Why not? They can be a quite useful measure of how competing traffic >> performs when bulk flows congest the link. Which for many >> applications is more important then the latency experienced by the >> bulk flow itself. > > One clear objection is that ICMP is often prioritised when UDP is not. > So measuring with UDP gives a better indication in those cases. > Measuring with a separate TCP flow, such as HTTPing, is better still > by some measures, but most truly latency-sensitive traffic does use > UDP. Sure, well I tend to do both. Can't recall ever actually seeing any performance difference between the UDP and ICMP latency measurements, though... -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] DSLReports Speed Test has latency measurement built-in
Sebastian Moeller writes: > I know this is not perfect and the numbers will probably require > severe "bike-shedding” Since you're literally asking for it... ;) In this case we're talking about *added* latency. So the ambition should be zero, or so close to it as to be indiscernible. Furthermore, we know that proper application of a good queue management algorithm can keep it pretty close to this. Certainly under 20-30 ms of added latency. So from this, IMO the 'green' or 'excellent' score should be from zero to 30 ms. The other increments I have less opinions about, but 100 ms does seem to be a nice round number, so do yellow from 30-100 ms, then start with the reds somewhere above that, and range up into the deep red / purple / black with skulls and fiery death as we go nearer and above one second? I very much think that raising peoples expectations and being quite ambitious about what to expect is an important part of this. Of course the base latency is going to vary, but the added latency shouldn't. And sine we have the technology to make sure it doesn't, calling out bad results when we see them is reasonable! -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] DSLReports Speed Test has latency measurement built-in
Sebastian Moeller writes: > Oh, I can get behind that easily, I just thought basing the > limits on externally relevant total latency thresholds would directly > tell the user which applications might run well on his link. Sure this > means that people on a satellite link most likely will miss out the > acceptable voip threshold by their base-latency alone, but guess what > telephony via satellite leaves something to be desired. That said if > the alternative is no telephony I would take 1 second one-way delay > any day ;). Well I agree that this is relevant information in relation to the total link latency. But keeping the issues separate has value, I think, because you can potentially fix your bufferbloat, but increasing the speed of light to get better base latency on your satellite link is probably out of scope for now (or at least for a couple of hundred more years: http://theinfosphere.org/Speed_of_light). > What I liked about fixed thresholds is that the test would give > a good indication what kind of uses are going to work well on the link > under load, given that during load both base and induced latency come > into play. I agree that 300ms as first threshold is rather unambiguous > though (and I am certain that remote X11 will require a massively > lower RTT unless one likes to think of remote desktop as an oil tanker > simulator ;) ) Oh, I'm all for fixed thresholds! As I said, the goal should be (close to) zero added latency... > Okay so this would turn into: > > base latency to base latency + 30 ms: green > base latency + 31 ms to base latency + 100 ms:yellow > base latency + 101 ms to base latency + 200 ms: orange? > base latency + 201 ms to base latency + 500 ms: red > base latency + 501 ms to base latency + 1000 ms: fire > base latency + 1001 ms to infinity: fire & > brimstone > > correct? Yup, something like that :) -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] DSLReports Speed Test has latency measurement built-in
jb writes: > Ok I think I talked myself around in a complete circle: a buffer is > only bad IF it increases latency under load. Not because of its size. Exactly! :) Some buffering is actually needed to absorb transient bursts. This is also the reason why smart queue management is needed instead of just adjusting the size of the buffer (setting aside that you don't always know which speed to size it for). > It might explain why these fiber connection tests don't show much > latency change, because their buffers are really inconsequential at > those higher speeds? Well, bufferbloat certainly tends to be *worse* at lower speeds. But it can occur at gigabit speeds as well. For instance, running two ports into one on a gigabit switch can add quite a bit of latency. For some devices, *driving* a fast link can be challenging, though. So for fibre connections you may not actually bottleneck on the bloated link, but on the CPU, some other link that's not as bloated as the access link, etc... -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] bufferbloat effects on throughput
Paolo Valente writes: > If there are, could anyone please point me to further reading on these > aspects? Bufferbloat can definitely adversely affect throughput in some cases. Mainly because it causes throughput to oscillate: when the queue fills, a lot of data can be dropped at once, causing throughput to drop, which takes a while to recover. This can degrade aggregate throughput. Having smart queueing smoothes out the traffic, so the oscillations are lower and average throughput thus better. The effect is most visible when you have several flows sharing a link: when the (FIFO) queue fills, they will tend to all experience drops at once, and so all slow down. -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Detecting bufferbloat from outside a node
Paolo Valente writes: > a network-monitoring company got curious about bufferbloat issues and > asked me to investigate a little bit the following issue (quite > interesting in my opinion). Is it possible to detect, from outside a > node, if the node is bufferbloated? In particular, the only action > allowed would be to observe the packets entering and leaving the node > (plus, of course, their timing). Sure. Just measure the timing when the network is unloaded and compare it to when it is loaded to capacity. We do that all the time. The details of course depend on what you define by a 'node', what role it plays in the network (does it forward or originate packets?), and what control you have over the traffic flowing through it. :) -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Detecting bufferbloat from outside a node
Paolo Valente writes: > I am sorry, but I realized that what I said was incomplete. The main > cause of my concern is that, from outside the node, we do not know > whether a VoIP packet departs ad a given time because the application > wants it to be sent at that time or because it has waited in the > buffer for a lot of time. Similarly, we do not know how long the VoIP > application will wait before getting its incoming packets delivered. No, not unless the application tells you (by, for instance, timestamping; depending on where in the network stack the timestamp is applied, you can measure different instances of bloat). Or if you know that an application is supposed to answer you immediately (as is the case with a regular 'ping'), you can measure if it does so even when otherwise loaded. Of course, you also might not measure anything, if the bottleneck is elsewhere. But if you can control the conditions well enough, you can probably avoid this; just be aware of it. In Linux, combating bufferbloat has been quite the game of whack-a-mole over the last several years :) -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Detecting bufferbloat from outside a node
Neil Davies writes: > You are asking about the epistemology! Good start. The only things you > can “know” outside the node are the things you can observe. You can > infer, from the characteristics of the observations, conformance to > some avowed model of behaviour. If we're going all philosophy of science on this, I'll add that the nice thing about networking is that the computers attached to it can give us some very specific measurements and we can (with care) provoke quite specific behaviour to reason about the performance. Try asking a biologist about the interactions between the life cycle of parasitic species, their hosts and the ecosystem they live in! :) -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Detecting bufferbloat from outside a node
Neil Davies writes: > Take a look at http://www.pnsol.com/publications.html, you may find > http://www.pnsol.com/public/PP-PNS-2009-02.pdf as a good starting > point. I've seen this referred on the list before (I assume by you ;)), but haven't really grok'ed it before. I like the delta-Q measure as a way of thinking about overall network performance; and there's definitely parallels to thinking about the end-to-end 'latency budget', which I also find quite instructive (I think I it picked up from Joe Touch at some point). How do you deal with the fact that loss and delay can be exchanged for each other (via retransmissions)? Also, which publication would you recommend if I'm interested in specifically how you 'Mathematically model behaviour and delta-Q' as you mention in that slide set? :) -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Detecting bufferbloat from outside a node
Neil Davies writes: > The interesting thing is making all those local decisions add up to a > (set of) end-to-end outcomes, and the answer is not to make the same > decision(s) everywhere - unfortunately that doesn’t stack up. Yes, well, I do also like the E2E principle of not making too many decisions within the network, instead letting the endpoints sort it out. For me, the fight against bufferbloat is mostly about restoring the assumptions that it has eroded (i.e. "packet loss is not to be feared, but on the contrary is an important indicator that we're hitting congestion"). I'd really rather prefer the network itself to be fairly dumb... > We have (some level) of control over our “universe of discourse” - my > joke with my mates at CERN is that they only have one universe to > investigate, we can create three in one day and still be home in time > for tea! Hehe, quite. That is both fascinating and frustrating! :) -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Detecting bufferbloat from outside a node
Neil Davies writes: > I don't think that the E2E principle can manage the emerging > performance hazards that are arising. Well, probably not entirely (smart queueing certainly has a place). My worry is, however, that going too far in the other direction will turn into a Gordian knot of constraints, where anything that doesn't fit into the preconceived traffic classes is impossible to do something useful with. Or, to put it another way, I'd like the network to have exactly as much intelligence as is needed, but no more. And I'm not sure I trust my ISP to make that tradeoff... :( > We've seen this recently in practice: take a look at > http://www.martingeddes.com/how-far-can-the-internet-scale/ - it is > based on a real problem we'd encountered. Well that, and the post linked to from it (http://www.martingeddes.com/think-tank/the-future-of-the-internet-the-end-to-end-argument/), is certainly quite the broadside against end-to-end principle. Colour me intrigued. > In someways this is just control theory 101 rearing its head... in > another it is a large technical challenge for internet provision. It's been bugging me for a while that most control theory analysis (of AQMs in particular) seems to completely ignore transient behaviour and jump straight to the steady state. -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] bufferbloat effects on throughput
Paolo Valente writes: > Thanks. So, if I understood correctly, average throughput may or may > not be affected, but large throughput fluctuations will always occur > in the presence of bufferbloat. I'm always wary of saying 'always', but I'd hazard an 'often' ;) > Sorry for my usual refrain, but … any pointers to tests, results, > papers and the like? Hmm, not sure if there's any papers dealing specifically with this. However, it's quite easy to provoke this behaviour. Compare, for instance, http://files.toke.dk/bufferbloat/rrul-pfifo_fast-all_scaled.pdf with http://files.toke.dk/bufferbloat/rrul-fq_codel-all_scaled.pdf The two top graphs on each are throughput (download and upload respectively). For the aggregate behaviour, I had some data on that in my presentation at the IETF in Hawaii: http://www.ietf.org/proceedings/91/slides/slides-91-iccrg-4.pdf -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] bufferbloat effects on throughput
Paolo Valente writes: > One question: how can one be sure (if it is possible) that the > fluctuation of the throughput of a TCP flow on a given node is caused > by bufferbloat issues in the node, and not by other factors (such as, > e.g., systematic drops in some other nodes along the path followed by > the flow, with the drops possibly even caused by different reasons > than bufferbloat)? You can't, and it might. However, if you measure a performance degradation that goes away when the link is idle, consider that a hint... :) -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Detecting bufferbloat from outside a node
Neil Davies writes: > You'll find the way that ∆Q can be decomposed into basis set of ∆Q|G, > ∆Q|S and ∆Q|V - helps work out which parts of the budget get eaten up > by different elements of the network design/architecture. Right, I got that part. What I'm missing is how you define the actual measure for ∆Q -- but that is application dependent? E.g. for web sites it might be load time, for VoIP it might be MOS score? -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Detecting bufferbloat from outside a node
Neil Davies writes: > Depends on your starting point: Right, having looked a bit more at this: > - if it is "how does this relate to the end user" - look at "the > properties and mathematics of data transport quality" This mentions, on slide 30, an analytical model for predicting (changes in) ∆Q. Is this Judy Holyer's "A Queueing Theory Model for Real Data Networks", or does it refer to something else? -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Detecting bufferbloat from outside a node
Neil Davies writes: > ∆Q is both the concept (quallity attenuation - the fact that delay and > potential for loss is both conserved and only every increases[1]) and > for its representation as an improper random variable (one who's CDF > doesn't necessarily reach one). Right, got it. > One of my adages is that "network quality" doesn' t exist - just like > you can't buy a box of "dark" and make a room dark by opening the box, > you can't buy a box of "network quality" - delivering quality in > networks is managing (through bounding) the "quality attenuation" That much seems obvious. But do you have any analytical models that can actual predict the magnitude of the quality attenuation for a given network, say? And if so, are they available somewhere? Also, some of the documents linked to from your web site seems to allude to a scheduling algorithm of some sort. Is that available in paper form (or better, code!) anywhere? Thanks for your answers, will also take a look at the paper you linked in your other email. :) -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] DSLReports Speed Test has latency measurement built-in
David Lang writes: > Voice is actually remarkably tolerant of pure latency. While 60ms of > jitter makes a connection almost unusalbe, a few hundred ms of > consistant latency isn't a problem. IIRC (from my college days when > ATM was the new, hot technology) you have to get up to around a second > of latency before pure-consistant latency starts to break things. Well isn't that more a case of "the human brain will compensate for the latency". Sure, you *can* talk to someone with half a second of delay, but it's bloody *annoying*. :P That, for me, is the main reason to go with lower figures. I don't want to just be able to physically talk with someone without the codec breaking, I want to be able to *enjoy* the experience and not be totally exhausted by latency fatigue afterwards. One of the things that really struck a chord with me was hearing the people from the LoLa project (http://www.conservatorio.trieste.it/artistica/ricerca/progetto-lola-low-latency/lola-case-study.pdf) talk about how using their big fancy concert video conferencing system to just talk to each other, it was like having a real face-to-face conversation with none of the annoyances of regular video chat. -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] the dslreports png
jb writes: > I agree! but I don't want to rush. What latency should substitute? average? > median? latency during upload? download? both? should it be the excess over > idle ping, expressed as a multiplier? an absolute value? A range? So keep the base ping, but add a "bloat" value underneath it (colour-coded as appropriate)? -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] DSLReports Speed Test has latency measurement built-in
Jonathan Morton writes: > Compare these totals to twice the ITU benchmark figures, rate > accordingly, and plot on a map. A nice way of visualising this can be 'radius of reach within n milliseconds'. Or, 'number of people reachable within n ms'. This paper uses that (or something very similar) to visualise the benefits of speed-of-light internet: http://web.engr.illinois.edu/~singla2/papers/hotnets14.pdf That same paper uses 30 ms as an 'instant response' number, btw, citing this: http://plato.stanford.edu/entries/consciousness-temporal/empirical-findings.html -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
[Bloat] Announcing Flent (formerly netperf-wrapper) v0.10.0
Hi everyone
This is to announce version 0.10.0 of Flent: The FLExible Network Tester
(formerly netperf-wrapper).
This is the first release under the new name: I'm hoping not too much
broke in the transition. A list of changes since v0.9.1 is included
below.
To install the release, use `pip install flent`. Arch Linux users can
install through the AUR. Pre-built packages for Debian and Ubuntu are
available from the Open Build Service at
https://software.opensuse.org/download.html?project=home:tohojo:flent&package=flent
Please report any bugs through Github at https://github.com/tohojo/flent/issues
Thanks,
-Toke
List of changes sine v0.9.1:
- Package installation should now work through `pip` on most platforms.
In addition, two binaries are now installed: `flent` and `flent-gui`.
The latter will launch the GUI directly (corresponding to passing
--gui to the normal `flent` binary).
- The file format has changed. It now uses the .flnt extension and is
bzip'ed instead of gzip'ed. In addition, raw data as parsed from the
underlying test tools is now always included, but it has been moved
outside the 'metadata' key and resides under its own top-level key
('raw_values') in the json object. Finally, the file format is now
explicitly versioned, and a compatibility layer has been added so
Flent will still load the old .json.gz files.
- Test runners can now depend on each other, so one test tool can be
made to run when another finishes. In addition, a 'watchdog' feature
has been introduced to the runners, so one runner exiting can trigger
forceful kill of (an)other runner(s). This can be used along with the
new 'timer' runner to enforce a maximum duration of tests, but can
also be used with an external script to exit on arbitrary events; for
instance when a bandwidth quota is used up.
- Flent should now better handle unicode output from test tools under
different locales. Fixes bugs on OSX in particular, where output from
the `ping` binary can be non-ASCII.
- Flent no longer crashes on broken pipe for text-based output
formatters. Allows doing things like `flent -o csv | head` without
errors.
- A couple of new tests has been added: `rrul_50_down`, `rrul_100_up`
and `dslreports_8dn`.
- A --swap-up-down parameter has been added to swap the meaning of "up"
and "down" when running tests.
- Various bug fixes.
This release announcement is also available on Github:
https://github.com/tohojo/flent/releases/tag/v0.10.0
signature.asc
Description: PGP signature
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Announcing Flent (formerly netperf-wrapper) v0.10.0
Dave Taht writes: > This contained the never-merged (some licencing issues) web based > parser for the data. > > https://github.com/bipulkkuri/netperf-wrapper The main reason (apart from licensing issues) that it was never merged was that I don't want to maintain two plotting implementations within Flent itself. So the possible scenarios for a web-based viewer are, as I see it, roughly: 1. Leverage the existing matplotlib plotting implementation to produce javascript plots. This is issue #27 (https://github.com/tohojo/flent/issues/27) and depends on how well the mpl-to-d3 library works in practice. 2. Replace the whole plotting implementation with a javascript-based one, and serve that from within Flent itself. 3. Have an entirely separate web viewer implementation. Which scenario that works best will probably to a large extent depend on the actual use case this mystical beast is supposed to support. Which I don't believe has been articulated properly... -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Announcing Flent (formerly netperf-wrapper) v0.10.0
Dave Taht writes: > well,1) we need a flent-devel mailing list... no need to have this > discussion so widely here.. Yup, will try to set one up soonish. ENOTIME so far. > I agree that *you* do not want to maintain two plotting > implementations inside flent. But: > > I am hugely in favor of various implementations of stuff that can read > the file format and do various (new and interesting) things with it. > The number of python-matplotlib capable developers is small. The > number of javascript capable developers (and web based plotting tools) > is huge. Other means of dealing with the data (postgres json) are also > needed. Oh, sure, quite happy with more implementations. That was option 3. However, until someone actually starts working on such an implementation this is all hypothetical. I'm happy to discuss interoperability issues when such an implementation actually materialises :) > So the json.gz file format WAS readable and translatable by many web > servers and browsers, flent is not (so far as I know, even with adding > a mime type.) Yes, but .json.gz also makes it hard to distinguish from other random gzip'ed json data. I'd rather have a separate file extension for offline storage, and then solve the web problem as a separate problem, which as far as I'm concerned is orthogonal to the encoding of the files on disk. The important thing is the structure of the JSON object, not which compression format and file extension it is stored in. > I liked the original web based prototype, it needed a db back end, but > it seemed like a promising start. And odds are that db back end is going to store the JSON object in its own encoding anyway, hence rendering this whole discussion moot... :) > I don't have a lot of hope for the canvas approach, personally. Too > many abstractions. Yeah, I'm sceptical, but willing to give it the benefit of the doubt if it means I have to write less code... > Personally what I most prefer is that the "expert" implementation be > blazing fast! Yes, well, matplotlib is not exactly a cheetah... -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
[Bloat] Announcing Flent v0.11.0
Hey everyone So, yesterday's release of Flent uncovered a couple of issues. True to the 'release early, release often' principle, I have released a new version 0.11.0 that fixes these. Please use this version rather than 0.10.0. As before, Flent can be installed via pip by issuing `pip install flent`, or on Arch Linux through the Aur. Pre-built packages are available for Debian and Ubuntu at https://software.opensuse.org/download.html?project=home:tohojo:flent&package=flent. The issues discovered after the release of v0.10.0 which are fixed in this release are: - The file format extension has changed to `.flent` as plain-text JSON files, with optional compression as `.flent.gz` and `.flent.bz2`. The default output is `.flent.gz`. - Data files are no longer written to the current working directory by default. Instead, they are written to the system TMPDIR. A new switch, `-D` controls the location of the data files. Run with `-D .` to retain the old behaviour. This can also be set from the rcfile to have a default directory to store all data files. - Name clash issues in the Debian packaging preventing the `flent` binary from working has been fixed. - The `notsent_lowat`, `limit_output_bytes` and `timestamps` sysctl settings are now captured as part of the extended metadata. As always, please report issues to Github: https://github.com/tohojo/flent/issues Thanks, -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
[Bloat] Flent now has its own mailing lists (and web site!)
Hi everyone
Flent (The FLExible Network Tester, formerly netperf-wrapper) now has
its own mailing lists. See https://lists.flent.org for the web interface
and subscription options. This is running on mailman3, so fairly
bleeding edge with a few rough spots, but should generally work.
This means that I'll stop posting announcements on these lists, so if
you want to continue to be notified of new releases, please subscribe to
flent-announce. And of course, feel free to use the -devel and -users
lists as well!
The lists are also available on Gmane as
gmane.network.flent.{announce,devel,users}.
Flent now also has its own web site at https://flent.org - and the
documentation (i.e. the man page) has been reformatted for the web so
should now hopefully be more accessible. This documentation is also in
the source code repository in the doc/ directory - contributions very
welcome!
Hope to see you on the Flent list(s)! :)
Cheers,
-Toke
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] AQM and PPP on Linux
Juliusz Chroboczek writes: > I'm currently away from home, and using a 3G modem for Internet > access. I've found out that both NetworkManager and wvdial/pppd setup > the interface to use pfifo_fast (with a qlen of a mere 3 packets!). > Setting fq_codel manually appears to work fine, but needs to be redone > every time the modem has a hiccup. I don't think NetworkManager does anything to set qdiscs. The kernel simple sets pfifo_fast if not told otherwise (but see below). > Is that the expected behaviour? Shouldn't we be pushing patches > somewhere to change the default? What distro are you on? There's a sysctl to set the default qdisc: net.core.default_qdisc. Set this to fq_codel and you should be good to go. This is becoming the default in more and more distros (currently at least Arch and Fedora; and OpenWrt has been patching out pfifo_fast entirely for a while). There's a bug for Ubuntu here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1436945 -- feel free to bug them :) -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] AQM and PPP on Linux
Juliusz Chroboczek writes: >> What distro are you on? > > Debian. (One machine stable, one testing.) Right. Don't know if there's already an effort to convince the Debian devs to switch the default... >> Set this to fq_codel and you should be good to go. > > Is that safe? I'm thinking lo and virtual interfaces. Why wouldn't it be? The lo interface doesn't have a queue at all AFAIK. And if you have congestion at your virtual interfaces wouldn't you want it de-bloated? :) -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Fwd: Did *bufferbloat* cause the 2010 flashcrash?
Mikael Abrahamsson writes: > On Fri, 7 Aug 2015, Steinar H. Gunderson wrote: > >> [1] For the purposes of the question, the “BitTorrent problem” is when you >> and >> I are on the same network, and your 200+ BitTorrent upload sessions makes it >> impossible for me to upload my single cat video to YouTube. > > Isn't this dependent on the upload speed? I would imagine that if it's 5-10 > megabit/s, then using Codel or similar technique that doesn't allow the buffer > to grow to hundreds of milliseconds, would improve things a lot? > > For a 500 kilobit/s link, I'm not sure even that would work...? There are two separate issues: -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Fwd: Did *bufferbloat* cause the 2010 flashcrash?
Toke Høiland-Jørgensen writes: >>> [1] For the purposes of the question, the “BitTorrent problem” is when you >>> and >>> I are on the same network, and your 200+ BitTorrent upload sessions makes it >>> impossible for me to upload my single cat video to YouTube. >> >> Isn't this dependent on the upload speed? I would imagine that if it's 5-10 >> megabit/s, then using Codel or similar technique that doesn't allow the >> buffer >> to grow to hundreds of milliseconds, would improve things a lot? >> >> For a 500 kilobit/s link, I'm not sure even that would work...? > > There are two separate issues: (three if you count me hitting send too soon...) 1. When you turn on bittorrent, everything becomes unbearably slow because you have huge amounts of bloat. I.e. web browsing doesn't work, your voice calls drop, etc. fq_codel solves this pretty nicely (I don't even notice when bittorent is on anymore). 2. Bandwidth sharing between bittorrent and other protocols. Bittorrent uses utp to try to be a scavenger that will back off and not use bandwidth if other traffic needs it. fq_codel breaks this by isolating flows and taking away the signal utp uses to back off. Diffserv with a suitable scheduler (cake, for instance) can fix this if the bittorrent client is configured correctly; or you could use deep(er) packet inspection to try to figure out which traffic is bittorent. But we don't have a shrinkwrap solution to this presently, AFAIK. I believe the cat video upload falls into category 2. -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Fwd: Did *bufferbloat* cause the 2010 flashcrash?
"Steinar H. Gunderson" writes: > On Fri, Aug 07, 2015 at 04:43:19PM +0200, Sebastian Moeller wrote: >>> switching to IP-level fairness makes life hard for the torrent >>> user (not that it seems to even exist in fq_codel; >> fq_codel does not care as far as I know one can specify different >> hashing schemes (expect I have not tried it myself so that might not >> work). > > How? I've searched for it, I've checked the documentation, I've looked for it > in the code. What am I missing? The mechanism is not specific to fq_codel, it's a tc thing. You can attach arbitrary tc filters which fq_codel will then use as a classifier. http://lartc.org/howto/lartc.adv-filter.hashing.html has some (fairly old) information on this, but I've never tried it in practice with fq_codel so can't give you any more specific pointers. An alternative, of course, is to try out cake. Jonathan did a presentation on it at Battlemesh yesterday, which also has instructions on how to obtain it: http://battlemesh.org/BattleMeshV8/Agenda?action=AttachFile&do=view&target=cake-battlemesh-v8.pdf -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] how to submit your signatures for the cerowrt letter to the fcc
Dave Taht writes: > If someone can roll a web form, all the better. http://goo.gl/forms/WCF7kPcFl9 -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Last call for signatures to the FCC on the wifi lockdown issue
David Collier-Brown writes: > I just voted for Dave's slashdot posting: anyone else with karma, go to > > http://slashdot.org/submission/5075341/ask-the-fcc-to-switch-to-sane-software-engineering-practices-for-wifi > > and hit the "+" button to vote for it. Reddit post: https://www.reddit.com/r/opensource/comments/3o3mx0/ask_the_fcc_to_switch_to_sane_software/ -- feel free to upvote! :) -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Difference between codel and fq_codel?
John Klimek writes: > I'm currently using pfaense which only supports codel and not > fq_codel. Is there a big difference between them? Is it worth looking > into using a different router? Yes, and quite possibly. :) Basically, Codel drops packets to try to keep queues small. This works reasonably well. However, what FQ-CoDel adds is flow isolation and priority for sparse flows, which is what in most cases gets rid of almost all of the added latency under load. For a (much) longer version of the above, see this: http://www.sciencedirect.com/science/article/pii/S1389128615002479 -- In particular, figure 2 shows the performance of a bunch of different algorithms, including CoDel and FQ-CoDel :) -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] review: Deployment of RITE mechanisms, in use-case trial testbeds report part 1
Alan Jenkins writes: > I wouldn't complain that I can't sustain 2056Kbps goodput when my fair > share of the shaped bandwidth is 2000Kbps. The results might be > showing a significant degradation, or it could be a marginal one that > pushes over the boundary (between the 2056k and 1427k encodes). Which > of those conclusions you start from might be influenced by whether > you're developing a different AQM, hmm. Exactly. And note how they just so happen to pick 11 total flows (10 competing, one video) to share the bottleneck, putting the per-flow throughput just below the rate needed to go up one quality level. What a coincidence. At least it shows how difficult it is to design experiments that put fairness queueing in a bad light ;) Oh, and of course HAS is in itself a hack to work around badly managed queues in the network. In a nicely fairness queued world, we could do away with HAS entirely and just, y'know, stream things at the desired rate... -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] review: Deployment of RITE mechanisms, in use-case trial testbeds report part 1
Alan Jenkins writes: >> Exactly. And note how they just so happen to pick 11 total flows (10 >> competing, one video) to share the bottleneck, putting the per-flow >> throughput just below the rate needed to go up one quality level. What a >> coincidence. At least it shows how difficult it is to design experiments >> that put fairness queueing in a bad light ;) > Ug. I try not to assume malice. It does indeed come across as > motivated absence of curiosity. Oh, didn't necessarily mean it was malicious. Can totally picture the discussion landing on 10 competing flows (a nice round number). However, it does just so happen to result in there being a bit too little bandwidth for the 2Mbps video flow... -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] review: Deployment of RITE mechanisms, in use-case trial testbeds report part 1
Juliusz Chroboczek writes: >>> Oh, and of course HAS is in itself a hack to work around badly managed >>> queues in the network. In a nicely fairness queued world, we could do >>> away with HAS entirely and just, y'know, stream things at the desired >>> rate... > > Perhaps I'm missing something -- how do you to pick the right rate for > a given user? Congestion control? With something like fairness queueing that keeps bandwidth very stable at the fair share, you could conceivably get away with a much shallower playback buffer in the application and stream at something very close to real time, rather than using the chunk-based retrieval of HAS. However, that remark was mostly meant to be tongue-in-cheek... not sure if there exists any really good congestion control algorithms for real-time video. -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
[Bloat] M-Lab hit by performance degradation caused by TCP micro-bursts
Seems their switches were overwhelmed by simultaneous line-rate micro-bursts from several servers connected to it. There's a nice report on the issue and their mitigation here: http://www.measurementlab.net/blog/traffic-microbursts-and-their-effect-on-internet-measurement/ -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] bufferbloat.net is sorely missed.
Kevin Darbyshire-Bryant writes: > Possibly/probably as a result of CAKE getting into LEDE I note a few people > saying 'bufferbloat.net' is down. This is unfortunate just at a time when a > hoped for uptick in interest factor may well be upon us. Interest has been > expressed in http://www.bufferbloat.net/projects/codel/wiki/Cake I'm working on converting the old wiki and issue pages to a static site. Got some of the way, but a bit more to be done. Will take another stab at it over the weekend. > In the shorter term, to satisfy some sort of interest, would it be possible to > point at an archive of the site? I know not how this could be done. The Wayback Machine is your friend: https://web.archive.org/web/20160328150326/http://www.bufferbloat.net/projects/codel/wiki/Cake -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] bufferbloat.net is sorely missed.
Rich Brown writes: > Thanks for taking on the revival of the bufferbloat site. Okay, updated the conversion to preserve the directory structure. Current version is here: https://kau.toke.dk/bufferbloat-archive. The overview pages and index are somewhat lacking at the moment, but the wiki pages are there at the same relative URLs as on the old site. I can update the DNS to point at that server and have old links start working again; if no one objects, I'll do that later today. There's a github repo with the contents linked from the above link; pull requests welcome if anyone wants to contribute to improving things :) -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] bufferbloat.net is sorely missed.
Dave Taht writes: >> Okay, updated the conversion to preserve the directory structure. >> Current version is here: https://kau.toke.dk/bufferbloat-archive. The > > I get a 404 on that right now across the board... > > https://kau.toke.dk/bufferbloat-archive/projects/codel/wiki/Benchmarking_Codel_and_FQ_Codel/ Was moving things around and hadn't set up a redirect yet. Should work now, and the server also answers to www.bufferbloat.net. I did an nsupdate, but the linode nameservers don't seem to have picked it up yet. Not sure how to poke them to do so. >> overview pages and index are somewhat lacking at the moment, but the >> wiki pages are there at the same relative URLs as on the old site. > > Having the original data available to those willing to work on fixing > it would be useful, I was reluctant to share the sql dump widely due > to passwords being in it. Can more of the sql dump land somewhere? Do > you have other conversion scripts lying around? This is all in the github repo in the export/ dir - both scripts and csv files. Did another export from the database, merging several tables with the information needed for the wiki. There's also an export of the attachments which I haven't done anything with yet. > (I used pandoc to convert from textile to markdown originally plus a > few sed scripts) Yes, mine are python scripts that also run pandoc. >> I can update the DNS to point at that server and have old links start >> working again; if no one objects, I'll do that later today. > > Well, to save on cost and improve bandwidth I'd rather it moved to the > web server lists.bufferbloat.net is on. (and ultimately a cdn). I was > reluctant to move it there because the redmine integration was > failing, but for a static web site, no problem. Have no objections to moving it once we hit something a bit more stable; but for now, having it on my own server allows me to iterate quicker. It's at my uni on a gbit link, so should be fine (famous last words). Having several mirrors and sticking all the addresses in DNS would also be a way to do things, if we can make sure they all update from git regularly. Figure these things can be sorted out once we get the conversion itself done and have it go into maintenance mode (where we actually take pull requests for the *content*). :) -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] bufferbloat.net is sorely missed.
Toke Høiland-Jørgensen writes: > I did an nsupdate, but the linode nameservers don't seem to have > picked it up yet. Not sure how to poke them to do so. Ah, they seem to be switching over now... -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
[Bloat] Revival of the bufferbloat.net site
So, I finished the conversion of the bufferbloat.net wiki page to a static version build with the Hugo site generator. The DNS updates are almost finished propagating, which means that the new site should be available soon. If your DNS has not updated yet, you can access it by this URL: https://kau.toke.dk/bufferbloat-net/projects/ The conversion includes the wiki pages of the bloat, cerowrt, codel and make-wifi-fast projects in the old redmine installation. It should be fairly complete as far as these parts are concerned, and the old links should start working as the DNS update propagation finishes. Now, there are still some rough patches on the conversion. I plan to convert over the attachments to the wiki pages and the news items from the old site. I am also thinking that having the old issue pages available might be good, but haven't been able to figure out exactly how redmine stores them (database model here: https://www.redmine.org/projects/redmine/wiki/DatabaseModel) The source files for the site are available on github: https://github.com/tohojo/bufferbloat-net -- if anyone wants to help out, filing issues with the new site would be a way to do that. Once I'm satisfied that the conversion scripts have done their job I figure we can also start improving the content itself by pull requests to the markdown source files; but I'd advise people to hold off on this until the risk of everything being overridden by another run of the conversion script is not so imminent ;) Oh, and I am aware that the ssl certificate is wrong right now. As soon as the letsencrypt servers start seeing the new DNS information I'll put in a working cert. In the meantime, access the site via plain http, or add an exception for the current cert. -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] bufferbloat.net is sorely missed/Now it's back!
Rich Brown writes: > The new site just went live here in the shrubs of New Hampshire, USA. > (It wasn't working ~10 minutes ago.) Awesome! The letsencrypt servers seem to have picked up the change too, so there's now a cert in place and non-https redirects to serve via https. > WOW! This is a wonderful piece of work! It manages to regain most of > the structure of the separate parts of the Redmine system. Thanks! Yeah, tried to keep the structure from the Redmine install. The only thing that may not be too obvious from the git repo is that the static site uses the /project prefix as its root. This is to take advantage of the built-in 'section' functionality of Hugo. The Hugo output is simply put in a subfolder on the server, and I configured it to redirect / to /projects. > I just forked the repo and will start looking for places to make it > better. Thanks! Awesome! Will update the README with a few pointers on how it's structured (unless you beat me to it ;)). > PS I will leave my placeholder github.io site up in case anyone wants > to go back via the Wayback Machine. > http://richb-hanover.github.io/bufferbloat-site/ Cool. Also added the archive.org 404 helper to the 404 page for the new site :) -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Revival of the bufferbloat.net site
Toke Høiland-Jørgensen writes: > Now, there are still some rough patches on the conversion. I plan to > convert over the attachments to the wiki pages and the news items from > the old site. I am also thinking that having the old issue pages > available might be good, I have now finished converting attachments, news items and issues from the old site. As far as I'm concerned the conversion is now 'good enough', which means that hopefully the conversion scripts don't need to be re-run. Which means that the ball is now open for actually improving the content. Going through the old pages, seeing what is broken and filing issues and/or pull requests. I've already started: https://github.com/tohojo/bufferbloat-net/issues/2 I figure that if there's going to be a lot of activity on this that we can setup some kind of automatic building and updating of the live site. For now, I'll do it manually. -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Bufferbloat.net - Organizing, curating, and workflow
Rich Brown writes: > Thanks again to Toke for all this good work. It's terrific to see the > pages resurrected, and to have the www.bufferbloat.net site living > again. You're welcome! Just glad it's being appreciated ;) > I've been thinking of the next steps - to make all this work really useful. I > see there are three important issues: > > Organizing: Thinking about the best way to display the current information: > - Should Cake be listed as a top-level project? No opinion. > - Is there a way to display newest entries? I'd like to see a > sidebar element showing the 5 newest posts Yes, certainly. Was thinking of putting a list of newest news items on the front page. However, for the wiki pages it is not necessarily obvious that having a notion of 'newest' is useful. > - Can an RSS feed be generated automatically? Yes, but see above. > Curating: The current site makes it seem as if all pages are equally > important. I feel the urge to do the following: > - Categorizing the "List of Wiki Pages" for a project (e.g., > http://bufferbloat.net/projects/cerowrt/ ) > so there's a sense of their importance A way to do this would be to update the 'index' wiki pages to be more useful (e.g. https://www.bufferbloat.net/projects/cerowrt/wiki/) and keep the overview pages as a 'complete' list. However, it's certainly also possible to mark some of the pages as 'important' and have those show up on top of the list. > - Discard old/outdated/useless articles Yes, this is probably needed. And also fixing broken links (see the issue I opened for this on github). > Workflow: > - Rules for making posts: Who can make them? How do they get > published? Well, it's a git repo. I figure anyone can do pull requests. > - Auto-publish - if it's not already happening, could we > re-render and publish after a commit? Yes, that is certainly possible. For now I figure I'll do it manually (it's just re-running a script), but if we get enough activity that that becomes a bottleneck, I can certainly set up something automated. > - I see the 404 handler in place, but it doesn't seem to show a > link to archive.org It includes a javascript from archive.org which *should* show a link if (and only if) an archived version exists. Haven't verified that it actually works. > - Is there a way to do page redirection? It looks as if Toke has done a > great job of replicating > URLs in the new site, but if we see frequent broken > links, is there a way to redirect a page to its > equivalent on the new site? Yes. This is already used for news items and issues. > - Should we add a Google search box on 404 page? On every page? Not sure what it takes to do this properly, and if it's worth the hassle. > - Would it make sense to review error logs from time to time? Possible. Split out the logs to a separate file; can provide it if someone wants to go digging. Or I can just parse out a list of 404 errors from time to time. -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Bufferbloat.net - Organizing, curating, and workflow
moeller0 writes: > So how do I contribute changes to existing pages? The cake page has > some inaccuracies regarding VDSL2 encapsulation that I would like to > fix… Clone the repo at https://github.com/tohojo/bufferbloat-net/, make changes to the right markdown file and submit a pull request with the change :) -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Bufferbloat.net - Organizing, curating, and workflow
moeller0 writes: >> Clone the repo at https://github.com/tohojo/bufferbloat-net/, make >> changes to the right markdown file and submit a pull request with the >> change :) > > Thanks, I just saw this information is also on the bottom of the > entry page, sorry for not looking more closely… If you missed it, it's probably not visible enough... ;) -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Bufferbloat.net - Organizing, curating, and workflow
Dave Taht writes: >> Clone the repo at https://github.com/tohojo/bufferbloat-net/, make >> changes to the right markdown file and submit a pull request with the >> change :) > > Arguably it will be faster as expertise is gained to allow more (most > or all) of the core authors direct access to the primary github repo, > and autopublication is possible with a post-push hook. No objection to that :) > One of the big "fixes" inherent in this design is that hugo supports a > "draft" concept, where stuff can be iterated on inside of git by one > or more parties before it makes it to the public web. I have a problem > in that I'm always working on 6 things at once and have had a tendency > to realize "oh, that's a topic that needs more work", and yet never > get around to fleshing out that topic, in part, because I forget it's > essentially a broken link. Well, isn't the idea of a Wiki that you just publish the draft, and it's always a work in progress? ;) -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] bufferbloat.net is sorely missed/Now it's back!
Kevin Darbyshire-Bryant writes: > Thank you to all involved in getting that sorted out. I don't know how > you did it, it's magic to me, fantastic result and very much > appreciated. Thanks! :) The 'how' is simply: Python! Available here for your perusal: https://github.com/tohojo/bufferbloat-net/tree/master/export Obligatory XKCD: https://xkcd.com/353/ -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Bufferbloat.net - Organizing, curating, and workflow
Rich Brown writes:
> Good comments all... Let me preface these responses by saying that I'm
> willing to help out, but don't want to get in the way of the rapid
> progress being made.
>
> Toke: Let us know when you think you're done with major
> reorganizations...
Awesome. I think I'm done with most of the reorganisation stuff now, and
am happy to let other people go nuts :)
> I also want to see if there's consensus about when and how to make
> updates, so that we're not stepping on toes. TL;DR questions:
>
> - Do we only want to use pull requests, or should core authors have
> edit access to github?
Quite happy to give out push access. Only caveat is that there needs to
be an understanding that updates should be tested and if someone breaks
something it is going to break on the live site. However, I figure the
people involved here knows how to deal with that ;)
> - Or do we use the 'draft' facility? (How?)
My thought was that for most things (like news articles, etc), just
writing it up and pushing it 'live' is the right thing to do. But there
may be cases where several people want to explicitly collaborate on,
say, a news article before it is published, in which case the draft
facility can be a way to use the git repo to do this. Using branches
would be another.
>>> - Is there a way to display newest entries? I'd like to see a
>>> sidebar element showing the 5 newest posts
>>
>> Yes, certainly. Was thinking of putting a list of newest news items on
>> the front page. However, for the wiki pages it is not necessarily
>> obvious that having a notion of 'newest' is useful.
>
> I see the (new) News column on the home page. The content is right,
> but it takes too much space on the page. Maybe there could be a box
> above the "Find us elsewhere" panel that just had news article
> titles...
Hmm, I do tend to use fairly wide monitors. Can certainly move it if it
takes up too much space. Feel free to play around with it :)
> Random updates to the wiki pages wouldn't need to be mentioned. But if
> there's a new topic added, maybe we should publish a corresponding
> News item to call it out.
I think it's possible to do a 'new items' feed that uses only initial
publication date as the sort key; which would make new wiki pages show
up as well, but not edits of old ones.
>>> - Can an RSS feed be generated automatically?
>>
>> Yes, but see above.
>
> I wonder whether an RSS icon could go in the heading of the News
> panel...
Sure. Just link it to /projects/index.xml - there's already a in the header.
>> Yes, this is probably needed. And also fixing broken links (see the
>> issue I opened for this on github).
>
> I figure that members of this group can take on sections as the spirit
> moves them.
That was my hope ;)
> I suspect bigger experiments should be done as PR's (especially if we
> figure out how to use github.io pages to display the new form of the
> site from our own repos...)
Yeah. For local experiments, running 'hugo serve' is all you need. For
things that need review, just publishing the files somewhere is all that
is needed. If we end up needing to have a long string of review on some
new feature (say), it is also possible to host automatic builds from
other branches at some other location.
>>> - Auto-publish - if it's not already happening, could we
>>> re-render and publish after a commit?
>>
>> Yes, that is certainly possible. For now I figure I'll do it manually
>> (it's just re-running a script), but if we get enough activity that that
>> becomes a bottleneck, I can certainly set up something automated.
>
> Cool! It looks as if you added code to do that. Is it operational?
Yup. Had some more time last night and set it up. It will automatically
pull and build from the master branch whenever it changes. Takes less
than a minute from push to live update :)
>> It includes a javascript from archive.org which *should* show a link if
>> (and only if) an archived version exists. Haven't verified that it
>> actually works.
>
> Ahah! I think this is going to be hard to test - Toke has done too
> good a job of matching Hugo URLs to the old Redmine URLs... :-)
>
> I did fire up LinkChecker on the site, and it found a few bad URLs.
> I'll send a separate message about it.
Saw that in the logs. I am including a filtered error log below, listing
the wiki URLs that seem to be missing.
>> Possible. Split out the logs to a separate file; can provide it if
>> someone wants to go digging. Or I can just parse out a list of 404
>> errors from time to time.
>
> I know how to add Google Search, and can take it on after other stuff
> has settled.
Awesome.
> Given the good match between new and old URLs, we might only need a
> one-time survey of error.log files to see if there's major traffic to
> a particular "lost" page.
See list below.
-Toke
$ grep 404 /var/log/nginx/bufferbloat.access.log | awk '{print $7}' | sort |
uniq | grep wiki | egrep -v 'annotate|history|diff|edit|
Re: [Bloat] Bufferbloat.net - Organizing, curating, and workflow
Dave Taht writes: > On Sun, Jun 12, 2016 at 10:49 AM, Rich Brown wrote: >> To all the Bufferbloaters out there... >> >> Thanks again to Toke for all this good work. It's terrific to see the pages >> resurrected, and to have the www.bufferbloat.net site living again. > > And it's fast - even half a planet away. I am still looking around at > various cdn technologies I played around with using cloudfare through amazon for my blog at some point; for static pages you can get it to pull from an S3 bucket. Syncing to that is fairly straight forward. I gave up on the effort at the time because I botched the SSL cert setup (cloudfare only accepts up to 2048 bits, and this was pre-letsencrypt, so getting a new one once issued was non-trivial), and because the propagation delay for changes was too high. We can certainly stick it in a CDN if you find something that works well, but for now at least I'd call that a premature optimisation. I did configure the web server to do most of the obvious speed optimisations (for instance, everything will be statically compressed on build, so the server basically just has to do sendfile() on the right file on request). https://developers.google.com/speed/pagespeed/insights/?url=https://www.bufferbloat.net/projects/ > Definately agree it would be good to track what people have been using > as inbound links, on plain access also. People kept linking to the > oddest parts of the site... I can have the server generate awstats reports for the site (http://www.awstats.org/) - these include the most common inbound referrers and most common 404 pages. Not sure if they should be public, though. Don't *think* they usually contain sensitive content (given that the whole site is public, anyway). But I could be wrong; thoughts? -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Bufferbloat.net & LinkChecker
Rich Brown writes: > I have pasted the resulting CSV file at: http://pastebin.com/XaFUjKEL Cool. Now someone just needs to go fix all those ;) I note that I have other stuff to attend to, so I am not expecting to do more work on the site for the time being. So don't be shy, go fix stuff (that goes for everyone, not you in particular). I'll be happy to review pull requests and/or assist with explaining some of the ways I've had to wrangle Hugo to get it to do stuff the way I wanted it to, as needed. -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] ultrafast broadband conference june 27-30
Jan Ceuleers writes: > Either you perceive the problem to be located in the link technology > (i.e. DSL generally or only specific flavours of it). If this is the > case what needs to be fixed is the standard so that implementations > thereof will improve. > > Or else you perceive the problem to be located in the CPE that implement > DSL, but in the layer above the DSL link layer. In this case what needs > to be fixed is those implementations, probably starting by the reference > firmware written by chipset vendors. > > I think it's the latter. If it's the former then indeed don't hold your > breath because the standardisation is done and dusted. It is indeed the latter. However, it is correlated with DSL technology because the equipment tend to be using binary blobs for drivers that themselves have huge buffers; so even if the device is running Linux, sticking FQ-CoDel on it doesn't do much good without a software rate limiter. And also, most devices are owned by the ISP, so the consumer can't upgrade them anyway. So while it is nothing inherent in the technology per se, in practice it is a fairly safe bet to say "ah, you're on DSL? Well, you are probably suffering from bufferbloat, then". I know of at least one DSL vendor who supposedly has started paying attention after pressure from a clueful ISP; not idea if they started shipping non-bloated products yet. -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] ultrafast broadband conference june 27-30
Jan Ceuleers writes: > On 18/06/16 12:51, Toke Høiland-Jørgensen wrote: >> I know of at least one DSL vendor who supposedly has started paying >> attention after pressure from a clueful ISP; not idea if they started >> shipping non-bloated products yet. > > Got it. > > To get more ISPs interested in this subject we need to get Ookla to take > account of bufferbloat. So long as speedtest.net and the Ookla servers > many ISPs have in their labs ignore latency under load there will not be > any pressure on the CPE industry to clean up its act. Yup. Unfortunately we've had no luck thus far. https://www.dslreports.com/speedtest is an alternative speedtest that does include bufferbloat scores. -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
