Re: ANNOUNCE: debloat-testing kernel git tree

Sedat Dilek [off-list ref] writes:

On Sun, Feb 27, 2011 at 4:56 PM, Dave Täht [off-list ref] wrote:

quoted

Sedat Dilek [off-list ref] writes:

quoted

On Sun, Feb 27, 2011 at 4:31 PM, Dave Täht [off-list ref] wrote:

quoted

Sedat Dilek [off-list ref] writes:

quoted

Are you planning debloat feature for 2.6.39?

Depends on how many testers we get and what the results are.

I feel the eBDP stuff will not be ready during this release cycle. SFB
and CHOKe are in net-next, so, probably. Various driver patches -
particularly those that increase the available dynamic range via
ethtool, (e.g lowering the bottommost TX queue limit to, like, 4,
especially for home gateways) may make it out if people look harder into
the issue.

OK, thanks for the explanations.

Concerning "more drivers":
What would I have to do to modify ath5k?
I looked into the ath9k patch in debloat-testing GIT and it was to mod
some (TX/BUF) values only.

Yes, reducing your TX buffer size greatly is the first, best, and
easiest patch.

For wireless routers and cable home gateways especially, this research
shows that the total un-managed buffers in your system should be less
than 32.

http://www.cs.clemson.edu/~jmarty/papers/PID1154937.pdf

I found their data convincing, and there are dozens of other papers that
we are sorting out on the bufferbloat.net web site.

(PLEASE Note the key word there is un-managed)

0 would be the best value. :/

In the case of wireless, you also have retries to take into account.
I'd argue in those cases, that what I say above is that the number
should be FAR less than 32.

Now, whether there is a good compromise between throughput and latency
in that range in a DMA TX queue + TXQUEUE, remains to be seen. 

Not sure if ath9k is/was "well" prepared or only a good choice by the
testers/committers as they own such a device.

My test network is mostly ath9k - the nanostation M5s and the WNDR5700
router described here:

http://www.bufferbloat.net/projects/bloat/wiki/Experiment_-_Bloated_LAGN_vs_debloated_WNDR5700

There are people looking into the ath6kl, but you're the first to step
up with the ath5k. :) Maybe the folk over at #ath6kl on irc can help.

The ath9k patch improves latency under load enormously - I can run voip
over it AND do big transfers and stream audio via samba... Which I
couldn't before - and DNS, ND, NTP, babel, etc behave much better, but
the currently hard coded nature of the TX queue limit does put an upper
limit on packet aggregation that the eBDP folk are trying to resolve
more generically.

In practice, at "normal" 180Mbit rates, with the new queue depth of 3, I
get most of the benefits of packet aggregation without the lag.

I do see higher packet loss than I would like, at present.

- Sedat -

-- 
Dave Taht
http://nex-6.taht.net
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

For wireless routers and cable home gateways especially, this research
shows that the total un-managed buffers in your system should be less
than 32.

Would it be a good thing to start describing these queues not so much in
terms of packets but in terms of delay (or bandwidth X delay)?

Constants tend to live longer than they should, no matter how noble in
birth.

rick jones

On Thu, Mar 03, 2011 at 10:16:08AM -0800, Rick Jones wrote:

quoted

For wireless routers and cable home gateways especially, this research
shows that the total un-managed buffers in your system should be less
than 32.

Would it be a good thing to start describing these queues not so much in
terms of packets but in terms of delay (or bandwidth X delay)?

Constants tend to live longer than they should, no matter how noble in
birth.

Yes, it probably would -- that would be more meaningful between
different technologies and/or for technologies that might have variable
latencies due to shared media or whatnot.

Now, the question becomes what patches to propose to make that
happen... :-)

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

On 03/03/2011 12:16 PM, Rick Jones wrote:

quoted

For wireless routers and cable home gateways especially, this research
shows that the total un-managed buffers in your system should be less
than 32.

Would it be a good thing to start describing these queues not so much in
terms of packets but in terms of delay (or bandwidth X delay)?

The unit of bandwidth is something like Mbps, that of delay can be 
second, so bandwidth X delay --> Mb, which is the unit of packet size. 
So both packets and delay should have the same effect for sizing buffers.

Tianji

Constants tend to live longer than they should, no matter how noble in
birth.

rick jones

_______________________________________________
Bloat-devel mailing list
Bloat-devel-JXvr2/1DY2fm6VMwtOF2vx4hnT+Y9+D1@public.gmane.org
https://lists.bufferbloat.net/listinfo/bloat-devel

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Thu, 2011-03-03 at 13:45 -0600, Tianji Li wrote:

On 03/03/2011 12:16 PM, Rick Jones wrote:

quoted

quoted

For wireless routers and cable home gateways especially, this research
shows that the total un-managed buffers in your system should be less
than 32.

Would it be a good thing to start describing these queues not so much in
terms of packets but in terms of delay (or bandwidth X delay)?

The unit of bandwidth is something like Mbps, that of delay can be 
second, so bandwidth X delay --> Mb, which is the unit of packet size. 
So both packets and delay should have the same effect for sizing buffers.

Yet, not all packets are not created equal - in size.  So, 42, 150 byte
packets queued is not the same as 42, 1500 byte packets.  However, 10,
1500 byte packets is the same as 100, 150 byte packets.

Had you said something like MB and delay should have the same effect I
would have agreed with you :)

rick jones

On Thu 2011-03-03 13:45:24, Tianji Li wrote:

On 03/03/2011 12:16 PM, Rick Jones wrote:

quoted

quoted

For wireless routers and cable home gateways especially, this research
shows that the total un-managed buffers in your system should be less
than 32.

Would it be a good thing to start describing these queues not so much in
terms of packets but in terms of delay (or bandwidth X delay)?

The unit of bandwidth is something like Mbps, that of delay can be
second, so bandwidth X delay --> Mb, which is the unit of packet
size. So both packets and delay should have the same effect for
sizing buffers.

Bandwidth varies greatly with time. On cellphone, you can go from
5KB/sec GPRS to 300KB/sec HSDPA and back...
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

On Tue, 2011-03-08 at 07:58 +0100, Pavel Machek wrote:

Bandwidth varies greatly with time. On cellphone, you can go from
5KB/sec GPRS to 300KB/sec HSDPA and back...

How quickly/often and does that trigger an event in the host that would
allow adjustment of the queue?

rick jones

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi!

quoted

Bandwidth varies greatly with time. On cellphone, you can go from
5KB/sec GPRS to 300KB/sec HSDPA and back...

How quickly/often and does that trigger an event in the host that would
allow adjustment of the queue?

I'd expect it to get fast when you leave the building, and back to
slow when you re-enter. It all depends how good 3G coverage is, but
seeing it change more than once a minute is not that uncommon.

Event... not sure. Linux can ask for current signal strength, and I
assume connection type works in similar way...
								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html