Hello,

Our customer has installed 10 Mikrotik AP's in 802.11a but more and more clients have been using Linux + madwifi-ng as a client system.
What's interesting - the basic complaints are regarding asymmetrical download/upload transfer rate (frankly, I couldn't believe that) !
For example: download is usually good (~10-12Mb) but upload is no more then ~4-5Mb on distances over 3-6km (full LOS).
I have tried to upgrade/install 2.9.17 and 2.9.18 on Mktk AP's but the problem is still the same.
I have also done testing on the 802.11b/g modes and did testing on small distances ... problem is as same as the previous one on 802.11a.

Any help or suggestion would be of a great value.

Thanks,
D.

Have the users tried adjusting ack timeout using 'athctrl -d [distance in meters]' yet?

If adjusting it doesn't help, get them to monitor athstats (athstats 1), and paste a few minutes worth of results to pastebin. Also have them try madwifi-old and see if they have similar issues.

Yes, they have all those parameters configured ... ack, slottime.
They have also tried to better adjust parameteres like ... sens, frag, rts etc. but without positive results.

in the production environment they have Mkt AP's connected to Mktk routers.
It seems that everything was normal on Mktk versions 2.9.7/2.9.8 (leveled on the routers and AP's).
Problems started after upgrading Mktk (both of them - routers and AP's) first to 2.9.14 and after that to 2.9.17.

I have captured athstats wifi0 and this is the result:

7 beacon miss interrupts
5175 tx management frames
22 tx failed due to too many retries
2 short on-chip tx retries
5269 long on-chip tx retries
4752 tx frames with no ack marked
87 tx frames with rts enabled
165741 tx frames with short preamble
327 tx frames with an alternate rate
64032 rx failed due to bad CRC
885 PHY errors
885 CCK restart
46642 periodic calibrations
rssi of last ack: 48
rssi of last rcv: 45

why so many bad CRC's ?