[MLB-WIRELESS] Re: [mesh] Transfer Rates

[Geoff Smith]

Cameron Donaghey wrote:

>  Hello All,
>   Ok got stuck into it and did some various testing last night. It
> seems that I did overlook that
> fact that transferring client->AP->client halves the bandwidth because
> the network is shared.
> The maximum I can achieve with client->AP->client is 282kB/s which
> allowed me to transfer
> a 20meg file in 1min11secs. This from what I now understand is quite
> good.
>
> I then decided to take the access point out of line and try the two
> clients peer to peer ( adhoc )
> or client->client mode and see what they could achieve by themselves.
> The maximum I could get with the same 20meg file was 569.05kB/s which
> allowed me to
> transfer the file in 35.5secs.
>
> I then also tried running one client to the access point connected to
> the second machine
> via its ethernet connection so client->AP->wired.
> The maximum I achieved from this was 546.6kB/s and I transferred the
> 20meg file in 37.9sec.
>
> So from all of this I think my setup is running how it should be
> although I still don't entirely
> understand when going client->AP->client the transfer speed is halved
> when compared to
> the client->client, perhaps someone could explain or perhaps this is
> not correct.
>

client->client is one rf transmission of the data,
client->AP->client requires two rf transmissions of the data, the total
rf bandwidth is
still the same (assuming a single channel AP) so you get half the
throughput.


Regards
Geoff



>
> Thanks for everyone's replies,
>    Cameron
>
> At 10:35 AM 9/17/2002 +1000, Geoff Smith wrote:
>
>> I may have mis-read the original post, I thought they were
>> attempting client->client transfers not client->AP->client
>> transfers.
>> My apologies if my post mislead anybody.
>>
>> Here is another link:
>> http://support.countr
>> day.net/Wireless/Performance/Wireless%20Efficiency.htm
>> it shows the lucent wavelan card getting 4.93Mbps, (616kB/s), for
>> client->AP->wired  transfers
>>
>> client->AP->client transfers with an AP with a single channel radio
>> will be
>> sharing
>> the same bandwidth between the two clients (i.e. half again) but
>> more
>> importantly
>> its very sensitive to the capabilities of the AP, embedded os, cpu
>> speed, memory
>> size
>> for queueing and buffering etc etc; i.e. implementation issues. In
>> addition the
>> people who
>> designed the AP probably tuned it for client->AP->wired connections
>> not client->AP->client connections.
>>
>> If the orginal post meant kB, then he was getting 2.4Mbps which is
>> pretty
>> impressive
>> and would represent 21% of the total bandwith
>> If the original post meant kbits then he was only getting 2.6% of
>> the total
>> bandwidth
>> for a client->AP->client test compared to 44.8% achieved by the
>> lucent card in a
>>
>> client->AP->wire test, or 27% achieved by the wl100 card in
>> client->AP->wire
>> tests.
>>
>> So if Cameron is doing client->AP->client, perhaps he can tell us
>> what
>> he is getting for a client->AP->wire test?
>>
>> Regards
>> Geoff
>>
>>
>>
>> Craig Mead wrote:
>>
>> > | Do you mean kB, k bytes or kb, k bits
>> > | 310kbytes -> 2.4Mbps
>> > |
>> > | Theoretically you should be able to get about half of the 11Mb
>> > | bandwidth.
>> > | ~ 5.5Mbps or ~680 kbytes/s
>> >
>> > Doing client to client transfers, this is extremely innacurate.
>> The 11b
>> > protocol has some massive overheads which consume a high
>> percentage of the
>> > possible thruput. The highest I've ever seen a link running
>> personally is
>> > 570k/sec (client to wired server behind AP). Though theoretically
>> from this
>> > you should then be able to get ~ 285k/sec client to client thru
>> AP, which is
>> > a lot higher than the 50KB/sec max I've obtained.
>> >
>> > I had a talk to some of the boys in Melbourne about this issue and
>> they said
>> > it also depends on the placement of the end nodes in relation to
>> each other
>> > and the AP for some reason. Not sure about the technicalities of
>> how this
>> > would effect it, but they said it did. As soon as I get a few more
>> links on
>> > I'll be able to do some more testing.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wireless.org.au/pipermail/melbwireless/attachments/20020917/d8cacd1b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gjsmith.vcf
Type: text/x-vcard
Size: 379 bytes
Desc: Card for Geoff Smith
URL: <http://lists.wireless.org.au/pipermail/melbwireless/attachments/20020917/d8cacd1b/attachment.vcf>