Floyd L. Davidson wrote:
Wolfgang Weisselberg wrote:
Floyd L. Davidson wrote:
There
will never be a time when at least 10 or so clients are
not trying to get access.

And that's lowering the individual thoughput by a factor 400?
(WLAN netto speed, single user, 54 MBit/s brutto versus
dialup modem brutto speed of 33.6 kbit/s upload)

Yes. When none of the clients can get a connection, due to
repeated contention, there is *no* throughput for any client.

You're of course completely right ...
.... if there WERE no way to make a connection, there WOULD BE
no throughput.


Unless one of them has a
received signal strength that is more than 6 dB greater
than the sum of the others, the AP cannot detect a
single client.

The way it works:
Stations listen if the channel is free, and have random
timers (the more collisions, the larger) which cause most
packets to not be involved in a collision. (It's actually
more complicated than that, but read yourself ...)
http://www.comlab.hut.fi/studies/324...ot/4_wlan2.pdf

The upshot is: There's no "the sum of the others".

Yes there is. Now do some research on something called
"capture effect" with FM or PM modulated radio signals.

The capture effect sort of requires that at least 2 nodes are
sending simultaneously, true? What happens if this situation
is mostly circumvented --- like in WiFi, where (see link above)
extreme pains are taken to avoid this sort of thing?

Or are you talking about radiation from other sources, in
which case WiFi won't work even with a single client?

The functionality is on several levels, not just WIFI contention.
There are also colisions between clients transmitting at the same
time.

Of course. In which case they'll detect that there has been a
collision as they don't get an ACK, increase the limit of their
CW_{backoff} and back off more.



If the AP has an RSL for one client that is 6 dB or more
above *all* other signals in the desired bandwidth, that client
will be accepted, otherwise the AP will not be able to detect
a usable signal from any of them.

True. Just not as common a problem as you make it out to be.
Just like dropping your camera during a studio assignment and it
breaking *is* a real problem ...


In fact, even with a CW_{Backup} of only 32 (i.e. set for rather
few collisions, it can ramp up to 255) the chance of collision is
50% with 16 active stations and 63% with 35 active stations.[1]

No answer?

So none of them get a connect, they all
time out and take a random sleep.

Only one will talk, and in most cases it will get through.
And if not on the first try, then on the second, third of fourth.

Wrong. Whatever makes you think "only one will talk"!
Every time there is a collision, the entire process
essentially starts over again.

A collision only happens when both sides start talking at the
same time. If one already started, in your PJ case all other
WiFi-nodes pick up the fact that someone is talking and
remain silent.[2] GOT THAT?

The chance for 2 or more nodes to send at the same time means
that their microsecond timers must pick identical values.

The chance of 2 nodes having the same timer set is
p_{collision} = 1 / CW_{backoff}

The chance that the second node does NOT have the timer
set to the same value is
p_{no collison} = (CW_{backoff} - 1) / CW_{backoff}

So for CW_{backoff} == 7 the chance for 2 nodes would be
6/7 for no collisons.

For 3 nodes it would be:
p_{no collison} = (CW_{backoff} - 1) / CW_{backoff} *
(CW_{backoff} - 1) / CW_{backoff}
= ( (CW_{backoff} - 1) / CW_{backoff} )^2

For n nodes it is:
p_{no collison} = ( (CW_{backoff} - 1) / CW_{backoff})^(n-1)

and
p_{collision} = 1 - p_{no collision}
= 1 -( (CW_{backoff} - 1) / CW_{backoff})^(n-1)

Given n = (48 PJ + 1 AP) = 49 (i.e. all 48 on one single
channel, all wanting to talk NOW):

CW_{backoff} p_{collision}
in %
7 99.94% (typical lowest value)
32 78.2%
64 53%
128 31%
255 17% (max value)


Now, given that only a completely incompetent person would
offer only one channel:

n = (48 / 3 PJ + 1 AP) = 17

CW_{backoff} p_{collision}
in %
7 92.73% (typical lowest value)
32 42%
64 23%
128 12.4%
255 6.44% (max value)

That's simple probability calculus.

The chances never get any
better.

Wrong, CW_{backoff} is raised through collisions.

Go try yourself: roll one black and 4 red 6-sided dice and
see how often the black and any red dice have the same number.
Now repeat that with the same number of 20-sided dice instead!

And for kicks, try with 1 + 16 32-sided dice (your PJ-example,
3 channels, CW_{backoff} = 32) and with 1 + 16 *255*-sided dice
(same, but CW_{backoff} = 255).

