Just we've done with debloat-testing, I'd like to have a git tree with
all the common shaper scripts in it.
We can do it on github, infradead, someone's private domain, etc.
suggestion for a name (debloat-shapers)?
Location?
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blo
The
http://events.linuxfoundation.org/events/collaboration-summit
is a free summit, if anyone here is based in or near San Francisco and
can attend...
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com
___
Bloat mailing l
The new build server (huchra.bufferbloat.net) is mostly up, as are a few
virtuals for handling things like builds of openwrt, and other
mainstream OSes, and overall management of the site.
We could use a few helpers in getting the virtuals fully configured and
operational (buildbot, hudson, r
On Wed, Mar 30, 2011 at 3:11 PM, John W. Linville
wrote:
> FYI...
>
> I have rebased the wireless-testing tree on 2.6.39-rc1. As previously
> stated, I plan to track the -rc and final releases, rebasing on
> each -rc1. The rebase is a little ugly/painful, but it is a good
> way to avoid building
I am attending this Rohan Narayana Murty talk today. Whitefi and Dyson
seems interesting. He proposes a mcham "Multi Channel Airtime Metric"
for arbitrarily borrowing channel whitespace from the TV spectrum in
particular...
http://www.eecs.harvard.edu/~rohan/Overview.html
The hardware prototy
Anyone doing anything for nanog?
Original Message
Subject:[NANOG-announce] NANOG 52 CFP Reminder: Slides due 4/11
Date: Sun, 10 Apr 2011 09:24:39 -0400 (EDT)
From: Tom Daly
To: nanog-annou...@nanog.org
NANOG'ers,
On Thursday, 4/14, the NANOG Program Committee
Constructive comment from bufferbloat-ers would be good! There is a May
26th deadline.
Extracted from:
http://hraunfoss.fcc.gov/edocs_public/attachmatch/DA-11-661A1.pdf
"This Public Notice seeks input on the particular types of “need for
speed”3 information that are most useful to consumers a
You may have created an earworm.
Everytime I encountered a bug when trying to work with the web interface
on the bismark project yesterday, I kept crying out in Desi Arnaz's voice...
"LUCII!"
http://www.bufferbloat.net/issues/80
On 04/12/2011 11:24 PM, Fred Baker wrote:
I think it's a
The email box crashes reliably every 2 weeks or so, so we are moving it
to another server friday.
Sorry for the delayed emails to the list(s).
I have been traveling too heavily to co-ordinate the change-over before now.
Manaña!
___
Bloat mailing lis
In my travels this month I have been testing ECN enablement at homes and
hotels everywhere I go.
Until today, I was able to have the following settings for ECN on my
laptop everywhere I've been.
net.ipv4.tcp_ecn=1
#net.ipv6.tcp_ecn=0
net.ipv4.tcp_sack=1
net.ipv4.tcp_dsack=1
However, I got to
I'd intended to write up summaries of bufferbloat related activity once
a month, but am running a bit behind. Both JG and I have been travelling
heavily.
There's been a lot going on under the covers!
Probably the biggest news is that we are working with Georgia Tech on
their bismark project.
I will be performing upgrades and fixes to the bufferbloat web, build
and email servers today.
Expect periodic outages throughout the afternoon, starting now.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bl
Not bad, although I can live without the title. Coins a new-ish phrase
"insertion latency"
http://www.networkcomputing.com/end-to-end-apm/bufferbloat-and-the-collapse-of-the-internet.php
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com
, Apr 26, 2011 at 12:13 PM, Dave Hart wrote:
> On Tue, Apr 26, 2011 at 17:05 UTC, Dave Taht wrote:
>> Not bad, although I can live without the title. Coins a new-ish phrase
>> "insertion latency"
>>
>> http://www.networkcomputing.com/end-to-end-apm/bufferbloa
I will be meeting with jim after his talk at google today, and perhaps
we can nail a few ideas to the wall.
What did you want your talk to be, john?
Ideas:
1) Beating the Bloat - a progress update from the project
2) Latency matters - the real behavior of voip, gaming, dns, arp, etc,
under Linu
On Tue, Apr 26, 2011 at 12:32 PM, Wesley Eddy wrote:
> On 4/26/2011 2:17 PM, Dave Taht wrote:
>>
>> "Big Buffers Bad. Small Buffers Good."
>>
>> "*Some* packet loss is essential for the correct operation of the
>> Internet"
>>
>> a
On Tue, Apr 26, 2011 at 2:30 PM, Constantine Dovrolis
wrote:
> Thanks Wes - I was hoping that someone will make this point.
>
> btw, another common reason for lossless operation is the
> size of the flows. basically flows often finish before their
> window increases so much that they overflow thei
2:34 PM, John W. Linville wrote:
> On Tue, Apr 26, 2011 at 01:29:57PM -0600, Dave Taht wrote:
> > I will be meeting with jim after his talk at google today, and perhaps
> > we can nail a few ideas to the wall.
> >
> > What did you want your talk to be, john?
> >
I was extremely amused to see an actual **ad** just now in my gmail account
targetting bufferbloat,
which ultimately after making me signup on their website (I gave my usual
addresses of a...@asdf.org, etc)
Sent me to this:
http://media.ciena.com/documents/ActivSpan_4200_Boosts_Competitive_Advan
I am curious as to what the correct behavior here should be for encapsulated
(6in4, 6to4, teredo) packets, and if this functionality was also borked. I
was under the impression that for encapsulated packets the tos field was
copied from the encapsulated packet to the ipv4 header.
I will make a not
On Fri, May 6, 2011 at 12:18 PM, Jonathan Morton wrote:
>
> On 6 May, 2011, at 9:14 pm, Dave Taht wrote:
>
> > I am curious as to what the correct behavior here should be for
> encapsulated (6in4, 6to4, teredo) packets, and if this functionality was
> also borked. I was unde
If you have not already joined the wiki for read/write privs, please do so!
IF you already have established an account it would help me a lot to get
correct privs to you if you would clearly identify your expertise by logging
into the web site and filling out the "expertise" field.
http://www.buf
I am modestly stumped as to how to solve this properly. I think it's been
causing problems with ipv6 for a long time, but I could be wrong.
see http://www.bufferbloat.net/issues/126
Basically although the underlying interfaces do have unique mac addresses
(for some reason the underlying eth0 inte
Final patch found, merged into openwrt (tested on 2.6.38, 2.6.37), and
incorporated into the bismark and iscwrt builds. Nice catch.
I hope the next round of sfb testing goes much better.
On Fri, May 6, 2011 at 1:42 PM, Dave Taht wrote:
>
>
> On Fri, May 6, 2011 at 12:18 PM, Jonath
On Mon, May 9, 2011 at 2:14 AM, Fred Baker wrote:
>
> On May 8, 2011, at 8:26 PM, Dave Taht wrote:
>
> > Is there a standard for renaming fe80:: addresses to represent they are
> interfacing with different vlans?
>
> well, yes. Link-local addresses (FE80::/10) areas you s
Fred/all
See
http://www.bufferbloat.net/issues/126
which has a ip -6 addr and ifconfig dump
and see if that "seems right" to you.
On Mon, May 9, 2011 at 9:57 AM, Fred Baker wrote:
>
> On May 9, 2011, at 7:59 AM, Dave Taht wrote:
> > On Mon, May 9, 2011 at 2:14
There's a new qdisc on the block. Here's some documentation on how it works.
-- Forwarded message --
From: John Fastabend
Date: Mon, May 9, 2011 at 11:22 AM
Subject: Re: trying to wrap my head around mqprio
To: Dave Taht
On 5/8/2011 12:49 AM, Dave Taht wrote:
> I
On Mon, May 9, 2011 at 10:44 AM, Fred Baker wrote:
> BTW, every time I post nowadays, I get moderated on bismark-devel. Do you
> think you could grandfather bloat@ emails?
>
>
I've added you to the bismark-devel list and set nomail on.
> On May 9, 2011, at 9:14 AM, Dave
I did a preliminary test of a bismark router with ECN and red enabled using
a lightly modified
version of openwrt's (nbd's) qos-scripts, doing a scp upload from my laptop
to a server at bufferbloat.net.
I artificially throttled the uplink at 1Mbit and downlink to 10Mbit (the
measured real values
On Tue, May 10, 2011 at 8:30 AM, Jeremy Visser wrote:
> Dave Taht said:
> > the bridged to a vlan fe80:: addresses are all the same. This strikes me
> > as a problem.
>
> You never reference link-local address by themselves anyway — they are
> always referenced with th
9640 kB
> Mapped: 27800 kB
> Slab: 9620 kB
> SReclaimable: 1388 kB
> SUnreclaim: 8232 kB
> PageTables: 760 kB
> NFS_Unstable:0 kB
> Bounce: 0 kB
> CommitLimit: 62048 kB
> Committed_AS:43156 kB
> V
On Tue, May 10, 2011 at 10:40 PM, Roland Bless wrote:
> Hi Dave,
>
> On 11.05.2011 05:32, Dave Taht wrote:
> > 1) in a wireshark analysis, the %interface part is lost
>
> But your wireshark is listening on some specific interface,
> isn't it?
No. It is listening
I think it would be more useful for me to describe the context behind the
fe80:: thread also
on this list.
In the case of wireless interfaces, very little QoS and packet
prioritization has been taking place
with the various qdiscs being used. (Linux uses "mq" by default, which is
severely underdoc
On Fri, May 13, 2011 at 8:35 AM, Rick Jones wrote:
> On Thu, 2011-05-12 at 23:00 -0600, Kevin Gross wrote:
> > One of the principal reasons jumbo frames have not been standardized
> > is due to latency concerns. I assume this group can appreciate the
> > IEEE holding ground on this.
>
> Thusfar a
t well above 20ms
It is astonishing that a switch chip this capable has reached the consumer
marketplace...
http://realtek.info/pdf/rtl8366s_8366sr_datasheet_vpre-1.4_20071022.pdf
And depressing that so few of it's capabilities have software to configure
them.
> Kevin Gross
>
>
>
> *
On Mon, May 16, 2011 at 7:42 AM, Kevin Gross wrote:
> I would like to try this. Can you suggest specific equipment to look at.
> Due
> to integration and low port count, most of the cheap consumer stuff has
> surprisingly good layer-2 performance. I've tested a bunch of Linksys and
> other small/
On Tue, May 17, 2011 at 1:49 AM, wrote:
> (I think) Fred wrote:
> > Well, the extra delay is solvable in the transport. The question isn't
> really what the impact on the > network is; it's what the requirements of
> the application are. For voice, if a voice sample is
> > delayed 50 ms the jitte
The default qos-scripts for openwrt are being tested in south africa right
now as part of the first bismark 'capetown' deployment of a whole bunch of
wndr3700v2 routers.
Bismark contains extensive debloating of the ar71xx, and ath9k device
drivers and
shortened txqueues.
On the plus side, the qo
On Sat, May 21, 2011 at 1:11 PM, Jonathan Morton wrote:
>
> On 21 May, 2011, at 5:27 pm, Dave Taht wrote:
>
> > Experience the pain of the Internet on another continent! (note that the
> gw is up on ipv6 as well)
>
> Well, it's not very fast in terms of throughput,
On Sat, May 28, 2011 at 2:07 PM, Juliusz Chroboczek wrote:
> > SFB is also in this release, but lacking good scripts for it...
>
> SFB is supposed to be self-tuning, so it should be enough to say
> something like:
>
> #!/bin/sh
> set -e
>
> if=${1:-eth0}
>
> tc -s qdisc del root dev $if 2>/dev
So after my experiments [1] yesterday with the wndr3700v2 hardware[2], I
came away
even more convinced that the wireless world and the wired worlds should
not be bridged together.
All the AQMs out there assume that it takes the same period of time to
deliver a packet consisting of X bytes to the n
On Sun, May 29, 2011 at 8:10 AM, Jonathan Morton wrote:
>
> On 29 May, 2011, at 4:23 pm, Dave Taht wrote:
>
> > In my last 2 months of travel, I have seen multicast packets, such as
> ARP, DHCP, MDNS, and now babel, all failing far, far, far more often than is
> desirable.
On Sun, May 29, 2011 at 9:33 AM, Juliusz Chroboczek wrote:
> > Result - 130+Mbit performance on iperf on the lan (up from 60Mbit),
> > which is still pretty low
>
> Are you seeing high CPU load in interrupt context? (Run top.)
>
>
Yes. 99% sirq.
Screenshot:
http://www.bufferbloat.net/attachmen
On Sun, May 29, 2011 at 9:21 AM, Juliusz Chroboczek wrote:
> > And the irony is that the lower speed is specifically chosen for
> > multicast in order to make sure all clients in range can hear them
> > reliably.
>
> It was my understanding that it was done for compatibility with older
> devices,
On Sun, May 29, 2011 at 9:51 AM, Juliusz Chroboczek wrote:
> >> Are you seeing high CPU load in interrupt context? (Run top.)
>
> > Yes. 99% sirq.
>
> Could be due to a simplistic Ethernet driver. If you have the time and
> energy, you may want to ask on dev.openwrt.org.
>
> I will have some ene
sorry, I meant to reply all.
Thanks for so quickly seeing the real cause of the upper limit.
On Sun, May 29, 2011 at 10:07 AM, Dave Taht wrote:
>
>
> On Sun, May 29, 2011 at 9:51 AM, Juliusz Chroboczek
> wrote:
>
>> >> Are you seeing high CPU load in interrupt conte
The datasheet has insufficient detail, and yet the switch seems enormously
>> capable, at least in theory. The kind of numbers under load I've seen thus
>> far (ranging from .9ms to 170ms) suggest port starvation.
>>
>> http://realtek.info/pdf/rtl8366s_8366sr_datasheet_vpre-1.4_20071022.pdf
>>
>
In
On Sun, May 29, 2011 at 10:33 AM, Eric Dumazet wrote:
> Le dimanche 29 mai 2011 à 10:07 -0600, Dave Taht a écrit :
> >
> >
> > On Sun, May 29, 2011 at 9:51 AM, Juliusz Chroboczek
> > wrote:
> > >> Are you seeing high CPU load in i
On Sun, May 29, 2011 at 11:17 AM, Eric Dumazet wrote:
> Le dimanche 29 mai 2011 à 11:02 -0600, Dave Taht a écrit :
>
> > The kernel being used in capetown[1] is 2.6.37.6. - patched forward
> > from 2.6.39 for the pfifo ecn bug, the ipv6 ecn bug, and several other
> > bu
On Sun, May 29, 2011 at 10:24 PM, George B. wrote:
> Ok, say I have a network with no over subscription in my net.
I'd love to see one of those. Can I get on it?
> I have
> 10G to the internet but am only using about 2G of that. This is the
> server side of a network talking to millions of c
On Mon, May 30, 2011 at 9:29 AM, George B. wrote:
> On Mon, May 30, 2011 at 5:25 AM, Dave Taht wrote:
> >
> >
> > On Sun, May 29, 2011 at 10:24 PM, George B. wrote:
> >>
> >> Ok, say I have a network with no over subscription in my net.
> >
>
Seeing ECN and DSCP in an ESP ipsec tunnel of a TCP stream, with all the
inner DSCP/ECN bits preserved on the outer packet, going from here (FL) to
gatech through a doubly natted tunnel via strongswan...
...gives me a warm and fuzzy feeling that I have been lacking of late, about
the health of the
So in addition to hacking on the switch, I've been poking into the behavior
of multiple AQM systems in the kernel, ranging from the wondershaper,
to the adsl-shaper, to the qos-scripts in openwrt.
I started off with something ambitious, which was to try and implement
a complete implementation of d
On Wed, Jun 8, 2011 at 6:56 AM, Eric Dumazet wrote:
> Le mercredi 08 juin 2011 à 06:12 -0600, Dave Taht a écrit :
>
> > SFQ is the second most commonly used qdisc, but doesn't balance in
> > ways ESFQ could.
> >
> > ESFQ really looked like a winner and I
ification that has not been done
to date.
On Wed, Jun 8, 2011 at 7:32 AM, Dave Taht wrote:
>
>
> On Wed, Jun 8, 2011 at 6:56 AM, Eric Dumazet wrote:
>
>> Le mercredi 08 juin 2011 à 06:12 -0600, Dave Taht a écrit :
>>
>> > SFQ is the second most commonly used qdisc
On Wed, Jun 8, 2011 at 8:57 AM, Eric Dumazet wrote:
> Le mercredi 08 juin 2011 à 08:04 -0600, Dave Taht a écrit :
> > It looks like adding ECN to the other qdiscs would be good, and
> > transparent to the upper layers, but a 10 minute glance at HTB seems
> > to make it a
I agree that the new (1997) solution for SFQ, embedding the
>
Sorry, meant 2007.
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/
On Wed, Jun 8, 2011 at 9:45 AM, Eric Dumazet wrote:
> Le mercredi 08 juin 2011 à 11:27 -0400, Jesper Dangaard Brouer a écrit :
>
>> While this is a good coding approach, the end result is that nobody is
>> using this stuff, because "tc" is so difficult to use, and its error
>> feedback is so lousy
On Wed, Jun 8, 2011 at 10:41 AM, Eric Dumazet wrote:
> Le mercredi 08 juin 2011 à 09:51 -0600, Dave Taht a écrit :
>
>>
>> And they are *all* wrong to varying extents, which is why I like the
>> 'mondo classifier' idea for DSCP+firewalling mentioned earlie
I'm going to make some notes against my original posting 'Some notes
on hacking on AQM's' here, because in less than a day, much progress
been made.
On Wed, Jun 8, 2011 at 6:12 AM, Dave Taht wrote:
> So in addition to hacking on the switch, I've been poking into the
Before I go to the trouble of writing up an RFC, I thought perhaps
here (and the end-to-end list) would be a good place to discuss some
ideas towards adding 3 new codepoints to diffserv,
in an enhancement to rfc4594[1] - http://tools.ietf.org/html/rfc4594
I've named them with something of a sense
So I sat down and took the fragments of various qos scripts I'd been
fiddling with, and came up with a diffserv
classifier (doesn't do qos or cope with nat yet) that matches a great
deal of traffic somewhat sanely (notably 'IT', 'mice', and ipv6). It
should work on any linux box, as well as openwrt
trying to move Linux forward from 1998...
>
> On 11 Jun 2011, at 16:15, Dave Taht wrote:
>
>> I was unable to come up with a back-acronym for 'mice'. I got as
>> far as 'majorly important' before getting stuck on the 'c'.
>
--
Dave Täht
SKYP
:(
But:
http://linuxwireless.org/en/developers/Summits/Vancouver-2011
In mid-august, looks more apt, followed by linuxcon.
We are also getting close to a point where it would be fun and
informative to be
testing debloated routers at scale, too.
Can we still get in this conference?
--
Dave Tä
On Mon, Jun 13, 2011 at 2:32 PM, John W. Linville
wrote:
> On Mon, Jun 13, 2011 at 09:08:13AM -0600, Dave Taht wrote:
>> :(
>
> This is news to me (and I'm on the program committee) -- where did
> you hear this?
Didn't see it in the approved tracks.
>
>> B
http://ubnt.com/airview
I'm about to order one. Heck, I might order a couple. I've been trying
to track down an
elusive bug in 802.11e handling for days.
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com
___
Bloat ma
When you have to retry sending a packet in swretry at a wireless
driver (mac802.11?) level, marking it as 'congested' seems to make sense.
If you are going to make heroic efforts to deliver packets in the
first place, you might as well tell the receiver of your heroism.
While retry is normal, eve
On Wed, Jun 15, 2011 at 4:08 PM, Hagen Paul Pfeifer wrote:
> * Dave Taht | 2011-06-15 07:24:33 [-0600]:
>
>>http://ubnt.com/airview
>>
>>I'm about to order one. Heck, I might order a couple. I've been trying to
>>track down an elusive bug in 802.11e handli
Well there is a lot of stuff that has been fed into 2.6.39 and later that
came
from the debloating work. In particular ECN and DSCP should 'just work'
now under all circumstances (or so I hope) on both ipv6 and ipv4.
So at the moment, debloat-testing is looking rather bare, but it's been
surving
a
While searching for a paper I remember reading back in the early 90s
about self similarity in network streams I stumbled across this
http://www.ceid.upatras.gr/faculty/manos/courses/highspeednets/2006/papers/veres00chaotic.pdf
I'm hoping what I was actually looking for is in the cites, but this
p
On Thu, Jun 23, 2011 at 4:38 PM, Juliusz Chroboczek wrote:
>> I will also attempt to argue persuasively that having ECN packet marking in
>> HTB
>
> I'm not following you. You can only perform ECN marking when you detect
> congestion; and you can only detect congestion if you're queueing.
> I ma
On Thu, Jun 23, 2011 at 4:45 PM, Juliusz Chroboczek wrote:
>> It really seems that ECN support could be added generically for all
>> qdiscs that currently do packet drop. Creating a generic mark_or_drop
>> function is easy.
>
> As hinted in a previous message -- please don't. Every qdisc must be
On Thu, Jun 23, 2011 at 11:01 PM, Eric Dumazet wrote:
> Le jeudi 23 juin 2011 à 17:10 -0600, Dave Taht a écrit :
>> On Thu, Jun 23, 2011 at 4:45 PM, Juliusz Chroboczek
>> wrote:
>> >> It really seems that ECN support could be added generically for all
>> >&g
On Fri, Jun 24, 2011 at 3:10 AM, Dave Taht wrote:
> On Thu, Jun 23, 2011 at 11:01 PM, Eric Dumazet wrote:
>> Once qdisc queue is _full_, its too late, you have to drop packets
>> anyway. And its not because at least one flow is not responsive :
>> It might be because one
As I continue to fiddle with deeply understanding one entirely open
source router[1] in the context of bufferbloat by running tons of
wildly varied traffic through it...
I could be filing individual bug reports in the right places or the
right mailing list, or (preferably) writing something other
After a long gestation, we're happy to announce the existence of a 'smoke
test' release of 'CeroWrt', for the NETGEAR WNDR3700v2 series of routers.
Documentation, flash images, and installation guide are at:
http://www.bufferbloat.net/projects/cerowrt/wiki/OCEAN_CITY_INSTALLATION_GUIDE
This smok
If anyone can spare some eyeballs for the discussion of wireless-n AMPDUs
and their interaction with bufferbloat, and groks TCP's behavior and/or
wireless's behavior, I'd appreciate some comment on:
http://www.bufferbloat.net/issues/216
Losing SOME appropriate packets, somewhere in the wireless s
I think I'd like to have one or more of these to test with:
http://www2.litepoint.com/products/manufacturing/iqflex
Anybody have one or know someone that does?
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com
___
Bloat m
Dear Hector:
We're getting to where all the sources will be publicly available via a
simple build script. Regrettably the script and repos have cleanup problems
right now that I hope to solve by Friday, and I plan to push out a few of
the main patches into openwrt in that timeframe as well. There
s root qdisc is necessary to model the hardware queues and
> the MAC queues in 802.11 correctly - you're not queuing lots of frames in
> the driver, rather extending the queuing system to implement parts of the
> MAC.
>
> Simon
>
>
> On 08/01/2011 06:30 AM, John W. Lin
Given how devastatingly effective my call to the list for help was, on:
http://www.bufferbloat.net/issues/216
http://www.bufferbloat.net/issues/195
(195 is NAILED right now, 216 is making serious progress - see the bug
reports for more details)
I figure that perhaps leveraging y'all expertise to
All those protocols are too 'ANT'-like - nearly at the level of statistical
noise. Need a much bigger hammer than that to play with.
That said, there's plenty of problems showing up in the noise...
On Wed, Aug 3, 2011 at 1:18 PM, Dave Hart wrote:
> On Wed, Aug 3, 2011 a
So as we march down towards *maybe* having a modestly debloated router ready
for the Linux Wireless summit in Vancouver, august 15th, I'd let logos,
t-shirts, and hats - classic stuff like that - for the project - slide
overlong.
Jim did one up for bufferbloat a while back, (
http://www.cafepress.
This is the first release containing fixes to bugs 216 and 195 - now that
those bugs are stomped, we hope to start working up the stack and finally
start beating the bloat, for real.
This version has tcp_low_latency enabled by default, 5 different tcp
algorithms and the usual horde of stuff docume
I note that rc6 is not ready yet, but rc5 is REALLY promising, and more
people testing that now would make rc6 all the better.
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com
___
Bloat mailing list
Bloat@lists.bufferbloa
The chair of the UK Network Operators' Forum (UKNOF), Keith Mitchell,
cc'd, has asked if we can provide a speaker for the upcoming meeting
in Bristol, Tue, 6th September.
As both jg and I are going to be at the Linux Plumbers conference that
week, I'm wondering if anyone from our European continge
-- Forwarded message --
From: Jim Gettys
Date: Sat, Sep 10, 2011 at 10:45 AM
Subject: Fwd: caidathoughts on bufferbloat
To: Dave Taht
Note the moosehaper. Worth reading through in general.
on caida chat room so far:
kenyon says, "hooray bufferbloat believers. I&#x
I think this possibly explains why I ended up routing ipv6 everywhere
rather than bridging it.
-- Forwarded message --
From: Chuck Anderson
Date: Tue, Sep 13, 2011 at 1:00 PM
Subject: bridge should flood non-IPv4-multicast ethernet frames
To: net...@vger.kernel.org
When the bri
I have seen the new 3800 model now entering stores. Judging from the
clock rate (680 mhz) and feature set, it does *look like* a souped up
atheros based platform, and the extra ram would come in handy.
It would be my hope that this box would 'just work' but I don't know
anyone that has tried one,
As the kernel development process has slowed due the ongoing recovery
from the kernel.org, bottlenecking changes to cerowrt and
debloat-testing... and I can't offer anything but empathy to those at
kernel.org getting things back online
... and I just arrived in Paris to work out of the lincs.f
I am presently wading through the following thesis by a researcher
here at lincs.
http://perso.telecom-paristech.fr/~valenti/pmwiki/pmwiki.php?n=Main.PhDDefense
The portions regarding LEDBAT (chapter 8 onwards) are particularly interesting.
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
ht
I am giving a public talk tomorrow (wednesday, october 19th) at 14:00
entitled
'Analyzing Bufferbloat in wireless networks'
In Paris, France, at the lincs lab, 4th floor, room #24
I fully intend to give this talk again, (whereever in Europe I am asked!!)
as I'm still shaking the bugs out of it.
Wow. 3 flashers in one day. (there is no specific cerowrt list, this is as
good a place as any, at least for now)
I will try to improve the flashing instructions but to clarify here:
the 'FACTORY' images are are for installing when you have factory firmware
installed. Usually, but *not always*, y
7;"
Dibbler is old, and what's in git is improving but unstable. I really don't
know what to use. I have a request from comcast to use something, anything,
but...
When I connected the router to my main ipv6 enabled router, it was able
> to pick the ipv6, but something still wron
rc7-smoketest10 is out in the usual place.
Fix for the wifi detect routine, re:
https://dev.openwrt.org/ticket/10350
Also jow had been busy abstracting out network protocol support from the
web interface, I added ipv6 as std, 3g as optional. (package is
luci-proto-whatever)
TOTALLY untested.
s
I just spent the last 6 months not talking about the debloat-testing kernel.
The initial test results sucked for eBDP and A* in it.
I didn't trust any layer of the stack at that point in time. Definately not
the iwl driver. (I still don't trust the iwl driver!).
(I tend to use eBDP and A* as syn
oops, correction:
On Mon, Nov 7, 2011 at 8:10 PM, Dave Taht wrote:
>
>
> This is just plain wrong. In wireless-g the relationship between these
> queues is far more sane than in -n. Aggregation doesn't currently happen in
> the VO(?) queue - thus in addition to having a la
On Mon, Nov 7, 2011 at 8:25 PM, John W. Linville wrote:
> On Mon, Nov 07, 2011 at 08:10:57PM +0100, Dave Taht wrote:
>
> > John was right when he wrote in the initial announcement:
> >
> > "This version runs separate instances of the algorithm for each WMM
> >
just stumbled across this old piece which links to some of the original
discussions around what has become called bufferbloat since, and also had
some links to papers I hadn't read.
http://blogs.broughturner.com/2009/10/is-att-wireless-data-congestion-selfinflicted.html
I'm curious as to who is m
On Tue, Nov 8, 2011 at 8:05 PM, Andrew Hammond <
andrew.george.hamm...@gmail.com> wrote:
> My friend owns and operates a small ISP that serves a small town and the
> surrounding rural area.
>
> His current setup is wireless routers in bridge mode.
>
>
Heh. I would suspect he has scaling problems.
1 - 100 of 1935 matches
Mail list logo
