Re: [Madwifi-devel] [PATCH] RFC: link distance specification
Status: Beta
Brought to you by:
otaku
From: Sam L. <sa...@er...> - 2004-05-26 17:59:39
|
On Wednesday 26 May 2004 10:16 am, Michael Renzmann wrote: > Hi Sam. > > Sam Leffler wrote: > > If you can set a value w/ a sysctl then I see no reason for a module > > parameter unless it is important to have the value set before the > > interface is attached (e.g. debugging or the country code). You should > > be able to get the same effect by doing the sysctl in a hotplug script or > > similar. > > See my last mail to Togg. I think I'll remove the module parameter, also > because it will be much more complicated if it's possible to set the > distance values for each interface this way. > > >>I added support for another sysctl (for setting distance), the module > >>parameter "distance" and automatic calculation of the timings depending > >>on link distance. > > > > Algorithmic conversion of parameters belongs in user-mode applications > > and not the driver unless they are the "one true way" to specify a value > > or there are synchronization issues such as needing to update multiple > > values together to avoid having the hardware in a bad state. It's not > > clear to me that this stuff qualifies. > > Following your argumentation I'd say: it doesn't qualify. While it's > currently the "one way" we can go (because it's the only one that has > been implemented), it won't stay like this forever. The driver lets you set individual parameters in usecs. This is one method that has been implemented. If I understand correctly you've added a method by which all the parameters are set as a group based on distance. I suggested this go in a user tool/app because there's already a way to set the parameters (i.e. w/ the individual sysctl's) and there's no compelling reason to set them as a group within the driver (e.g. because having a short interval between setting them individually might lead to problems). There are a myriad of parameters one might tweak and pushing everything like this in the driver feels wrong to me. Better, perhaps, to create an athcontrol tool or similar to host this sort of code until the wireless extensions folks decide to attack the problem. > > > I also suspect there are better solutions for tuning the > > timeout values than using a fixed formula; e.g. by sending "echo packets" > > and monitoring the TSF to get proper timing. > > What do you mean with "TSF"? Could you explain this idea a little more? TSF is the synchronized clock kept by the network. Each 802.11 frame has a tsf value and I was suggesting that you could use that to measure time between nodes in a p-t-p network if you can get to the raw 802.11 frames (don't know if there's a convenient way in Linux; there is in other systems). > > Possibly it would be the best to just provide device-dependant sysctl > access to slottime, ack-timeout and cts-timeout and add a shellscript or > binary tool that allows to estimate the values for a given "long range > link". When one sets up that link he runs the script once, and the > script will tell which values are needed. These values then can be set > inside the startup script or thelike. Yes, this was my suggestion. > > >>Note: Togg mentioned that the manual settings will be lost with his > >>patch, as soon as the card is reset (or looses association). I think I > >>have fixed this problem, by adding a call to ath_settimings() inside > >>ath_init(). > > > > I've fixed the HAL to save+restore these register settings across a > > reset. It should be in the next release. > > Is it still necessary to have a call to ath_settimings() inside > ath_init() then? Not when the new hal is available. Sam |