Thread: [zd1211-devs] Working on the dscape driver
Status: Beta
Brought to you by:
mayne
From: Jon S. <jon...@gm...> - 2007-01-28 03:26:58
|
In order to learn more about how the zd1211 works I though I could try implementing a few missing functions in the dscape zd1211 driver. The easiest ones looked to be the statistics functions. get_stats needs this filled: struct ieee80211_low_level_stats { unsigned int dot11ACKFailureCount; unsigned int dot11RTSFailureCount; unsigned int dot11FCSErrorCount; unsigned int dot11RTSSuccessCount; }; get_tx_stats needs this filled, one per queue: struct ieee80211_tx_queue_stats_data { unsigned int len; /* num packets in queue */ unsigned int limit; /* queue len (soft) limit */ unsigned int count; /* total num frames sent */ }; I've been poking around in the vendor driver amd zd1211rw and don't see an obvious way to collect this data. For example I didn't see where RTS success/failure is tracked. I also haven't located the exact spot to separate FCS (CRC errors) from other classes of errors. -- Jon Smirl jon...@gm... |
From: Ulrich K. <ku...@de...> - 2007-01-28 08:02:42
|
On 07-01-27 22:26 Jon Smirl wrote: > In order to learn more about how the zd1211 works I though I could try > implementing a few missing functions in the dscape zd1211 driver. The > easiest ones looked to be the statistics functions. > > get_stats needs this filled: > > struct ieee80211_low_level_stats { > unsigned int dot11ACKFailureCount; > unsigned int dot11RTSFailureCount; > unsigned int dot11FCSErrorCount; > unsigned int dot11RTSSuccessCount; > } > > get_tx_stats needs this filled, one per queue: > > struct ieee80211_tx_queue_stats_data { > unsigned int len; /* num packets in queue */ > unsigned int limit; /* queue len (soft) limit */ > unsigned int count; /* total num frames sent */ > }; > > I've been poking around in the vendor driver amd zd1211rw and don't > see an obvious way to collect this data. For example I didn't see > where RTS success/failure is tracked. I also haven't located the exact > spot to separate FCS (CRC errors) from other classes of errors. We do/emulate ACK confirmation for packet tx in d80211, so it should be possible to estimate the error count. However it is not obvious to me, what the semantics is here. Are ACK failures for retransmissions also counted here? There is no simple way to count the RTS failures and successes. You could however get all the RTS packets and work from that. However I would regard this as waste of device-to-host bandwidth, which is shared of all USB devices on the same host adapter. FCS errors are in struct rx_status (ZD_RX_CRC32_ERROR) if ZD_RX_ERROR is set. Queue stats might be possible, if we start to understand how queuing does work for the ZD1211B. I guess that the high byte of packet length in zd_ctrlset is used for this. But we don't know how exactly. Notify there is no support for queuing in ZD1211 devices. -- Uli Kunitz |
From: Jon S. <jon...@gm...> - 2007-01-28 16:09:41
|
On 1/28/07, Ulrich Kunitz <ku...@de...> wrote: > On 07-01-27 22:26 Jon Smirl wrote: > > > In order to learn more about how the zd1211 works I though I could try > > implementing a few missing functions in the dscape zd1211 driver. The > > easiest ones looked to be the statistics functions. > > > > get_stats needs this filled: > > > > struct ieee80211_low_level_stats { > > unsigned int dot11ACKFailureCount; > > unsigned int dot11RTSFailureCount; > > unsigned int dot11FCSErrorCount; > > unsigned int dot11RTSSuccessCount; > > } > > > > get_tx_stats needs this filled, one per queue: > > > > struct ieee80211_tx_queue_stats_data { > > unsigned int len; /* num packets in queue */ > > unsigned int limit; /* queue len (soft) limit */ > > unsigned int count; /* total num frames sent */ > > }; > > > > I've been poking around in the vendor driver amd zd1211rw and don't > > see an obvious way to collect this data. For example I didn't see > > where RTS success/failure is tracked. I also haven't located the exact > > spot to separate FCS (CRC errors) from other classes of errors. > > We do/emulate ACK confirmation for packet tx in d80211, so it > should be possible to estimate the error count. However it is not > obvious to me, what the semantics is here. Are ACK failures for > retransmissions also counted here? I'll look around for more specific documentation. > There is no simple way to count the RTS failures and successes. You could > however get all the RTS packets and work from that. However I > would regard this as waste of device-to-host bandwidth, which is > shared of all USB devices on the same host adapter. I'll look in the dscape code and see what they do with these errors. > > FCS errors are in struct rx_status (ZD_RX_CRC32_ERROR) if ZD_RX_ERROR is set. > > Queue stats might be possible, if we start to understand how > queuing does work for the ZD1211B. I guess that the high byte of packet > length in zd_ctrlset is used for this. But we don't know how > exactly. Notify there is no support for queuing in ZD1211 devices. If I understand things, these stats are what is needed to do rate adaptation in the dscape stack. > > -- > Uli Kunitz > -- Jon Smirl jon...@gm... |
From: Jon S. <jon...@gm...> - 2007-01-28 17:52:11
|
On 1/28/07, Ulrich Kunitz <ku...@de...> wrote: > There is no simple way to count the RTS failures and successes. You could > however get all the RTS packets and work from that. However I > would regard this as waste of device-to-host bandwidth, which is > shared of all USB devices on the same host adapter. Couldn't this be tracked easily in the firmware? Is it possible to get firmware changes? -- Jon Smirl jon...@gm... |
From: Ulrich K. <ku...@de...> - 2007-01-28 18:31:55
|
On 07-01-28 12:52 Jon Smirl wrote: > On 1/28/07, Ulrich Kunitz <ku...@de...> wrote: > > There is no simple way to count the RTS failures and successes. You could > > however get all the RTS packets and work from that. However I > > would regard this as waste of device-to-host bandwidth, which is > > shared of all USB devices on the same host adapter. > > Couldn't this be tracked easily in the firmware? Is it possible to get > firmware changes? Yes, firmware would probably able to do that. I don't explicitly whether firmware changes would be possible. But I would not be to optimistic. Atheros bought ZyDAS last year and doesn't publicly market or support the product anymore. Daniel started last year an assembler/disassembler for the firmware, but I haven't seen any activity for this recently. -- Uli Kunitz |
From: Jon S. <jon...@gm...> - 2007-01-28 18:41:11
|
On 1/28/07, Ulrich Kunitz <ku...@de...> wrote: > On 07-01-28 12:52 Jon Smirl wrote: > > > On 1/28/07, Ulrich Kunitz <ku...@de...> wrote: > > > There is no simple way to count the RTS failures and successes. You could > > > however get all the RTS packets and work from that. However I > > > would regard this as waste of device-to-host bandwidth, which is > > > shared of all USB devices on the same host adapter. > > > > Couldn't this be tracked easily in the firmware? Is it possible to get > > firmware changes? > > Yes, firmware would probably able to do that. I don't explicitly > whether firmware changes would be possible. But I would not be to > optimistic. Atheros bought ZyDAS last year and doesn't publicly > market or support the product anymore. Is the zd1211b still being produced? Or is Atheros killing it? I'm working on an embedded design and I don't want to design in a part that is disappearing. > > Daniel started last year an assembler/disassembler for the > firmware, but I haven't seen any activity for this recently. > > -- > Uli Kunitz > -- Jon Smirl jon...@gm... |
From: Ulrich K. <ku...@de...> - 2007-02-03 14:46:24
|
On 07-01-28 13:41 Jon Smirl wrote: > Is the zd1211b still being produced? Or is Atheros killing it? I'm > working on an embedded design and I don't want to design in a part > that is disappearing. I don't know. On the web page http://www.atheros.com/RD you still can find the contact data of sales personnel. However the chip itself is nowhere mentioned on the website and a google search finds only the Linux related pages. Kind regards, Ulrich -- Uli Kunitz |
From: Jon S. <jon...@gm...> - 2007-02-03 15:13:20
|
On 2/3/07, Ulrich Kunitz <ku...@de...> wrote: > On 07-01-28 13:41 Jon Smirl wrote: > > > Is the zd1211b still being produced? Or is Atheros killing it? I'm > > working on an embedded design and I don't want to design in a part > > that is disappearing. > > I don't know. On the web page http://www.atheros.com/RD you still > can find the contact data of sales personnel. I had been attracted to the zd1211 because it was easily available at low cost. Now I'm beginning to think that was because the vendors were getting rid of their stock. I have been able to get Gigabyte version for $10. Lately I have started looking at ralink based modules. They are running about $20. I would like to find an 802.11 a/b/g adapter based on this module, but I have been unable to locate one. http://www.ralinktech.com/ralink/data/RT5201USB_brochure.pdf A while ago I saw a mail mentioning that there was a wireless chip that had open doc but nobody had written a driver for. Anyone remember which chip that was? We should send it to GregKH and see if he will write the driver. > > However the chip itself is nowhere mentioned on the website and a > google search finds only the Linux related pages. > > Kind regards, > > Ulrich > > -- > Uli Kunitz > -- Jon Smirl jon...@gm... |
From: Daniel D. <ds...@ge...> - 2007-02-03 15:40:15
|
Ulrich Kunitz wrote: > I don't know. On the web page http://www.atheros.com/RD you still > can find the contact data of sales personnel. My company inquired to both the Taiwan sales contact and the main Atheros sales contact addresses about ordering a large stock of ZD1211 devices. They did not respond from either address. Daniel |