Re: [Madwifi-devel] Questions about MAC Ack Timeout
Status: Beta
Brought to you by:
otaku
Menu
▾
▴
Re: [Madwifi-devel] Questions about MAC Ack Timeout
|
From: dead c. <dz...@fo...> - 2009-05-29 03:12:24
|
Hi, all
Many thanks to Derek and Candy :)
It seems that we should adjust slottime/acktimeout/ctstimeout by hand and separately.
So, at the next experiment, we will set slottime/acktimeout as follows:(802.11b)
slottime = default slottime + ( distance - 300 ) / 300
acktimeout = 2 * slottime + an extra bit for safety
or
acktimeout = default acktimeout + (distance - 300)/300
so, for 3.83 km, slottime is 32, acktimeout is 2*32+3 = 67 or acktimeout = 48 + 12 = 60
I will try it at the next experiment and show my experiment results here.
>>> Derek says:
Hi,
you have measured exactly what I described in my letter.
At a distance of 3.49km, retry rate is 0.37 (link C-D)
At a distance of 3.83km, retry rate is 6.9 (link A-B).
you have a huge increase in the loss rate for a very small increase in
distance.
This is clearly an acktime/slottime/ctstimeout issue.
On the codebase here, I modified the code handling the slottime and
acktimeout and ctstimeout proc files. In my codebase, I took the supplied
number from the file and put it into the hal. Nothing more. So if the file
was for acktimeout, and a new number was put into acktimeout, then my code
just modified the acktimeout.
If the file was for ctstimeout, and a new number was put into ctstimeout,
then my code just modified the ctstimeout.
--and so on.
This way, when I knew I had the right values, I knew the hal was using the
values I gave it..
> 1) ACK Timeout = Air Propagation Time (max) + SIFS + Time to transmit 14 byte ACK frame [14 * 8 / bitrate in Mbps] + Air Propagation Time (max)
> 2) Slottime = MAC and PHY delays + Air Propagation Time (max)
> if 1) holds, then ack timeout which is 48 us by default for 802.11b is not correct? what's the problem? Am I wrong?
> I refer to the madwifi code r4026, the function: ath_slottime2timeout says that ack timeout = aSIFSTime + aSlotTime, why? How to explain it if 1) hold?
yes. In words, the ack timeout is the time that the sender is prepared to
wait for an 802.11 ack packet from the recipient.
The units of the variable ack timeout is in microseconds.
In earlier versions of the madwifi code,
the slottime is:: the air propogation time plus a bit for safety
the variables acktimeout and ctstimeout are set to the same value,
which is:: twice the slottime plus an extra bit for safety.
your conclusion about r4026 is clearly correct - the code is wrong.
Derek.
On Thu, 28 May 2009, dead cow wrote:
> Hi, Derek
> I'm glad to read your reply. But, still I have some details to explain.
> In fact, we have two links in our outdoor experiment: link C->D is at
> the suburban district, with line of sight. And there is no tall
> buildings blocking the line of sight. The distance is 3.49 km (We
> measured the distance from the google earth). Both link C->D and link
> A->B have the same software/hardware.
>
> From the experiment data, we found that link C->D has no such serious
> MAC retransmission compared with link A->B. Actually, This link suffers
> MAC retransmission less than 7 times, and most of frames didn't suffer
> frame retransmission. The mean retry value per frame is 0.37 (total
> frames: 54220, total retry times:20139).
>
> As for link A->B, We conduct our experiment for two days. At the first
> day, the link A->B is 3.83 km, and we got the mean retry value per frame
> of 6.90 (total frames: 5466, total retry times: 37700). At the second
> day, we move the receiver B to a further place, so the distance of link
> A->B is 4.76 km and we conducted the same experiment as above mentioned.
> The result is that we got a much higher retry value per frame: 6.93
> (total frames: 3982, total retry times: 27610).
>
> So, does the assumption of ack timeout hold? If it holds, the conclusion is that when the distance changed from 3.49 km to 3.83 km, it can lead to a serious performance degradation due to mass ack timeout?
>
> afaik,
> 1) ACK Timeout = Air Propagation Time (max) + SIFS + Time to transmit 14 byte ACK frame [14 * 8 / bitrate in Mbps] + Air Propagation Time (max)
> 2) Slottime = MAC and PHY delays + Air Propagation Time (max)
> if 1) holds, then ack timeout which is 48 us by default for 802.11b is not correct? what's the problem? Am I wrong?
> I refer to the madwifi code r4026, the function: ath_slottime2timeout says that ack timeout = aSIFSTime + aSlotTime, why? How to explain it if 1) hold?
>
>
>>>>> as Derek says:
>
> Hi,
> Slottime is the length of time light will take to travel the distance
> between your two nodes plus a bit for processing.
> Acktimeout is twice the slottime plus a bit for processing.
> From memory, for, 5km, it is 26, 55 and 55.
> Your numbers are "about right".
> You can easily see if it is slottime/acktimeout issues.
> Set your slottime etc to the values for your desired distance (your case,
> 3.8 km.)
> Set up your two nodes at a distnace of 2km.
> iperf etc, and measure the loss percentage.
> Increase the distance to 2.5km
> iperf etc, and measure the loss percentage.
> Increas the distance some more and do your iperf again.
> If you plot the loss percentage as a function of distance, you will see a
> point where there is Huge huge change in the loss percentage. The loss
> percentage will change from a couple of percent to 50-90%
> When you get that huge change, it is slot time.
> Changing your packet size will alter the required acktimeout required.
> I have seen links where small packets (100 bytes) go through fine (minimal
> loss). But the large packets (1400 bytes) had 90% loss rates. Slot&ack
> timeouts..
> Good luck, and keep testing.
> Derek.
> On Thu, 28 May 2009, dead cow wrote:
>> Hi guys：
>> We have conducted several outdoor long-distance WiFi experiments. On a wireless
>> link, to say, from A to B, We send UDP traffic with iperf. We add some output
>> messages upon receiving frames in Madwifi. From the driver log, We saw a lot of MAC
>> retransmission ( 6‾10 times randomly ) for almost each frame, but in fact, the frame
>> is correctly received by the receiver B. We think it may be due to the MAC Ack
>> timeout.
>>
>> The link from A to B is about 3.8 km, in the urban area, nearly line of sight, with
>> 24dBi directional antenna on each side.
>> We use ubiquitous XR2 mini pci card, with linux kernel 2.4.26 and madwifi 0.9.2.
>> Each side is in adhoc demo mode, 802.11b, channel 1, with autorate or fixed tx rate
>> at 1Mbps and 11Mbps.
>>
>> We also measured the RSSI in the receiver side, it's about 40‾55dB higher then the
>> noise floor. So we think the link quality is very strong ( It implies very low loss
>> rate and actually it really did ) and there is no reason for MAC layer to retransmit
>> frames except for MAC Ack timeout.
>>
>> We use default slottime value (20 us for 802.11b), acktimeout (48 us ), ctstimeout
>> value ( same as acktimeout )
>>
>> My question is was it really due to ack timeout? and why acktimeout is 48 us? How
>> does this value be calculated?
>>
>> Here is my driver log from the receiver B:
>> <14>Jan 1 00:01:27 kernel: 8 (is data packet) 0 (no retry, 8 represents mac
>> retry) 13228 (mac timestamp) 52 (RSSI) -98(noise floor) 22 (data rate) 31 (mac
>> sequence number) 0:15:6d:63:2b:35 (src mac addr) 0:15:6d:63:2b:26 (dest mac addr)
>> 0:0:0:0:0:0 (bssid)
>>
>>
>> <14>Jan 1 00:01:27 kernel: 8 0 13228 52 -98 22 31 0:15:6d:63:2b:35 0:15:6d:63
>> :2b:26 0:0:0:0:0:0
>> <14>Jan 1 00:01:27 kernel: 8 8 15090 52 -98 22 31 0:15:6d:63:2b:35 0:15:6d:63
>> :2b:26 0:0:0:0:0:0
>> <14>Jan 1 00:01:27 kernel: 8 8 25374 52 -98 2 31 0:15:6d:63:2b:35 0:15:6d:63:
>> 2b:26 0:0:0:0:0:0
>> <14>Jan 1 00:01:27 kernel: 8 8 1940 53 -98 2 31 0:15:6d:63:2b:35 0:15:6d:63:2
>> b:26 0:0:0:0:0:0
>> <14>Jan 1 00:01:27 kernel: 8 8 13822 53 -98 2 31 0:15:6d:63:2b:35 0:15:6d:63:
>> 2b:26 0:0:0:0:0:0
>> <14>Jan 1 00:01:27 kernel: 8 8 22960 53 -98 2 31 0:15:6d:63:2b:35 0:15:6d:63:
>> 2b:26 0:0:0:0:0:0
>> <14>Jan 1 00:01:27 kernel: 8 8 32236 52 -98 2 31 0:15:6d:63:2b:35 0:15:6d:63:
>> 2b:26 0:0:0:0:0:0
>> <14>Jan 1 00:01:27 kernel: 8 8 10412 50 -98 2 31 0:15:6d:63:2b:35 0:15:6d:63:
>> 2b:26 0:0:0:0:0:0
>> <14>Jan 1 00:01:27 kernel: 8 0 12062 50 -98 22 32 0:15:6d:63:2b:35 0:15:6d:63
>> :2b:26 0:0:0:0:0:0
>> <14>Jan 1 00:01:27 kernel: 8 8 13762 53 -98 22 32 0:15:6d:63:2b:35 0:15:6d:63
>> :2b:26 0:0:0:0:0:0
>> <14>Jan 1 00:01:27 kernel: 8 8 22920 51 -98 2 32 0:15:6d:63:2b:35 0:15:6d:63:
>> 2b:26 0:0:0:0:0:0
>> <14>Jan 1 00:01:27 kernel: 8 8 2878 53 -98 2 32 0:15:6d:63:2b:35 0:15:6d:63:2
>> b:26 0:0:0:0:0:0
>> <14>Jan 1 00:01:27 kernel: 8 8 12110 52 -98 2 32 0:15:6d:63:2b:35 0:15:6d:63:
>> 2b:26 0:0:0:0:0:0
>> <14>Jan 1 00:01:27 kernel: 8 8 23684 51 -98 2 32 0:15:6d:63:2b:35 0:15:6d:63:
>> 2b:26 0:0:0:0:0:0
>> <14>Jan 1 00:01:27 kernel: 8 8 1808 51 -98 2 32 0:15:6d:63:2b:35 0:15:6d:63:2
>> b:26 0:0:0:0:0:0
>> <14>Jan 1 00:01:27 kernel: 8 8 11006 53 -98 2 32 0:15:6d:63:2b:35 0:15:6d:63:
>> 2b:26 0:0:0:0:0:0
>>
>> from the log, we can see that the frame which mac sequence number is 31 has a retry
>> times of 7.
>> Is that really due to ack timeout? However, the link AB is not too long, we haven't
>> expected the ack timeout in such links.
>>
>> Can anyone shed light on my questions?
>> Thanks‾
>>
>> dzbjet
>>
>>
>>
> --
> Derek Smithies Ph.D.
> IndraNet Technologies Ltd.
> Email: de...@in...
> ph +64 3 365 6485
> Web: http://www.indranet-technologies.com/
>
--
Derek Smithies Ph.D.
IndraNet Technologies Ltd.
ph +64 3 365 6485
Web: http://www.indranet-technologies.com/
"The only thing IE should be used for is to download Fire Fox"
|