On 1/4/07, Daniel Drake <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
> > I just did a 15GB copy test and averaged 13Mb/sec, Windows can copy
> > the same files at 19Mb/sec. It appears that CIFS has higher throughput
> > than SMBFS (10Mb).
>
> I think using such a high level protocol for speed tests is a mistake
> and has certainly wasted some of your time so far. You should try
> low-level TCP transfers using netcat or something. I have personally had
> trouble making cifs/samba perform at something comparable to the
> available network bandwidth.

Yes I got burnt on the SMB copy. I never suspected that the code in
the shipping kernel wouldn't have worked after all these years. But it
must be degrading because of CIFS taking over for it and no one is
maintaining it. I wasn't aware that it wasn't being maintained.

I don't care about really getting 20Mb+ performance out of the link,
I'm just using performance as another way of looking for bugs.

I'll have to rearrange my hardware to do netcat type of testing. Is
there any way to get two zd1211rw devices talking to each other?

> You should also now retest the vendor driver and see if you can
> reproduce the vendor-driver-is-2x-faster thing.

Linux version of the vendor driver is running about the same speed as
zd1211rw. It it the Windows version of the vendor driver that is
faster for the copies. About 50% right now.

> You also need to explicitly test downstream and upstream separately, and
> classify the problems by direction.
>
> > I have 1000's of these in my log. 10-15 per second
> > handle_retry_failed_int() retry failed interrupt
>
> These are generated for frame transmission failures (read: no ACK). You
> get several of them for each frame as they are retried multiple times
> before it gives up.

I got 89,330 of these over the 2.5hr copy. There were about 10M
outbound packets so that implies a packet transmission failure rate of
1% (or received ack failure). 89K seems like a lot given that I only
got one CRC error in 15GB.

I'll try adding some more hints to the debug output. I wouldn't expect
to retransmit enough times to cause a frame transmission error. If it
is noise there would normally be only a single retransmission.
Multiple retransmissions and then frame transmit failure implies a bug
somewhere.

When I was using kismet the traces looked more to me like the ACK was
being transmitted by the AP and the zd1211rw wasn't listening.

BTW per packet low level synchronous ACKs is a terrible design for a
MAC layer. I don't see that they needed any acks at all. UDP is
unreliable and TCP will recover. TCP also piggybacks acks on return
traffic which is much more efficient. Those acks waste a huge chunk of
bandwidth.

> > I also have a few of these, once every minute
> > [21901.205436] zd1211rw 5-1.4:1.0: zd_usb_ioread16v() read timed out
> > [21901.205442] zd1211rw 5-1.4:1.0: zd_chip_control_leds error -110
>
> You could try disabling the LED code and seeing if that has an effect on
> performance.

That might be worthwhile, doesn't that pending read block the whole
USB channel while it is timing out?

> CRC failed, ignore it, frame was discarded.

Only got one of those in 15GB.

-- 
Jon Smirl
[EMAIL PROTECTED]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Zd1211-devs mailing list - http://zd1211.ath.cx/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs

Reply via email to