Re: [zd1211-devs] Copy seems to be working, speed is the next issue
On 07-01-04 20:04 Jon Smirl wrote: 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. Unless we start to reengineer the Windows driver, there is nothing we can do about this. It might even be that the Windows driver is using a different firmware. As Daniel proposed it is worthwhile to check against the Linux vendor driver. If our driver has a lower performance, than there is something we can do about it. 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. I have trouble to follow the logic here. There are several retransmissions until the device gets the ACK. There is nothing which guarantees, that the second transmission must succeed. 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. Please recognize that the fact that you see the ACK elsewhere, doesn't mean, that the packet can be seen at another point. There are interferences. The other fact is that the ZD1211 devices are cheap devices, the RF transceivers have low quality. 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. This is the way the 802.11 standard has been designed. As far as I know there is discussion about doing a single ACK for several packets in 802.11n. There are some vendor based optimizations to merge several packets into a single packet and so on, but they are not interoperable. Kind regards, Ulrich -- Uli Kunitz - 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.phpp=sourceforgeCID=DEVDEV ___ Zd1211-devs mailing list - http://zd1211.ath.cx/ Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs
Re: [zd1211-devs] Copy seems to be working, speed is the next issue
On 1/5/07, Ulrich Kunitz [EMAIL PROTECTED] wrote: 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. I have trouble to follow the logic here. There are several retransmissions until the device gets the ACK. There is nothing which guarantees, that the second transmission must succeed. Noise is somewhat random, so it should result in differing numbers of retransmission attempts. If there is always the same number of retransmission attempts, it is more likely a bug. -- 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.phpp=sourceforgeCID=DEVDEV ___ Zd1211-devs mailing list - http://zd1211.ath.cx/ Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs
Re: [zd1211-devs] Copy seems to be working, speed is the next issue
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.phpp=sourceforgeCID=DEVDEV ___ Zd1211-devs mailing list - http://zd1211.ath.cx/ Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs
