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
