From: Bjørn Mork (bjorn_at_mork.no)
Date: 2002-04-09 13:23:12 UTC
Jouni Malinen <jkmaline_at_cc.hut.fi> writes:
> On Sun, Apr 07, 2002 at 07:01:21PM +0200, Bjørn Mork wrote:
>
>> This made me optimistic since I've had a small performance problem
>> with the latest releases (losing packets when transmitting many of
>> them, causing TX speed to drop and reducing TX performance to a
>> fraction of the theoretical). I'm using the driver on a 66 MHz 486
>> with a Vadem ISA-PCMCIA controller, so interrupt latency is probably
>> as high as it can get.
>
> I just tested the latest version on 486 DX/4 75 MHz laptop with Intel
> i82365sl B step rev 00 ISA-to-PCMCIA and D-Link DWL-650 and did not
> run into any problems.. Which Prism2 card are you using and which
> firmware version?
I am using ZyXEL ZyAIR 100 cards. This is an OEM version of the Z-Com XI300 (same manfid). Currently with firmware version 1.3.4, but I had the same experiences with version 0.8.0.
>> I guess the problem is that the platform is too slow handling the
>> packets, not really that they are lost in the air. Probably not much
>> that can be done about that. Your changelog made me a bit optimistic,
>> but I couldn't really notice any improvement. The TX performance is
>> still terrible (~500 kbits/s as opposed to the RX speed of ~5 Mbits/s).
>
> Is that ~500 kbps TCP or UDP traffic? If it was TCP, numerous reset
> attempts will certainly harm the performance.
It was TCP. UDP is another problem I haven't mentioned yet (thought I'd take it in small steps to avoid scaring you :-)
I can't get ttcp to do UDP speed tests in the hostap->client direction (the other way works fine). UDP tests are aborted after a few packets, and I get interesting messages like this in the log:
Apr 7 19:30:58 rasputin kernel: UDP: bad checksum. From 192.168.2.1:4555 to 192.168.2.16:5001 ulen 8200
I meant to look a bit more at it with ethereal, but haven't gotten around to it yet.
> I was able to about 6 Mbps TX (and RX) speeds (UDP; about 5 Mbps with
> TCP) with a bit faster CPU. This was both with busy waiting command
> completion and interrupt version. There were not much difference in
> transmit rate between the versions, but system load was considerably
> lower with interrupt version as expected.
>
> The driver did not log even a single dropped frame no matter what I
> did. I tried compiling with a lot of swapping (that laptop has only 8
> megs of RAM) on the background while flooding the net, but no problems
> what so ever with the traffic..
Great. That means that I should look somewhere else to locate my problems. I had a feeling of that.. I suspect the PCMCIA controller. I could never get prism2dl to finish downloading the tertiary firmware on this box either, without finding any reasonable explanation. It has worked on all the laptops I tried it on.
> I did not use bridging and the traffic went directly between the AP
> and the station. Did you use another NIC during the tests (i.e.,
> interrupts both from wireless and wired card)?
The box has two other NICs, both 3c509. There is no bridging, and the traffic over the other interfaces should be insignificant at the time of the test. But the 3c509 driver is not the nicest with regard to interrupt latency as far as I know, so this may be the problem after all?
Bjørn