Re: [Madwifi-devel] new rate control module

[Derek S. <de...@in...>]

Hi,
 thanks for your feedback.

> Why no do just that? Then you can weigh the bit rates correctly. You only need to calculate the table once (unless you're into long distance links and time of flight matters).
Why not calculate what the effective bit rate is for a given bitrate.
I don't think this is reasonably possible. For a given bitrate 
(say 5.5mbps)  the effective bit rate goes up and down, depending on the packet size
 
Thus, we chose a simple simple solution that appeared to work. Thorsten,
if you like, we could discuss a better approach offline. However, if we
did do all this math, would it make a large difference ? I am thinking
that we would need to look at things like slot times (and other things
that you probably know about) and it gets hard real quick.

 =======================================

When designing this approach we considered finding a different method to 
use the rssi figures.

However, rssi is influenced by several factors, such as multipath
interference, other nodes transmitting at the wrong time, and signal
strength. Given that rssi is influenced by several factors, how does one
use rssi to determine what the ideal rate is?

Consequently, we felt it best to use an approach that measured the 
probability of success. 

=================================================================

> A different question is how does the inability to determine whether failure resulted from transmission or from ack loss affect your results?

I am not sure if this is worth chasing down. In both cases, the 
transmission of the packet failed. Consequently, the probability of 
success for this  particular rate should be lowered.


Derek.
==============================================================================================================
 On Thu, 6 Jan 2005, Thorsten von Eicken wrote:

> At 09:11 PM 1/6/2005 +1300, Derek Smithies wrote:
> >One does not want to "overly weight" the higher bit rates.
> >Suppose you use 
> >   success_probability * bitrate 
> >
> >compare 11mbs to 1mbs
> >To switch to 1mb (from 11) requires that the 1mb has a prob of 100%
> >but the 11mb has a prob of 9%. Or, 50%vs 4.5%.
> 
> If I get better throughput at 11Mb with a 9% success rate than at 1Mb with a 100% success rate, then I'd rather use the 11Mb rate, no? I think the key is in your comment that:
> 
> >Further, simply using bit rate is incorrect, as one should take into 
> >effect the time delay from management packets (rts/cts for example) that 
> >are sent at 1mbps with every data packet.
> 
> Why no do just that? Then you can weigh the bit rates correctly. You only need to calculate the table once (unless you're into long distance links and time of flight matters).
> 
> A different question is how does the inability to determine whether failure resulted from transmission or from ack loss affect your results?
> 
> Thorsten
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Madwifi-devel mailing list
> Mad...@li...
> https://lists.sourceforge.net/lists/listinfo/madwifi-devel
> 
> 
> 

-- 
Derek Smithies Ph.D.                           This PC runs pine on linux for email
IndraNet Technologies Ltd.                     If you find a virus apparently from me, it has
Email: de...@in...                    forged  the e-mail headers on someone else's machine
ph +64 3 365 6485                              Please do not notify me when (apparently) receiving a
Web: http://www.indranet-technologies.com/     windows virus from me......