﻿
Hi, Derek
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.
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.
>
> 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
> 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: derek@indranet.co.nz
ph +64 3 365 6485
Web: http://www.indranet-technologies.com/