[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1178800551.4074.34.camel@localhost>
Date: Thu, 10 May 2007 08:35:51 -0400
From: jamal <hadi@...erus.ca>
To: Zhu Yi <yi.zhu@...el.com>
Cc: "Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>,
Johannes Berg <johannes@...solutions.net>,
Stephen Hemminger <shemminger@...ux-foundation.org>,
Patrick McHardy <kaber@...sh.net>, netdev@...r.kernel.org,
jgarzik@...ox.com, cramerj <cramerj@...el.com>,
"Kok, Auke-jan H" <auke-jan.h.kok@...el.com>,
"Leech, Christopher" <christopher.leech@...el.com>,
davem@...emloft.net
Subject: RE: [PATCH] IPROUTE: Modify tc for new PRIO multiqueue behavior
On Thu, 2007-10-05 at 11:02 +0800, Zhu Yi wrote:
> The difference is the hub provides the same transmission chance for all
> the packets but in wireless, high priority packets will block low
> priority packets transmission. You can argue there is still chances a
> low priority packet is sent first before a high priority one. But this
> is not the point of wireless QoS. It rarely happens and should be avoid
> at best effort in the implementation.
So we may be agreeing then?
In other words, if you had both low prio and high prio in WMM scheduler
(in wireless hardware) then the station favors a higher priority packet
over at low priority packet at ALL times.
IOW:
Given the default 802.11e AIFS, CWmin/max and PF (and TXOP) parameters
used for the different WMM queues there is no way that a lower prio
packet will ever be allowed to leave when it is competing with a higher
prio packet.
This approach is what the strict prio qdisc already does. The slight
difference is the prio qdisc is deterministic and the WMM is statistical
(strict prio) in nature - i.e there is a statiscal "luck" possibility
(not design intent) for an lower prio packet to go out.
Does this make sense?
cheers,
jamal
-
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