[Codel] Fwd: [Announce] LARTC wiki available

it would be good to put at least some of what we know over here, too. -- Forwarded message -- From: Julien Vehent Date: Fri, Jun 1, 2012 at 8:12 PM Subject: Re: [Announce] LARTC wiki available To: Niccolò Belli Cc: la...@vger.kernel.org, netfil...@vger.kernel.org, Linux Networkin

[Codel] Fwd: [dtaht/ns-3-codel-dev] f69227: Latest tcp-qfp, including codel

Andrew has pushed working final codel and fq_codel into the ns-3-codel-dev repo on github. have at it! -- Forwarded message -- From: GitHub Date: Fri, Jun 8, 2012 at 10:57 PM Subject: [dtaht/ns-3-codel-dev] f69227: Latest tcp-qfp, including codel To: cerowrt-comm...@lists.buffer

[Codel] interesting/useful networking related conferences?

I am trying to figure out travel schedules for the next 7 months, to continue to spread the codel word, so I'm looking for government or academic conferences worth members of the bloat team attending or presenting at, between now and December. We have the linux and ietf worlds prettu covered, so...

Re: [Codel] [Bloat] interesting/useful networking related conferences?

On Sat, Jun 9, 2012 at 10:10 PM, Joe Provo wrote: > On Sat, Jun 09, 2012 at 09:41:06PM -0400, Dave Taht wrote: >> I am trying to figure out travel schedules for the next 7 months, to >> continue to spread the codel word, so I'm looking for government or >> academic co

Re: [Codel] [RFC PATCH] Codel: Enable packet drop with ECN-marked packets on a threshold

On Sun, Jun 17, 2012 at 10:17 PM, Eric Dumazet wrote: > On Sun, 2012-06-17 at 15:30 -0700, Dave Täht wrote: >> Lossless IP networks are not possible. Dropping packets is the >> fastest way to get back to a target delay, and if that involves >> dropping ECN marked packets, so be it. When a network

Re: [Codel] [RFC PATCH] Codel: Enable packet drop with ECN-marked packets on a threshold

On Sun, Jun 17, 2012 at 10:58 PM, Eric Dumazet wrote: > On Sun, 2012-06-17 at 22:40 -0400, Dave Taht wrote: >> On Sun, Jun 17, 2012 at 10:17 PM, Eric Dumazet >> wrote: > >> > if (A && B && C) >> > >> > Even if (C) is false, but A is

Re: [Codel] [RFC PATCH] Codel: Enable packet drop with ECN-marked packets on a threshold

On Sun, Jun 17, 2012 at 11:10 PM, Eric Dumazet wrote: > On Sun, 2012-06-17 at 22:40 -0400, Dave Taht wrote: > >> (side note, I noticed fq_codel defaulted to 10k packets which is >> rather excessive for tiny routers - I just trimmed that down >> significantly for cerowrt

Re: [Codel] [RFC PATCH] Codel: Enable packet drop with ECN-marked packets on a threshold

OK, so to move forward on testing this on linux directly I'll produce a better patch, and add tc support for ecn_limit? ecn_target? ecn_drop_limit? harddrop_at? However: I'm perfectly happy leaving the mainline linux implementation alone for a while, fiddling with ns3 instead, and especially cont

[Codel] Cerowrt 3.3.8-6 is now available

I just put out http://huchra.bufferbloat.net/~cero1/3.3/3.3.8-6/ and deployed it as my default gw and ran a bunch of tests that it survived. I'd prefer to test 24 hours but I'm about to start a trip and can't do that. Hopefully after some more testers leap on it we can declare it stable later this

[Codel] codel "oversteer"

I've been forming a theory regarding codel behavior in some pathological conditions. For the sake of developing the theory I'm going to return to the original car analogy published here, and add a new one - "oversteer". Briefly: If the underlying interface device driver is overbuffered, when the

Re: [Codel] [RFCv2 PATCH] codel: add ecn_target for when to drop rather than mark ecn packets

On Sun, Jun 24, 2012 at 10:22 PM, Eric Dumazet wrote: > On Sun, 2012-06-24 at 22:00 -0700, Dave Täht wrote: >> From: Dave Taht >> >> ECN can be gamed, and it is generally faster under overload >> to drop rather than mark packets, to get back to a target. >&g

Re: [Codel] [RFCv2 PATCH] iproute2: Add ecn_target option to codel and fq_codel

On Sun, Jun 24, 2012 at 10:29 PM, Eric Dumazet wrote: > On Sun, 2012-06-24 at 22:00 -0700, Dave Täht wrote: >> From: Dave Taht >> >> ECN was not part of the original codel design and adding support >> for it revealed problems in two areas. 1) ECN can be gamed. &