You are assuming that all clients can detect all other clients,
which is probably not true.

In your PJ at a press conference case, it very probably IS true
.... and then there *is* RTS/CTS for hidden nodes.

Of course by that
time another group is ready (after waiting for a random
period), and the story repeats itself.

Yep, all the group of 10+ clients has each RANDOMLY choosen one
and the same period of time --- and will do so every time!

That's why it's called RANDOM!

And that is exactly why if fails too.

It doesn't fail.
Sure, you _could_ build a token ring wireless network.
However you can't use token ring for nodes that try to connect,
as they are not yet in the ring ... and if there are 2 nodes
waiting, they'd *always* cause a collision that way when sending
the token to "any new node". With random they only cause a
collision *sometimes*.

In addition, nodes dropping off the network (switched off,
getting out of range, ...) cause a token to be dropped.

Since you want high bandwith and care a bit less about latencey,
not (sorta)-guaranteed latency (for a given, unchanged node group)
and low bandwidth, token ring's not the right solution

Eventually luck
might allow one client to connect. That is going to work
to some degree up to 4 clients per channel, but with more
than that the chances of any client actually getting a
connection start to be very slim.

So how exactly do you arrive at 4 clients per channel?

No answer?

Pulling data from your ass?

Get you head out of yours.

Brownnosing oneself is a new one.


Especially when 4-5 clients give the best combined throughput
rate for TCP traffic for a 54 MBit connection?[1]

You did pull them out of your ass, didn't you?

Get you head out of it...

I'm not brownnosing you.

But I can't help but notice *I* have data and you pull
numbers from your ass.


In fact, 48 *active* clients on 3 channels have a combined
throughput of 45 MBit/s of data (with all the TCP overhead and
WLAN overheads and timeouts and retries and collisions already
taken care off), so each PJ has 960 kbit/s.[1]
A modem is 33.6 kbit/s.

Do your math ...

Learn how it works.

Done.
It works that way:

1. you claim something wrong
2. people provide real life observations, mathematical models,
studies and more that say you're wrong
3. you claim they *all* don't know a thing and can't read.
4. You get plonked. Again.


Instead there will virtually always be
contention, and instead of being 4 times faster than a
dialup, it would probably be about 10 times slower... at
best!

So 3 channels at 54 MBit/s can't keep up with 48 clients which
sporadically try to pass data through them to the outside.

Correct.

Hmmm. [1] says something very different.

You apparently didn't read what you are citing.

s/You app/Floyd app/
s/you are/Wolfgang is/
Now it's correct.


He
http://serverfault.com/questions/192...le-wifi-router
is someone connecting 60 iPads over 3 channels.

We can find somebody somewhere who said almost anything on
the Internet, but that doesn't make it correct.

True --- after all, I found *you* saying wrong stuff.



Regardless, just like the other URL, you don't seem to have
actually read the article you cite!

Please point out exactly where in the article it is said that
more than 4 clients are a really huge problem for WiFi.


Whom to believe? Those who have facts and others that have mathematical
models congruent with yet other people's tests and experiences,
or ... you ...?
Tough question, innit?
But then maybe you do get 48-PJ-news conferences pretty regular
up in Barrow ... who knows?

Yep, no answer. Floyd does not have *any* credentials.

I see.

Probably not, because you don't seem to know how it works or why
and have no interest in learning eitehr.

I'll await your "OK, I *was* completely wrong on all of my
claims, including the WiFi and the learning!" admission.

See, you haven't learned anything!

I've learned you're an idiot, Floyd. You're wrong and too stupid
to even see that you're wrong.
Yes, my first calculations were wrong (way too naive and hence
overestimating the effective netto bandwidth badly) but I learned.
Fast.

And now I'm quickly learning you are incapable of learning
*and* wrong, hence not worth talking to. One more post will
probably do it and you'll be back to the killfile.

[1] http://paper.ijcsns.org/07_book/201207/20120704.pdf

You *really* should read that paper and try to understand
the significance of what it says!

I did. Closely. It says that you're completely wrong in how
common collisions are. The significance is that your claim
| That is going to work to some degree up to 4 clients per
| channel, but with more than that the chances of any client
| actually getting a connection start to be very slim.
is wrong. Trying to get a connection is the essentially the
same as trying to sending data ...

-Wolfgang

[2] We're not having hidden nodes here. If we had, we could
use RTS/CTS.