[Olsr-dev] OLSRd 0.5.4 and 0.5.5 with ETT available

[Markus Kittenberger]

there are usually multiple wlan rates araound

first we have the bitrate for unicast and broadcast

based on this values a calculation of achievable bandwidth ist not easy, and
a constant factor will surely not work,..

the higher rate, the more overhead, same on higher distance,..

some wlan drivers present you the expected real data througput for each wlan
rate, for example madwifi which is internally used in rate selection, these
values seem to be correctet on packetloss and control data overhead,..

on atheros and mafwifi have a look into

/proc/net/madwifi/ath0/rate_info

here you here you find values for every neighbour, the most interesting is
the second column

from my tests these values reflect the achievable udp throughput quite well,
tcp throughput however depends on tcp implementation, which has some
tuneables as well,..

usually tcp throuput suffers quite much from packetloss, as tcp lowers the
senders bandwidth whenever packetloss occures (which makes much sense on
typically lossless networks)

but these tcp-specific problems have to be adressed in the rate selection
algorithms, as well as the tcp implementations


On Fri, Nov 14, 2008 at 1:15 PM, Erik Tromp <(spam-protected)> wrote:

>
> The problem with the reported rate is that in reality the throughput is
> usually a lot lower.
>
> As an example: my WLAN connection currently reports a rate of 130 Mbit/sec
> .
> However, the highest transfer rate I have seen is approx. 6 MByte/sec (48
> Mbit/sec). Somehow there is some overhead. Is that a fixed factor (130/48 =
> 2,7 ?) Or is that factor dependent on other things?
>
> This is what I meant by "it is difficult to determine the "quality" based
> on
> only these [L1/L2]metrics."
>
> But, even if the reported rate is not the actual rate, at least it is
> better
> than nothing. That is, provided the WLAN interface has the ability to
> choose
> for itself its bit rate. If a node owner chooses to fix the rate to say
> 54Mbit/s, then the OLSR network will think there is a very good quality
> link
> there, while in fact there may be not.
>
> Erik
>
>
>
> > -----Oorspronkelijk bericht-----
> > Van: (spam-protected)
> > [mailto:(spam-protected)] Namens Henning Rogge
> > Verzonden: donderdag 13 november 2008 16:56
> > Aan: (spam-protected)
> > Onderwerp: Re: [Olsr-dev] OLSRd 0.5.4 and 0.5.5 with ETT available
> >
> > On Thursday 13 November 2008 16:18:03 John Hay wrote:
> > >  > ifconfig wlan0 list sta
> > >
> > > ADDR               AID CHAN RATE RSSI IDLE  TXSEQ  RXSEQ CAPS FLAG
> > > 00:15:6d:53:1f:ee    0   64   6M 6.0    0   3271  42432 I    A
> > > 00:02:6f:41:19:2b    0   64   6M 13.5    0  53104  39744 I    A
> > > 00:80:48:50:9a:48    0   64   6M 8.0    0     82     96 I    A
> > > 00:02:6f:41:19:2b    0   64  36M 15.0   30   7664  22896 I    A
> > > 00:02:6f:41:19:2b    0   64  36M 15.5   30   8135  36928 I    A
> > > 00:02:6f:41:19:2b    0   64  48M 15.0    0   8640  39712 I    A
> > > 00:15:6d:53:20:0b    0   64   6M 2.5    0      0  16208 I    A
> > > ##############################
> >
> > Sounds good, have to look at the ifconfig sourcecode in BSD... :)
> >
> > So now we need a good linux sollution (someone with
> > experience in nl80211 here
> > ?) and windows of course...
> >
> > Henning
> >
>
>
> --
> Olsr-dev mailing list
> (spam-protected)
> http://lists.olsr.org/mailman/listinfo/olsr-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20081130/6aba36d4/attachment.html>