Re: [Codel] [RFCv2 PATCH] codel: add ecn_target for when to drop rather than mark ecn packets

On Mon, Jun 25, 2012 at 8:20 AM, Eric Dumazet wrote: > On Mon, 2012-06-25 at 07:50 -0700, Dave Taht wrote: >> On Sun, Jun 24, 2012 at 10:22 PM, Eric Dumazet >> wrote: >> > On Sun, 2012-06-24 at 22:00 -0700, Dave Täht wrot

Re: [Codel] [RFCv2 PATCH] codel: add ecn_target for when to drop rather than mark ecn packets

25 Jun 2012, at 18:45, Eric Dumazet wrote: > >> On Mon, 2012-06-25 at 08:30 -0700, Dave Taht wrote: >> >>> It was the way I was leaning until I observed me dropping ecn enabled >>> mosh, ssh, and babel packets , which tend to be small, so I started >>

Re: [Codel] [PATCH net-next] fq_codel: report congestion notification at enqueue time

cal TCP stack to call tcp_enter_cwr() and reduce its cwnd > without drops (for example if ECN is not enabled for the flow) > > Signed-off-by: Eric Dumazet > Cc: Dave Taht > Cc: Tom Herbert > Cc: Matt Mathis > Cc: Yuchung Cheng > Cc: Nandita Dukkipati > Cc: Neal Car

Re: [Codel] [PATCH net-next] fq_codel: report congestion notification at enqueue time

On Thu, Jun 28, 2012 at 6:56 PM, Yuchung Cheng wrote: > On Thu, Jun 28, 2012 at 11:12 AM, Eric Dumazet wrote: >> On Thu, 2012-06-28 at 10:51 -0700, Dave Taht wrote: >> >>> clever idea. A problem is there are other forms of network traffic on >>> a link, and this

Re: [Codel] [PATCH net-next] fq_codel: report congestion notification at enqueue time

On Fri, Jun 29, 2012 at 12:50 AM, Eric Dumazet wrote: > A router will have no use of this feature, not sure you need to spend > time trying this ;) It's not yer ordinary router... A cerowrt router has iperf, netperf/netserver from svn with congestion control switching and classification setting

Re: [Codel] Fwd: Re: [tsvwg] new draft on CoDel AQM

I'm not sure if fred is on the codel list... On Fri, Jul 13, 2012 at 9:53 PM, Kathleen Nichols wrote: >> >>> 3.3. About the interval >>> >>> The interval constant is loosely related to RTT since it is chosen >>> to give endpoints time to react without being so long that >>> response times suffer

Re: [Codel] [RFC PATCH] codel: ecn mark at target

On Mon, Aug 6, 2012 at 9:46 AM, Eric Dumazet wrote: > Every time we suspect sender has a small cwnd, we enter the quickack > mode. > > So when receiving CE segments, we should do the same. Thats a flaw in > current linux code to do nothing and expect more packets to come. > > It just works becaus

[Codel] new ns3 tree for codel/fq_codel (coping with mercurial and ns3)

My previous import of ns3 into github from hg was not working out well. So I have rebased the ns3 sfq/codel/fq_codel tree on top of the latest ns3-dev code into a new tree on github. git clone git://github.com/dtaht/ns-3-dev.git Hopefully this version will work out better. The code compiles and r

Re: [Codel] [RFC PATCH] codel: ecn mark at target

On Mon, Aug 6, 2012 at 1:01 PM, Eric Dumazet wrote: > On Mon, 2012-08-06 at 12:09 -0700, Andrew McGregor wrote: >> On 6/08/2012, at 10:50 AM, Dave Taht wrote: >> >> > This discussion is getting mildly off-track. My intent in posting this >> > patch >> &g

[Codel] Codel, fq_codel in ns3

Andrew Mcgregor has developed some ns3 models of Kathie Nichols' and Van Jacobson's new codel algorithm and also incorporated Eric Dumazet's fq_codel derivative... VJ's ietf talk last week on codel and fq_codel is here: http://recordings.conf.meetecho.com/Recordings/watch.jsp?recording=IETF84_TSV

[Codel] coping with memory limitations and packet flooding in codel and fq_codel

We've had a raft of deployment questions regarding fq_codel, memory use, and the impact of unresponsive flows over on the cerowrt development list. sort of summary of the thread here, with some codel related ideas https://lists.bufferbloat.net/pipermail/cerowrt-devel/2012-August/000423.html some

[Codel] codel, fq_codel ns3 models under code review

