Re: [ns] new 802.11 - CAP proportion too big
On Wed, 2006-09-06 at 01:02 +0100, Pedro Fortuna wrote:
if ((*tmp).second + m_parameters-getMSDULifetime () now) {
It's delay bounded, and its limited with the value returned by
function getMSDULifetime, which by default is 10 seconds, which is a
very large value for delay.
Do you have a better suggestion ?
I've looked at your Yans code and ported the relevant code to your NS2 branch.
If I may ask, why did you use a queue size limit of 400 packets?
Because this is the max queue size of the linux madwifi driver the last
time I worked on it.
What is the delay limit on queued packets you implemented on Yans?
10s
Mathieu
--
Re: [ns] new 802.11 - CAP proportion too big
I cannot remember if the queue is size-bound or delay-bound. My curent
code (in yans) is both size and delay bound with a default size of 400
packets. The relevant code is located in mac-queue-80211.cc.
Mathieu
if ((*tmp).second + m_parameters-getMSDULifetime () now) {
It's delay bounded, and its limited with the value returned by
function getMSDULifetime, which by default is 10 seconds, which is a
very large value for delay.
I've looked at your Yans code and ported the relevant code to your NS2 branch.
If I may ask, why did you use a queue size limit of 400 packets?
What is the delay limit on queued packets you implemented on Yans?
Thanks.
Best Regards,
Pedro Fortuna
Re: [ns] new 802.11 - CAP proportion too big
On Mon, 2006-08-14 at 23:54 +0100, Pedro Fortuna wrote: I'll do my best trying to find the problem. I'll submit a patch if I succeed correcting it (assuming there's a problem). There is a question on the DCF implementation part I'd like to ask if you don't mind. It seems that there's no Packet Loss. I know 802.11 DCF MAC's is an acknowledged service with up to 7 retransmissions, which eliminates almost every packet loss due to transmission errors. But shouldn't it at least have some packet loss due to limited queue sizes? I have done a simulation where I create 200 nodes exchanging 400 voip flows and although the maximum delay is a lot higher when compared with a 20 or 50 node simulation, it still does not show any packet loss. This suggests that in your implementation you have a very long queue (or infinite size). Is this true? If so, In your opinion, would it be complicated to implement a limited queue size? I cannot remember if the queue is size-bound or delay-bound. My curent code (in yans) is both size and delay bound with a default size of 400 packets. The relevant code is located in mac-queue-80211.cc. Mathieu
[ns] new 802.11 - CAP proportion too big
Hello Mathieu, Sorry for bothering you again. I have a question which might have more to do with the 802.11e standard, but maybe you can enlighten me a bit. Im using your 802.11e implementation in NS2 to setup a scenario where a number of VoIP flows is exchanged between the QAP and a bunch of nodes. Each flow is configured with the exact same TSpec: # set TSpec set tspec [new TclTspec] $tspec set-minimum-service-interval 0.0 $tspec set-maximum-service-interval 0.0 # ms $tspec set-delay-bound 0.125 # bytes $tspec set-nominal-msdu-size 80 # bytes per second $tspec set-mean-data-rate 8000 $tspec set-peak-data-rate 8000 But when running the simulation, only the first flows are accepted (1 or 2 flows). The subsequent flows are refused due to CAP proportion being too big. I understand that during the CP, the QAP is able to provide TXOP to stations (CAPs), and that the overall number of CAPs shouln't not be over a certain value (0.4 i think). But why such a limited set of flows result in this error? When there aren't enough CAPs to offer, the flows should try to transmit them using regular EDCA contention rules I'm not getting this behavior :( Thank you. -- Best Regards, Pedro Fortuna INESC Porto
