On Thu, 2007-09-06 at 03:32 +0200, Ian Schram wrote: > I thought I'd try and answer this question to the best of my ability, since it > has been asked before. And even though it's open source and now has been submitted > to this list, leaving this unanswered feels like a creepy way of potential time bombs > and frustration. That said I'm probably not the best person to do it. Thanks, I appreciate it. > iwl3945-rs: > > - the device can retry at different rates, and hence is able to deduct > from the total number of retries a packet needed at which rates it failed/ > succeeded We recently discussed this capability, atheros hardware as it as well, so we need a generic way to tell mac80211 how many retry rates the hardware can support so that better rate control algorithms can be written. I don't see this as device specific but rather as something the mac80211 driver interface is currently lacking. Cf. the "minstrel" rate control algorithm. > - tables of expected tpt (throughput?) which are used in the the throughput > calculation are probably not very universal? > there aren't identical for 3945 and 4965. Seems to me like something the driver should be doing and reporting to the rate control algorithm via some defined interface. > -some synchronization of the station list with the device ucode happens here This is totally wrong. Please extend mac80211 instead, maybe the sta_table_notification callback. > So that's that. Some questionable implementation details, but it does use > device specific logic/capabilities in order to decide which rate to use. > Now what do we do? As a first step, I think we (i.e. mostly you because only few other people have an interest right now) should work on defining an interface between the drivers and mac80211 that allows the drivers to export these capabilities like "how many different retry rates can I give you with one packet" in order to allow different rate control algorithms to take advantage of that. Oh and then don't just implement the interface and push it onto us as a "ok done" thing but discuss the interface first. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