The codel and fq_codel ns3 model is under code review using the tool the ns3 developers use, here: http://codereview.appspot.com/6463048/ This a preliminary code review mostly aimed at making this model meet ns3's coding standards, rather than for correctness or usefulness... If anybody else wou

Re: [Codel] [PATCH] codel: Refine re-entering drop state to react sooner

re-re-reviewing this in the light of dawn... On Thu, Aug 23, 2012 at 1:37 AM, Dave Täht wrote: > From: Dave Taht > > This patch attempts to smooth out codel behavior in several ways. > > These first two are arguably bugs. > > 1) Newton's method doesn't run wel

Re: [Codel] [Cerowrt-devel] [PATCH 2/2] codel: reduce count after exiting dropping state after one maxpacket

codel/alwaysthoughtthese10secondintervalswereaflawofthecapturetoolbut.png Anyway > > -Original Message- > From: "Dave Täht" > Sent: Thursday, August 23, 2012 9:58am > To: cerowrt-de...@lists.bufferbloat.net > Subject: [Cerowrt-devel] [PATCH 2/2] codel: reduce cou

Re: [Codel] [PATCH] codel: Refine re-entering drop state to react sooner

a new patch coming up that adheres closely to the ns2 model that won... some notes follow: On Thu, Aug 23, 2012 at 1:37 AM, Dave Täht wrote: > From: Dave Taht > > This patch attempts to smooth out codel behavior in several ways. > > These first two are arguably bugs. > &g

Re: [Codel] coping with memory limitations and packet flooding in codel and fq_codel

On Tue, Aug 21, 2012 at 1:38 AM, Eric Dumazet wrote: > On Mon, 2012-08-20 at 14:05 -0700, Dave Taht wrote: >> We've had a raft of deployment questions regarding fq_codel, memory >> use, and the impact of unresponsive flows >> over on the cerowrt development list. &g

Re: [Codel] [RFC PATCH] codel: tighten responsiveness and more reliably deal with loads

On Mon, Aug 27, 2012 at 5:17 AM, Eric Dumazet wrote: > On Sun, 2012-08-26 at 12:02 -0700, Dave Täht wrote: >> From: Dave Taht >> >> This updates the codel algorithm to more closely match the current >> experimental ns2 code. Not presently recomended for mainline. >

Re: [Codel] coping with memory limitations and packet flooding in codel and fq_codel

On Mon, Aug 27, 2012 at 4:37 AM, Eric Dumazet wrote: > On Sun, 2012-08-26 at 14:36 -0700, Dave Taht wrote: > >> From looking over the history of this idea, it does seem to be a good >> idea for small devices with potentially big queues. >> >> http://www.spinics.n

[Codel] better mixing in fq_codel

I have finally found the source of the issues I was having with htb + fq_codel at low bandwidths, and it wasn't htb to the extent I thought it was. It was fq_codel's use of byte quantums, which was resulting in head of line blocking for multiple streams. The undesirable behavior (quantum of 1500)

Re: [Codel] better mixing in fq_codel

On Thu, Aug 30, 2012 at 4:06 PM, Eric Dumazet wrote: > On Thu, 2012-08-30 at 15:59 -0700, Dave Taht wrote: >> I have finally found the source of the issues I was having with htb + >> fq_codel at low bandwidths, and it wasn't htb to the extent I thought >> it was. >

Re: [Codel] better mixing in fq_codel

On Thu, Aug 30, 2012 at 6:40 PM, Eric Dumazet wrote: > On Thu, 2012-08-30 at 16:19 -0700, Dave Taht wrote: > >> In that case it will deliver 3 acks in a row from >> stream A, and then 3 acks in stream B, in the linux 3.5 version, and >> push the the 1500 byte packet fr

Re: [Codel] fq_codel : interval servo

On Fri, Aug 31, 2012 at 9:23 AM, Eric Dumazet wrote: > On Fri, 2012-08-31 at 08:53 -0700, Rick Jones wrote: >> On 08/30/2012 11:55 PM, Eric Dumazet wrote: >> > On locally generated TCP traffic (host), we can override the 100 ms >> > interval value using the more accurate RTT estimation maintained

[Codel] exploring alternate codel and fq_codel ideas

I finally did get a working version of the ns2 based codel.h code, and instead of hacking on fq_codel directly, I started adding versions so as to be able to compare new and old more directly. I'm thinking of re-activating debloat-testing for this purpose. What I did was just do a codel2.h, and did

Re: [Codel] fq_codel : interval servo

On Sat, Sep 1, 2012 at 5:53 AM, Eric Dumazet wrote: > On Fri, 2012-08-31 at 09:59 -0700, Dave Taht wrote: > >> I realize that 10GigE and datacenter host based work is sexy and fun, >> but getting stuff that runs well in today's 1-20Mbit environments is >> my own

