Is NV2 AP giving client “A” 2 times more time to communicate with AP then client “B” if “A” has two times as much data to transport? Or is time devision equal between clients regardless of how much data both would like to send/recieve?
I have this scenario:
1 AP running NV2 with two connected clients. Both clients have approx. -60 signals and connection and 90+ CCQ al the time. Connetion rates set at 48Mbps. Distance of clients is 6 and 7 km respectively.
Both clients have second radio working as AP-bridge.
Client “A” has 4 clients with mild usage.
Client “B” has 8 clients and amongst it two regular heavy users.
(Clients are rb433 and AP is rb333, all running ros 4.16 with NV2 wireless package.)
Would NV2 work in this scenario (´equal´ time sharing of each AP client radio’s) or would rts/cts be a better methode here since now the amount of data to be transported also relates to the amount of time client wants (RTS) from AP and gets (CTS)?
Clients can’t ´see´ eachother. Even their AP radio’s don’t see any signals of the other unit’s radio’s.
2 clients little usage, 1 client heavy (in time and bandwith)
RTC/CTS devides medium access upon 802.11 which basicall means heavy users gets most of the access time. (´He “screams” most and is thus heared most and also satisfied most.´ Just like real live…)
NV2 devides medium access in TDMA which my understanding is “equall time slots for each CPE”? This would mean little usage client have better medium access then in RTS/CTS situation, but ´heavy user´ has little lower perfomance when other two want to communicate.
Is this scenario true?
Can the NV2 scenaro tuned more in favour of ´heavy user? Maybe in using the NV2 QoS options?
As of now nv2 AP transmits data to clients such that approximately equal
amount of bytes is sent to each client, provided that there is enough data
queued for clients. For receive, nv2 AP assigns time for clients to transmit
in approximately equal amounts, provided that clients have data queued, but
not more that necessary for client to transmit all of its queued data.
RTS/CTS procedure in 802.11 is executed on per-packet basis and has nothing to
do with amount of data queued in device - by sending RTS client does not
report amount of data it wants to send - it informs on size of next packet it
wants to send, AP on turn, does not grant client some time by sending CTS -
it simply informs on how long everybody should be silent in order to not
disturb requester in sending its frame and this time is taken from RTS. With
RTS/CTS the same DCF medium access procedure is executed and the end result
with respect to medium distribution will be approximately the same as w/o
RTS/CTS, because probability of medium access is the same. For details on how
RTS/CTS works please refer to 802.11.
we stopped using RTS/CTS as we had strange effects on some sectors.
One CPE succeeded to disturb whole Sector. Even with low usage.
Disabling RTS/CTS on this CPE cleared things.
Theory of RTS/CTS helps but in practice we did not succeed.
I would try nstreme/nv2 in your situation. Use Protocol=any on your
clients so you can compare it without hassle. I’ve seen nstreme
performing still better in most situations.
Dont forget to look at queueing. I played some time with wireless
protocols on an installation until I found that changing from sfq to pcq
on the wireless interface of the AP was the biggest gain.
OK. Ok, heavy download client gets its data send by AP and at the moment little usage client wants some data he gets is in equal amounts as heavy users (until little user’s data is starved, then heayve gets all again..)
For receive, nv2 AP assigns time for clients to transmit
in approximately equal amounts, provided that clients have data queued, but
not more that necessary for client to transmit all of its queued data.
“not more that (=than?) necessary”??? How does AP knows how much data clients wants to send?
RTS/CTS procedure in 802.11 is executed on per-packet basis and has nothing to
do with amount of data queued in device - by sending RTS client does not
report amount of data it wants to send - it informs on size of next packet it
wants to send, AP on turn, does not grant client some time by sending CTS -
it simply informs on how long everybody should be silent in order to not
disturb requester in sending its frame and this time is taken from RTS. With
RTS/CTS the same DCF medium access procedure is executed and the end result
with respect to medium distribution will be approximately the same as w/o
RTS/CTS, because probability of medium access is the same. For details on how
RTS/CTS works please refer to 802.11.
Are you sure this was really a RTS/CTS issue? I studied quit a bit in RTS/CTS and it is a reasonably good protocol and I have it implemented in all my 12 AP’s all working in ´busy´ air spectrum and all with plenty of hidden nodes. Withou RTX/CTS network performance was poor.
I would try nstreme/nv2 in your situation. Use Protocol=any on your
clients so you can compare it without hassle. I’ve seen nstreme
performing still better in most situations.
Never liked nstreme too much. Client AP protocol=any… hmm, I use “Nv2-nstreme-802.11”. I don’t see so much difference in both for client radio. Both scan although it might be the latter scans in specific order where NV2 comes first while “any” would be ´random´ and might at times take more time to find suitable protocol network.
After good reading this section of manual I might also try to set clients to “NV2” to avoid the scanning delay after a disconnect.
Dont forget to look at queueing. I played some time with wireless
protocols on an installation until I found that changing from sfq to pcq
on the wireless interface of the AP was the biggest gain.
Stefan
Ok, this can be interesting… but what do you exactly mean? On both my main AP as both clients I have a Queue tree set on the wirless interface to limit and priorize the traffic going over links to other side. These Queue trees use pcq. But can it be sfq is still used on interface at some other level?
Can you give more info on this.
Yes. Disabling/Enabling on the offending CPE solved things. I dont believe RTS/CTS
itself is the problem. I think it has to be implemented correct on all involved devices …
Scanning is quite fast. I like to be flexible until NV2 matures.
If you use Queue tree and PCQ you should be save. I’ve found bad interaction
with PCQ and wireless accesslists. So we use bfifo and accesslist limits at the moment.
OK, I misunderstood. I do use the access list, but only to grant access for certain mac.addresses.
No limits here. All my limitation of the clients is done at my main border gateway. The benefit is that for management purposes I have all the bandwidth of the network available but clients only get their assigned limits to go online.