Thread: [Madwifi-devel] Questions about MAC Ack Timeout
Status: Beta
Brought to you by:
otaku
From: dead c. <dz...@fo...> - 2009-05-28 04:34:51
|
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:2b: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:2b: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:2b: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 |
From: Derek S. <de...@in...> - 2009-05-28 09:59:20
|
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/ |
From: dead c. <dz...@fo...> - 2009-05-28 14:53:08
|
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/ |
From: Candy Y. <ca...@cs...> - 2009-05-28 17:21:06
|
I don't know if this is related to your issue. I saw similar behavior in my setup. All hardware are the same with different distance. I experience huge packet loss and lots of retransmission. After one month later, I found out that the card I use is highly unreliable. I had 7 linksys card with same laptop hardware. But they perform very differently. After I bought 4 new cards from Netgear. The packet loss is very stable among all cards. -Candy On Thu, May 28, 2009 at 7:44 AM, dead cow <dz...@fo...> 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/ > > > ------------------------------------------------------------------------------ > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity professionals. > Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp as they present alongside digital heavyweights like Barbarian > Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com > _______________________________________________ > Madwifi-devel mailing list > Mad...@li... > https://lists.sourceforge.net/lists/listinfo/madwifi-devel > > -- Candy YIU student, Computer Science Portland State University http://web.pdx.edu/~candy |
From: Derek S. <de...@in...> - 2009-05-28 23:01:26
|
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" |
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" |