Re: [Codel] fq_codel : interval servo

On Sun, Sep 2, 2012 at 11:08 AM, Dave Taht wrote: In reviewing this mail I realized I used three different names for tcp_limit_output_bytes, corrected below... > Codel will push stuff down to, but not below, 5ms of latency (or > target). In fq_codel you will typically end up with 1

Re: [Codel] fq_codel : interval servo

On Sun, Sep 2, 2012 at 4:23 PM, Eric Dumazet wrote: > On Sun, 2012-09-02 at 11:08 -0700, Dave Taht wrote: >> On Sat, Sep 1, 2012 at 5:53 AM, Eric Dumazet wrote: >> > On Fri, 2012-08-31 at 09:59 -0700, Dave Taht wrote: >> > >> >> I realize that 10GigE and

Re: [Codel] [RFC v2] fq_codel : interval servo on hosts

On Tue, Sep 4, 2012 at 8:34 AM, Eric Dumazet wrote: > On Tue, 2012-09-04 at 08:10 -0700, Nandita Dukkipati wrote: >> The idea of using srtt as interval makes sense to me if alongside we >> also hash flows with similar RTTs into same bucket. But with just the >> change in interval, I am not sure ho

[Codel] fq_codel: revenge of the standing queue

As presently implemented, multi-queue fq_codel has a few FIFO codel assumptions baked into it. The first, already fixed, was that codel's state was completely reset when a fq_codel queue was emptied. This has been fixed via a patch to mainline. However there are other places where codel's state i

Re: [Codel] fq_codel: revenge of the standing queue

