[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1299084644.2920.24.camel@edumazet-laptop>
Date: Wed, 02 Mar 2011 17:50:44 +0100
From: Eric Dumazet <eric.dumazet@...il.com>
To: Mikael Abrahamsson <swmike@....pp.se>
Cc: Stephen Hemminger <shemminger@...tta.com>,
John Heffner <johnwheffner@...il.com>,
Bill Sommerfeld <wsommerfeld@...gle.com>,
Hagen Paul Pfeifer <hagen@...u.net>,
Albert Cahalan <acahalan@...il.com>,
Jussi Kivilinna <jussi.kivilinna@...et.fi>,
linux-kernel <linux-kernel@...r.kernel.org>,
netdev@...r.kernel.org
Subject: Re: txqueuelen has wrong units; should be time
Le mercredi 02 mars 2011 à 17:41 +0100, Mikael Abrahamsson a écrit :
> On Tue, 1 Mar 2011, Stephen Hemminger wrote:
>
> > Also WRED is not default on faster links because it can't be done fast
> > enough.
>
> Before this propagates as some kind of truth. Cisco modern core routers
> have no problems doing WRED at wirespeed, the above statement is not true.
>
looking at cisco docs you provided
( <http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/12stbwr.html>
)
, it seems the WRED time limits (instead of bytes/packets limits) are
internaly converted to bytes/packets limits
quote :
When the queue limit threshold is specified in milliseconds, the number
of milliseconds is internally converted to bytes using the bandwidth
available for the class.
So it seems its only a facility provided, and queues are still managed
with bytes/packets limits...
WRED is able to prob drop a packet when this packet is enqueued. At time
of enqueue, we dont know yet the time of dequeue, unless bandwidth is
known.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists