[Olsr-users] Fwd: Question about hidden node behavior

[Teco Boot]

802.11e provides QoS support for apps that cannot tolerate jitter. This
works nice for for example a scenario where nodes A and C has a bulk flow,
that has negative influence on real time flow between B and D, on same channel.
Packet scheduling at higher layers cannot provide such class of QoS function,
as IP packet dispatching acts at a single node only and does not "channel 
wide packet scheduling".

I agree 802.11e queues should not be that deep, few frames are OK. CPU
is fast enough to provide next frame, without loss of unused time on channel.

As a 802.11e driver has multiple queues, each queue should have its own 
backpressure to the higher layer packet dispatcher. Not sure if such a
mechanism is available yet.

Thanks, Teco

Op 18 jan 2011, om 10:47 heeft Markus Kittenberger het volgende geschreven:

> hmm we do not really need 802.11e support, but sure it`s nice to have this aswell
> 
> if madwifi would just report its qeues as full to the kernel, it would do,..
> 
> (and imho this should imho be a standard behaviour for any interface driver,..)
> 
> Markus
> 
> On Tue, Jan 18, 2011 at 7:12 AM, Teco Boot <(spam-protected)> wrote:
> Jumping in a bit late.
> Madwifi is 802.11e capable. It needs a patch for support in ad hoc mode (ticket #1871).
> Then, marked priority packets can take media access priority.
> DSCP to 11e mapping needs code adjustments and recompile.
> 
> Does anyone use this for OLSR packets? Give it a try?
> I am aware of tests with test-flows only.
> 
> Thanks, Teco
> 
> 
> Op 15 jan 2011, om 17:22 heeft Markus Kittenberger het volgende geschreven:
> 
>> 
>> 
>> On Sat, Jan 15, 2011 at 4:06 PM, Juliusz Chroboczek <(spam-protected)> wrote:
>> 
>> i just retestet with newer versions ath9k (openwrt trunk),.. (as unfortunately last time i used a "release", and not trunk )-;)
>> 
>> and now ath9k did as well as ath5k!
>> 
>> so we "just" need to get rid of madwifi in our meshes, and QoS would be as "easy" again as it used to be on WRT54GL & co *G
>> 
>> > q1  q2  q3 driver
>> > 4.0 0.0 0.0 b43-legacy
>> > 4.0 0.0 0.0 ath5k (pci)
>>  > 2.5 1.5 0.0 ath9k (pci) old )-;
>> 4.0 0.0 0.0 ath9k newer 
>> > 1.3 1.3 1.3 madwifi (ahb)
>> 
>> Interesting.  What are the packet drop figures (ifconfig)?
>> i "never" saw ifconfig stating any dropped packets (at least on any openwrt router)
>> 
>> but tc- s qdisc reports the drops,..
>> 
>> here the results for ath9k and ath5k
>> 
>> input:
>> 100k packets in each of 3 udp-streams (via eth1)
>> 
>> wlan0 IEEE 802.11abgn ESSID:"test" 
>> Mode:Ad-Hoc Frequency:2.412 GHz Cell: 12:34:56:78:90:AB 
>> Tx-Power=3 dBm 
>> RTS thr:off Fragment thr:off
>> Encryption key:off
>> Power Management:off
>> 
>> wlan0 Link encap:Ethernet HWaddr 00:0C:42:61:05:21 
>> inet addr:192.168.2.2 Bcast:192.168.2.255 Mask:255.255.255.0
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:18 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:67135 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:1000 
>> RX bytes:756 (756.0 B) TX bytes:101346300 (96.6 MiB)
>> 
>> qdisc prio 1: dev wlan0 root refcnt 5 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
>> Sent 100161070 bytes 67135 pkt (dropped 227096, overlimits 0 requeues 32671) 
>> rate 0bit 0pps backlog 0b 0p requeues 32671 
>> qdisc sfq 10: dev wlan0 parent 1:1 limit 127p quantum 1514b perturb 10sec 
>> Sent 98195980 bytes 65815 pkt (dropped 32261, overlimits 0 requeues 0) 
>> rate 0bit 0pps backlog 0b 0p requeues 0 
>> qdisc sfq 20: dev wlan0 parent 1:2 limit 127p quantum 1514b perturb 10sec 
>> Sent 1160902 bytes 781 pkt (dropped 97310, overlimits 0 requeues 0) 
>> rate 0bit 0pps backlog 0b 0p requeues 0 
>> qdisc sfq 30: dev wlan0 parent 1:3 limit 127p quantum 1514b perturb 10sec 
>> Sent 804188 bytes 539 pkt (dropped 97525, overlimits 0 requeues 0) 
>> rate 0bit 0pps backlog 0b 0p requeues 0 
>> 
>> ath5k
>> 
>> wlan0 IEEE 802.11abg ESSID:"test" 
>> Mode:Ad-Hoc Frequency:2.412 GHz Cell: 12:34:56:78:90:AB 
>> Tx-Power=3 dBm 
>> RTS thr:off Fragment thr:off
>> Encryption key:off
>> Power Management:off
>> 
>> wlan0 Link encap:Ethernet HWaddr 00:0C:42:2B:A4:E9 
>> inet addr:192.168.2.2 Bcast:192.168.2.255 Mask:255.255.255.0
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:21 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:73147 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:1000 
>> RX bytes:882 (882.0 B) TX bytes:110421520 (105.3 MiB)
>> 
>> qdisc prio 1: dev wlan0 root refcnt 5 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
>> Sent 109133874 bytes 73147 pkt (dropped 223235, overlimits 0 requeues 2674) 
>> rate 0bit 0pps backlog 0b 0p requeues 2674 
>> qdisc sfq 10: dev wlan0 parent 1:1 limit 127p quantum 1514b perturb 10sec 
>> Sent 107133060 bytes 71805 pkt (dropped 26982, overlimits 0 requeues 0) 
>> rate 0bit 0pps backlog 0b 0p requeues 0 
>> qdisc sfq 20: dev wlan0 parent 1:2 limit 127p quantum 1514b perturb 10sec 
>> Sent 1450266 bytes 973 pkt (dropped 97834, overlimits 0 requeues 0) 
>> rate 0bit 0pps backlog 0b 0p requeues 0 
>> qdisc sfq 30: dev wlan0 parent 1:3 limit 127p quantum 1514b perturb 10sec 
>> Sent 550548 bytes 369 pkt (dropped 98419, overlimits 0 requeues 0) 
>> rate 0bit 0pps backlog 0b 0p requeues 0 
>> 
>> the reason why queue 20: and 30: manage to send more than 0pkt, ist that my streams start/end not exactly simultaneously, and even if they would the first 128 pkt aren`t dropped at the beginning,..
>> 
>> Markus
>> 
>> p.s. i seem to have ~ 2% packetloss on my ethernet interface *G
>>  
>> 
>>                                        Juliusz
>> 
>> -- 
>> Olsr-users mailing list
>> (spam-protected)
>> http://lists.olsr.org/mailman/listinfo/olsr-users
> 
>