On Tue, Sep 4, 2012 at 12:02 PM, Eric Dumazet wrote: > On Tue, 2012-09-04 at 11:35 -0700, Dave Taht wrote: > >> 1) An empty queue in fq_codel has no meaningful information. >> >> in: codel_should_drop >> >> if (!skb) { >>

Re: [Codel] fq_codel: revenge of the standing queue

Most of my own battle of late has been with uTP. > > imho, > Kathie I'm going to crawl back under my rock now. > > > On 9/4/12 11:50 AM, Eric Dumazet wrote: >> On Tue, 2012-09-04 at 11:35 -0700, Dave Taht wrote: >> >>> 2) New flo

[Codel] some bloat-related updates, VJ's talk, mine, other items...

The bloat list itself has been kind of dead lately. We have a tendency to think everyone is paying attention to g+ and subscribed to Jim's blog. High on my list that everyone see is: Van Jacobson's wonderful talk on bloat, codel, and fq_codel at ietf 84. http://recordings.conf.meetecho.com/Reco

Re: [Codel] ns-3.15 simulations using CoDel

The ns3 patches for codel and fq_codel long ago migrated to github. https://github.com/dtaht/ns-3-dev Is that what you are using? Secondly codel is mostly targetted at TCP. On Sun, Sep 30, 2012 at 9:23 AM, Mark Sammut wrote: > Hi all, > > I am trying to run CoDel simulations using ns-3.15 and

[Codel] better testing, linux 3.6.1, cerowrt credits, other stuff

Some notes: Moving rapidly up on my own list of priorities is developing at least a spec for better tests. Help? Openwrt is nearing a stable release on linux 3.3.8, which includes a backport of fq_codel. 150+ platforms, no waiting. The current "sugarland" version of cerowrt contains versions of

Re: [Codel] [Bloat] better testing, linux 3.6.1, cerowrt credits, other stuff

On Tue, Oct 9, 2012 at 9:45 AM, Rick Jones wrote: > Toke - > > 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 mo

[Codel] 3.6.2 multiple codel testing (and odd behavior with tos = 0x20 on iwl?)

I have just put up my intended-for-some-major-testing 3.6.2 based kernels for x86_64 ubuntu 12.4 here: http://snapon.lab.bufferbloat.net/~cero1/deb/ There's only two out of tree patches left in it - one to preserve the "dropped" statistic in fq_codel, the other to add the current ns2 model of cod

[Codel] Fwd: Combatting Buffer Bloat With fq_codel on android

This is making the rounds today: https://groups.google.com/forum/?fromgroups=#!topic/android-kernel/jQMx7802OBU HT: Todd Poynor At the very least, I'd love some benchmarking on droids once a 3.5 or 3.6 kernel exists on it with it built (HT: Todd Poynor) -- Dave Täht Fixing bufferbloat wi

[Codel] getting fq_codel tested in the next year (in the ubuntu 13.4 test series?) somehow

Jesper, Toke and I crashed the ubuntu kernel meeting at last weeks ubuntu developer summit in Copenhagen. We raised the issue of possibly getting fq_codel on on ubuntu by default (especially for desktops), and then had to explain bufferbloat to the meeting chair... About half the room then starte

[Codel] RFC: Realtime Response Under Load (rrul) test specification

I have been working on developing a specification for testing networks more effectively for various side effects of bufferbloat, notably gaming and voip performance, and especially web performance as well as a few other things that concerned me, such as IPv6 behavior, and the effects of packet

Re: [Codel] [Bloat] RFC: Realtime Response Under Load (rrul) test specification

On Tue, Nov 6, 2012 at 2:42 PM, Henrique de Moraes Holschuh wrote: > On Tue, 06 Nov 2012, Dave Taht wrote: >> I have been working on developing a specification for testing networks >> more effectively for various side effects of bufferbloat, notably >> gaming and voip perfor

Re: [Codel] RFC: Realtime Response Under Load (rrul) test specification

On Tue, Nov 6, 2012 at 9:52 PM, David Collier-Brown wrote: > Dave Taht wrote: >> I have been working on developing a specification for testing networks >> more effectively for various side effects of bufferbloat, notably >> gaming and voip performance, and especially w

Re: [Codel] RFC: Realtime Response Under Load (rrul) test specification

On Tue, Nov 6, 2012 at 7:14 PM, Rick Jones wrote: > On 11/06/2012 04:42 AM, Dave Taht wrote: >> >> I have been working on developing a specification for testing networks >> more effectively for various side effects of bufferbloat, notably >> gaming and voip perf

[Codel] preliminary BQL usbnet support. Testers wanted.

I do not have any usbnet devices at my disposal. Anyone? I think the old USB ipaqs were the first to use this infrastructure... pandaboard? rasperri pi? -- Forwarded message -- From: Oliver Neukum On Monday 12 November 2012 15:17:13 Dave Taht wrote: > http://www.spinics.

[Codel] GRO (generic receive offload) is not helpful with codel and fq_codel

I am fiddling with one of david woodhouse's machines (which is 16MBit down, .75Mbit up) Pouring packets through it, I noticed significant jitter while using HTB to rate limit, and saw maxpacket consistently hitting 14546, rather than staying at a MTU. Normally, when I see this, this is due to TSO

Re: [Codel] FQ_Codel lwn draft article review

David Woodhouse and I fiddled a lot with adsl and openwrt and a variety of drivers and network layers in a typical bonded adsl stack yesterday. The complexity of it all makes my head hurt. I'm happy that a newly BQL'd ethernet driver (for the geos and qemu) emerged from it, which he submitted to ne

Re: [Codel] FQ_Codel lwn draft article review

On Sat, Nov 24, 2012 at 1:07 AM, Toke Høiland-Jørgensen wrote: > "Paul E. McKenney" writes: > >> I am using these two in a new "Effectiveness of FQ-CoDel" section. >> Chrome can display .svg, and if it becomes a problem, I am sure that >> they can be converted. Please let me know if some other d

[Codel] DOCSIS + Codel paper published by cablelabs

Recently Greg White and a few others at Cablelabs, along with Kathie Nichols, did an exhaustive simulation of a cable modem with a default amount of buffering, vs the new short queue option, vs codel, in a wide variety of scenarios. The paper has just been released officially. http://www.cablelab

Re: [Codel] FQ_Codel lwn draft article review

On Mon, Nov 26, 2012 at 10:13 PM, Rick Jones wrote: > On 11/24/2012 08:19 AM, Dave Taht wrote: >> >> On Sat, Nov 24, 2012 at 1:07 AM, Toke Høiland-Jørgensen >> wrote: >>> >>> "Paul E. McKenney" writes: >>> The UDP ping tests tend to not

Re: [Codel] [Bloat] [Cerowrt-devel] FQ_Codel lwn draft article review

On Sun, Dec 2, 2012 at 10:47 PM, Andrew McGregor wrote: > > On 3/12/2012, at 10:37 AM, Toke Høiland-Jørgensen wrote: > >> Eric Dumazet writes: >> >>> This can help if you really want to avoid a thick flow sharing a thin >>> flow bucket, but given that all packets are going eventually into the >>

[Codel] physical demo of codel at the univerisity at modena

I did 30+ years of network queue theory in 1 hour 15 minutes to about 120 students at the University of Modena, using some physical demonstrations... This is the codel one... http://www.teklibre.com/~d/talks/video/20121128_152757.mp4 The raw video to the talk and the slide set are in that dir, h

Re: [Codel] [Cerowrt-devel] FQ_Codel lwn draft article review

On Mon, Dec 3, 2012 at 12:24 PM, Toke Høiland-Jørgensen wrote: > "Paul E. McKenney" writes: > >> And please see attached. Thoughts? > >"In addition, you network driver must be instrumented to support packet your ethernet network driver different technologies have different answers. BQL is

[Codel] hardware hacking on fq_codel in FPGA form at 10GigE

see: http://netfpga.org/ The quad gig-E version looks like it works well (in that there are advanced things like DRR available for it) but the underlying FPGA is obsolete. The quad 10GigE version looks sexy but not very functional as yet. In either case, implementing {n,e,s}fq_codel onboard looks

Re: [Codel] hardware hacking on fq_codel in FPGA form at 10GigE

On Thu, Dec 20, 2012 at 3:17 AM, Hal Murray wrote: > > If I was going to do something like that, I'd build a small/simple CPU and do > the work in microcode. There are two ppc 440 cpus already onboard the 10GigE device, I think. It's a REALLY NICE fpga. http://netfpga.org/10G_specs.html http://

Re: [Codel] hardware hacking on fq_codel in FPGA form at 10GigE

On Thu, Dec 20, 2012 at 4:13 AM, Dave Taht wrote: > On Thu, Dec 20, 2012 at 3:17 AM, Hal Murray wrote: >> >> If I was going to do something like that, I'd build a small/simple CPU and do >> the work in microcode. I'd also looked at the octeon and the latest ar

Re: [Codel] [Cerowrt-devel] hardware hacking on fq_codel in FPGA form at 10GigE

ious sorts using a breakout board > you can buy from Xilinx quicker than that. > > > > In some ways, this is the Raspberry Pi of high speed digital logic hacking. You should give them that quote. And I'll order one. Heck, maybe two. Real find! Thanks! How far along is y

Re: [Codel] [Cerowrt-devel] hardware hacking on fq_codel in FPGA form at 10GigE

OK, I ordered 2. It's not clear how the ethernet is fully implemented (The marvel phy is documented, the actual ethernet interface is not so far as I can see, so some source code reading is going to be required. ) I note that me doing this is also kind of driven by supplies of the wndr3800 drying

Re: [Codel] R: Making tests on Tp-link router powered by Openwrt svn

On Fri, Dec 21, 2012 at 5:19 AM, Alessandro Bolletta wrote: > Hi jonathan, > > > > This is how i configured the testbed: > > > > I have a windows 8 laptop connected directly on the tplink/openwrt router. > Tplink is also connected to a gigabit switch. > > So, i thought to make some file uploads fr

Re: [Codel] R: Making tests on Tp-link router powered by Openwrt svn

To be more clear here; You outlined your setup as: laptop <- TPLINK <- gigE switch <- server And your path for attempting fq_codel is on a samba download from the server. So it hits the gigE switch, gets buffered up and dropped there, and then has a clear path the rest of the way to your laptop.

Re: [Codel] [Cerowrt-devel] hardware hacking on fq_codel in FPGA form at 10GigE

It really is astounding what is going on in the arm world: http://www.hardkernel.com/renewal_2011/products/prdt_info.php?g_code=G135341370451 > The wndr3700v4 is out, and appears to be a good hardware upgrade from > the 3800 series, but it's not supported by openwrt yet. > > I took a look at thei

Re: [Codel] R: Making tests on Tp-link router powered by Openwrt svn

On Fri, Dec 21, 2012 at 6:06 PM, Kathleen Nichols wrote: > On 12/21/12 2:32 AM, Dave Taht wrote: >> On Fri, Dec 21, 2012 at 5:19 AM, Alessandro Bolletta >> wrote: > I don't understand why you are lowering the target explicitly as the use of > an MTU's worth of

Re: [Codel] R: Making tests on Tp-link router powered by Openwrt svn

On Fri, Dec 21, 2012 at 7:30 PM, Jim Gettys wrote: > > > > On Fri, Dec 21, 2012 at 12:51 PM, Alessandro Bolletta > wrote: >> >> Hi everybody, >> Thanks so much for your useful help! I solved my problem by reproducing >> bottleneck through HTB queues. >> I tried some bandwidth rates and i saw that

[Codel] fiddling with multicast file transfer with an alpha of uftp 4

One of my long term concerns with fairer queuing algos is the potentially enhanced effect of multicast on heavily bridged networks, as well as on wifi, which tends to run multicast at 1-6Mbit when "line rate" is 300Mbit, and has all sorts of interesting delayed behavior at CAP. I'd stuck uftp into

[Codel] Fwd: Stanford Networking Seminar, Thursday, January 31st @ 11:45am, Dave Taht (Bufferbloat Project)

ww.youtube.com/watch?v=bi-jumVNVGk ) While *this* talk will be filmed, I'm not sure if they'll let me bring the gatorade into the Gates building. -- Forwarded message -- From: Yiannis Yiakoumis Date: Mon, Jan 28, 2013 at 9:25 AM Subject: Stanford Networking Seminar, Thursday

[Codel] looking for a good image of slow start and congestion avoidance.

This had some nice animations but the slow start was too abstract... http://zst.utp.edu.pl/Technologie/TCP/TCP1.htm this one wasn't bad but would prefer to show slow start then packet drop behavior over a string of RTTs http://user.it.uu.se/~carle/Notes/images/SlowStart.png /me grumbles Anybod

[Codel] Stanford talk on "inside codel and fq_codel" is now online

I have to admit that most of the first 20 minutes is review for people here, but I'm hoping that we finally came up with a clear explanation of two of the phases in the codel algorithm, which starts about 28 minutes in. Kathie Nichols, Eric Dumazet and Luigi Rizzo were also there and we got a littl

[Codel] talk at mit feb 14 - what's wrong with wifi?

I will be on the east coast for the next 6 weeks or so (philly, cambridge, orlando). I am going to fit in a talk in there at MIT, on the tons of stuff we haven't worked on yet... perhaps some of you are on that coast? http://www.csail.mit.edu/events/eventcalendar/calendar.php?show=event&id=3592

Re: [Codel] FQ_Codel v. FQ_LQD

Also nice: http://perso.rd.francetelecom.fr/oueslati/Pub/xp-hpsr.pdf I'd been just down the street from you (at LINCS) multiple times in the past year. Pouring through the rest of your canon now... as for your referenced: http://www.tlc-networks.polito.it/oldsite/muscariello/papers/Kortebi-f18.

[Codel] Video of my talk at MIT "What's Wrong with WiFi?" is up

http://www.youtube.com/watch?v=Wksh2DPHCDI&feature=youtu.be the first half of this talk revises and extends on the previous talk at stanford (where I mostly talk about fq_codel, and RRUL). In particular I extended the slide set to include more examples, and have a rather killer one showing vast im

[Codel] revised Codel RFC is up

http://tools.ietf.org/html/draft-nichols-tsvwg-codel-01 -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html ___ Codel mailing list Codel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/codel

[Codel] the iccrg presos and some meeting notes from tsvarea at ietf

I had been wiped out by prepping for the previous days' iccrg meeting and overslept and didn't make the tsvarea meeting the next morning. I'm rather sorry I missed it! (portions of the iccrg were recorded, I don't know if there are minutes available(?)) Anyway, tsvarea minutes are up: http://ww

[Codel] Fwd: [Ns-developers] NS-3 has been accepted for GSOC 2013

Andrew and I haven't had time to update the ns3 model to the current versions of codel, fq_codel, and sfq_codel. I don't really expect that time to materialize. However I am certainly willing to mentor someone (other mentors would be good, too!) on moving the codebase forward (and developing furth

[Codel] blip: a tool for seeing internet latency with javascript

Apenwarr has developed a really unique tool for seeing latency and packet loss via javascript. I had no idea this was possible: http://apenwarr.ca/log/?m=201304#26 -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

[Codel] Latest codel, fq_codel, and pie sim study from cablelabs now available

Greg White and his team over at cablelabs have just published their latest simulation results of the aqm algorithms under test on simulated cable modems. This paper is vastly expanded from the presentation at ietf 86 iccrg, including great descriptions the effects of latency on web, voice, and gam

Re: [Codel] [Bloat] Latest codel, fq_codel, and pie sim study from cablelabs now available

Eric, you supplied the prio scheduler example as an example of how it shouldn't work, right? On Tue, May 7, 2013 at 1:30 PM, Eric Dumazet wrote: > On Tue, 2013-05-07 at 14:56 -0500, Wes Felter wrote: > > > Is it time for prio_fq_codel or wfq_codel? That's what comes to mind > > when seeing the B

Re: [Codel] [Bloat] Latest codel, fq_codel, and pie sim study from cablelabs now available

On Mon, May 13, 2013 at 9:56 PM, Tristan Seligmann wrote: > On Tue, May 14, 2013 at 4:26 AM, Dan Siemon wrote: > >> It's pretty easy to configure the Transmission Bittorrent client to mark >> packets. >> > It is not clear to me that transmission correctly marks uTP traffic, particularly on IPv6.

Re: [Codel] [Bloat] Network test tools for many parallel/concurrent connections?

I still use tcptrace and xplot.org for deep dives. I just fired off 2048 netperfs to localhost on my laptop. It started bogging down at 1000 but made it to the end, all connections chugging away. Probably a better tool would be the apache benchmark `ab` or something else that is built to stress

Re: [Codel] [Bloat] Network test tools for many parallel/concurrent connections?

On May 14, 2013 12:21 PM, "Stephen Hemminger" wrote: > > On Tue, 14 May 2013 15:48:38 +0200 > Jesper Dangaard Brouer wrote: > > > > > (I'm testing fq_codel and codel) > > > > I need a test tool that can start many TCP streams (>1024). > > During/after the testrun I want to know if the connections

[Codel] freebsd version of codel appears

Interestingly it appears to have a hook directly into hfsc, optionally replacing red. https://github.com/pfsense/pfsense-tools/blob/master/patches/RELENG_10_0/altq_codel.diff picked up via my usual daily scan from: http://freebsd.1045724.n5.nabble.com/PATH-ALTQ-9-codel-algorithm-implementation-t

Re: [Codel] freebsd version of codel appears

On Tue, Jun 11, 2013 at 7:38 AM, Simon Perreault < simon.perrea...@viagenie.ca> wrote: > Le 2013-06-11 13:39, Hrvoje Popovski a écrit : > > maybe it is good to know that original patch came from OpenBSD community >> >> http://comments.gmane.org/**gmane.os.openbsd.tech/29745

[Codel] RRUL

dpoints, and get 3ms worth of latency e2e. I mean, I ultimately want to get to where I have netem fired up on 2atom with long rtts to multiple "servers", and random packet loss/delay/reordering but just getting to where 4 boxes produced results that made a tiny bit of sense has taken weeks.

Re: [Codel] [Cerowrt-devel] happy 4th!

this really, really, really is the wrong list for this dialog. cc-ing codel On Mon, Jul 8, 2013 at 11:04 PM, Mikael Abrahamsson wrote: > On Mon, 8 Jul 2013, Toke Høiland-Jørgensen wrote: > >> Did a few test runs on my setup. Here are some figures (can't go higher >> than 100mbit with the hardware

[Codel] sprout

I haven't been paying a lot of attention to rmcat and webrtc until recently, although I'd had a nice discussion with keith on it a while back.. this particular thread sums up some interesting issues on that front. http://www.ietf.org/mail-archive/web/rmcat/current/msg00390.html -- Dave Täht Fi

Re: [Codel] sprout

erybody else, you can't fix > bufferbloat by fixing just one endpoint. We will have some results soon on > whether you can fix it by fixing all the endpoints (but still leaving the > "bloated" gateway intact). > > Cheers, > Keith > > On Wed, Jul 10, 2013 at 3:30

Re: [Codel] sprout

On Wed, Jul 10, 2013 at 1:46 PM, Jim Gettys wrote: > > > > On Wed, Jul 10, 2013 at 4:41 PM, Keith Winstein wrote: >> >> On Wed, Jul 10, 2013 at 4:38 PM, Jim Gettys wrote: >>> >>> Did you compare with fq_codel? None of us (Van included) advocate CoDel >>> by itself. >> >> >> Hi Jim, >> >> In our

Re: [Codel] sprout

On Wed, Jul 10, 2013 at 3:10 PM, Kathleen Nichols wrote: > Is that indeed what I think? Heh. On another topic, at my stanford talk, you pointed at maxpacket being a thing you were a bit dubious about. After fiddling with the concept in presence of offloads (which bloat up maxpacket to the size of

[Codel] hardware multiqueue in fq_codel?

In my default environments (wifi, mainly) the hardware queues have very different properties. I'm under the impression that in at least a few ethernet devices they are essentially the same. That said, in the sch_mq case, an entirely separate qdisc is created per hardware queue, and it's always bee

Re: [Codel] sprout

On Thu, Jul 11, 2013 at 9:54 AM, Kathleen Nichols wrote: > > Yes. I think that's a sort of "application - dependent" bit of code perhaps. > Van and I had various discussions about this and put that in with very > low bandwidth applications in mind, where some "maximums" might > be much smaller tha

Re: [Codel] hardware multiqueue in fq_codel?

On Thu, Jul 11, 2013 at 10:44 AM, Eric Dumazet wrote: > On Thu, 2013-07-11 at 10:09 -0700, Dave Taht wrote: >> In my default environments (wifi, mainly) the hardware queues have >> very different properties. >> >> I'm under the impression that in at least a

[Codel] useful netem-based testing?

My results with netem were generally so dismal that I'd abandoned it. I just finished building a bunch of kernels from net-next with eric's improvements to it, so I'm about to try it again. My intent is to duplicate most of the RTTs cablelabs simulated with, under essentially the same workloads, a

  1   2   3   >