Delay and data throughput on 802.11b WLAN with 50 nodes

hi,

we have to connect 50 devices with an WLAN. We thought about the
Lantronix WiPort which is only a 802.11b device. I wonder how 802.11b
handles conflicts. As far as I know it works with an CSMA/CD
algorithm. Does anyone have experience with an WLAN with about 50
nodes? For every node we will send about 30 times per second a TCP
Packet with 30 bytes user data. So we transmit a total of about
150KByte per second ( Data+TCP/IP Header = 100Byte, 50nodes * 30
packets * 100 bytes). The maximum data throughput on 802.11b is about
600KByte/s, so we only use 1/4 of it.
But it's a real-time application and our deadline for delayed packets
is about 100ms. Will a 802.11b WLAN be fast enough for such an
application. Or can the delay of a packet become too long due to
collisions between the nodes?

I am happy for every hint or answer. Thanks a lot.

Regards,

Andreas

Andreas wrote:

>hi,
>
>we have to connect 50 devices with an WLAN. We thought about the
>Lantronix WiPort which is only a 802.11b device. I wonder how 802.11b
>handles conflicts. As far as I know it works with an CSMA/CD
>algorithm. Does anyone have experience with an WLAN with about 50
>nodes? For every node we will send about 30 times per second a TCP
>Packet with 30 bytes user data. So we transmit a total of about
>150KByte per second ( Data+TCP/IP Header = 100Byte, 50nodes * 30
>packets * 100 bytes). The maximum data throughput on 802.11b is about
>600KByte/s, so we only use 1/4 of it.
>But it's a real-time application and our deadline for delayed packets
>is about 100ms. Will a 802.11b WLAN be fast enough for such an
>application. Or can the delay of a packet become too long due to
>collisions between the nodes?
>
>I am happy for every hint or answer. Thanks a lot.
>
>Regards,
>
>Andreas
>
>
>
My first reaction is that you don't have a hope in hell. 802.11 is
not RT-friendly.

But it really depends on what happens when a packet is missed. Some
RT systems cope with a missed data item (or bad data) by substitution
(e.g., extrapolation from earlier samples), and carry on; if your
transmitters use write-and-run, and your receivers can afford a few
missed samples, you may survive. But, if a few missed packets are a
disaster, then a shared 802.11 design should and likely will lead to
a court case for malpractice.

And, speed is not the only issue here; 802.11 is prone to RFI and
retransmit storms and other things that go bump in the night.

Overall, using unsolicited data from unsynchronized transmitters is
a likely recipe for RT failure. One possible solution is to have
the receiver solicit data from each transmitter, and to never use
this 802.11 channel for any traffic other than solicitations and
immediate responses; alternatively (for higher bandwidth), use a pair
of 802.11 channels -- one for data requests from the receiver and
one for responses. Safe RT design probably dictates preventing the
data channel(s) from being used for other traffic and, hence, interfering
with RT traffic; so, you may need a third channel for non-RT traffic
unless you use a RT OS (not WinDuhs) in the transmitters.

Cheap, fast, reliable: pick one.

--
Cheers, Bob

Andreas,

If your application can tolerate at most a 100ms delay, then IMO
you're making a big mistake by choosing to use TCP.

Now, your application as you describe it (modulo your selection of
TCP rather than UDP) sounds not unlike G.711 VoIP. I will note
that we support at most 7 concurrently active G.711 VoIP calls
in an *optimally designed* 802.11b cell. So, to support 50
such calls, one would want to deploy at least 8 APs in your coverage
area.

You may find it instructive to consult our _Cisco Wireless IP Phone
7920 Design and Deployment Guide_,
http://www.cisco.com/en/US/products/...0802a029a.html,
which gives some idea of what you need to do to support VoIP over
a WLAN.

In particular, the section entitled "Maximum Throughput Calculations
for 802.11b WLAN" may prove useful.

Hope this helps,

Aaron

---

~ hi,
~
~ we have to connect 50 devices with an WLAN. We thought about the
~ Lantronix WiPort which is only a 802.11b device. I wonder how 802.11b
~ handles conflicts. As far as I know it works with an CSMA/CD
~ algorithm. Does anyone have experience with an WLAN with about 50
~ nodes? For every node we will send about 30 times per second a TCP
~ Packet with 30 bytes user data. So we transmit a total of about
~ 150KByte per second ( Data+TCP/IP Header = 100Byte, 50nodes * 30
~ packets * 100 bytes). The maximum data throughput on 802.11b is about
~ 600KByte/s, so we only use 1/4 of it.
~ But it's a real-time application and our deadline for delayed packets
~ is about 100ms. Will a 802.11b WLAN be fast enough for such an
~ application. Or can the delay of a packet become too long due to
~ collisions between the nodes?
~
~ I am happy for every hint or answer. Thanks a lot.
~
~ Regards,
~
~ Andreas

Hi Bob,

thanks for your answer. we want to do a show with 50 robots. the most
important thing is that the robots movement is synchronized (they
dance) and it shouldn't be visible that the first robot starts his
movement before the last one. we discussed how the robots should be
controlled. So as i thought it seems like it's not a good idea to
control all functions from a central server.

I think we have to build "intelligent" robots. Then we can send a
specific movement code to every robot an then send movement-start
messages as a broadcast.

On 4 Nov 2005 09:01:52 -0800, "Andreas" <soror78@hispeed.ch> wrote:

>thanks for your answer. we want to do a show with 50 robots. the most
>important thing is that the robots movement is synchronized (they
>dance) and it shouldn't be visible that the first robot starts his
>movement before the last one. we discussed how the robots should be
>controlled. So as i thought it seems like it's not a good idea to
>control all functions from a central server.
>
>I think we have to build "intelligent" robots. Then we can send a
>specific movement code to every robot an then send movement-start
>messages as a broadcast.

One of my friends was involved in almost exactly the same scheme for
operating indoor race cars and robots via 802.11. It worked just fine
with 3-5 robots running simultaneously on one 802.11 channel. However,
when we tried it with 15 robots, response time and packet loss rose to
unacceptable levels. Unresponsive would be an understatement. Out of
control would be closer to the mark.

I got involved and tweaked the access points wireless settings to
improve reliability. In general, I enabled CTS/RTS flow control with
a very low threshold (about 250-400 bytes) and reduced the
fragmentation threshold to about the same value. 802.11b
compatibility was disabled (this was an 802.11g system). The
controllers were reprogrammed so that they did not require continuous
updates and would only transmit when there were changes in position
and direction. Control protocols were switched from TCP to UDP which
did not require acknowledgements. The walls and ceiling of the room
were covered with anti-reflective panels.

That brought the system up to about 30 robots. They only had 30
robots so there was no way to test larger numbers. My guess is that
it could have made it to 50. The real trick was the control algorithm
being tweaked to reduce wireless traffic by a factor of about 100. The
original designers had simply implemented the conventional radio
control servo system over 802.11 which transmits continuously.

Even so, the packet loss was relatively high and response time (ping)
varied radically with this packet loss. Personally, I think a
conventional (non spread spectrum) system using TDMA would be more
effective with large numbers of clients, but they wanted to do it off
the shelf. This was largely proven when they tried using Karlnet
Turbocell and StarOS wireless protocols. These are polling protocols
instead of a big free for all, which scales much better than CDMA/CD.
However, they were deemed too expensive to require participating robot
owners to purchase.
http://www.star-os.com
http://www.karlnet.com
If cost of licensing is not an issue, you might want to look into
these.

Anyway, then came the dot com bomb and funding dried up. I have no
clue what happened to this project but can find out if necessary.

--
Jeff Liebermann jeffl@comix.santa-cruz.ca.us
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

"Andreas" <soror78@hispeed.ch> wrote in message
news:1131101030.878898.199750@g43g2000cwa.googlegr oups.com...
> hi,
>
> we have to connect 50 devices with an WLAN. We thought about the
> Lantronix WiPort which is only a 802.11b device. I wonder how 802.11b
> handles conflicts. As far as I know it works with an CSMA/CD
> algorithm. Does anyone have experience with an WLAN with about 50
> nodes? For every node we will send about 30 times per second a TCP
> Packet with 30 bytes user data. So we transmit a total of about
> 150KByte per second ( Data+TCP/IP Header = 100Byte, 50nodes * 30
> packets * 100 bytes). The maximum data throughput on 802.11b is about
> 600KByte/s, so we only use 1/4 of it.

i think you are forgetting something - TCP requires ACK packets to flow as
well - so there are twice as many packets flying around.

so - you are too near the capacity if 802.11b to handle your data
requirements (ignoring the other issues which have already been pointed
out).

> But it's a real-time application and our deadline for delayed packets
> is about 100ms. Will a 802.11b WLAN be fast enough for such an
> application. Or can the delay of a packet become too long due to
> collisions between the nodes?
>
> I am happy for every hint or answer. Thanks a lot.

this is no use if each robot is controlled separately, but if you are
sending the same commands to multiple devices maybe you could use IP
multicast to cut down on the amount of packets needed?

multicast might also relax the timing constraints, since every device would
pick up the command at the same time.

you also need to worry about reply traffic (ie. if you need it and what it
should be).
>
> Regards,
>
> Andreas
--
Regards

stephen_hope@xyzworld.com - replace xyz with ntl

hi Jeff,

thanks for your answer. So with an 802.11g it's possible to handle 30
robots. That's a good information. We also want to do it off the shelf,
because we haven't enough time. I think we will build "intelligent"
robots with implemented collision detection and motor control. In case
we send only commands like "go to position X with speed Y". Then we
will only need about 2 or 3 Messages per second and robot. Can you
rememer what kind of WLAN modules they used? I could only find modules
with 802.11b for embedded Systems (we would like to connect them with a
serial port). A module with 802.11g would be nice i think. Any
suggestions?

Regards,

Andreas

hi Aaron,

thanks, the link is very helpful.

Regards,

Andreas

hi stephen,

thanks for your answer. you're right about the ACK. I didn't include it
in the calculation because i thought the ACK Packages are very small.

I think we will transmit the commands with TCP and then send a UDP
broadcast to start all 50 robots simultaneously. With "intelligent"
robots with integrated collision detection i hope we will only need 2
or 3 messages per robot and per second. I hope we will get this through
the WLAN.

Is there an important difference between broadcast and IP multicast?

Regards,

Andreas

On 5 Nov 2005 08:51:30 -0800, "Andreas" <soror78@hispeed.ch> wrote:

>So with an 802.11g it's possible to handle 30
>robots.

That's 10 robots on 3 non-overlapping channels. However, I'm sure it
could be done with 50 bots on just one channel using UDP and by
limiting transmissions to only those bots that needed an update.

The proposed system was essentially interrupt drive. The speed and
direction was sent to the bot. The bot had enough intelligence to
point itself in the correct direction and start moving. If it hit
anything along the way, it would transmit an interrupt (packet) and
the controlling program would need to revise the speed and direction.
This drastically reduced the transmission times.

>We also want to do it off the shelf,
>because we haven't enough time.

That's fine because you'll have plenty of time to do it over again.

Is this a club, skool, or class project?
http://www.cs.cmu.edu/~brettb/robocup/
http://www.eurobot.org/eng/
http://www.robot-ch.org/site/index.php?sel_lang=english
Which one?

>I think we will build "intelligent"
>robots with implemented collision detection and motor control. In case
>we send only commands like "go to position X with speed Y". Then we
>will only need about 2 or 3 Messages per second and robot.

That will barely work. That's far too high an update rate.

Since ours was indoors, the designers decided to NOT use a GPS or
hyperbolic location system but used an overhead video camera (Global
vision) and PC provided the location of each robot. The last version,
which was NOT working before the project died, use multiple cameras
and parallax location. However, both of these systems had problems
with long delay times in locating the bots. 200msec to several
seconds was typical. That resulted in failure of simple positioning
algorithms such as what you're suggesting. In some cases, the bot
would arrive at its destination before the position report arrived
resulting in some rather bizarre behavior. It also forced maneuvering
to be limited to straight line positioning. The update problem was
reduced by limiting position update to only after a collision, where
it was imperitive to obtain a corrected position.

Let's run the numbers. 3 position updates per second per bot requires
333msec latency. If a position report is delayed by 333msec, it won't
work. However, 50 bots on a channel requires 6.67msec latency, and
that's not going to happen in an 802.11g collision infested
environment. Even splitting it over 3 channels at 20msec latency is
going to be difficult (one channel per team). Fortunately, you don't
have to update all 50 robots at one time and will probably be
concentrating on a few active players. The active bots can possible
do 3 updates per second, but the other will need to wait much longer.
I'll leave the algorithmic problem to you, but I suspect that you will
need to drastically reduce your transmission rate.

>Can you
>rememer what kind of WLAN modules they used? I could only find modules
>with 802.11b for embedded Systems (we would like to connect them with a
>serial port). A module with 802.11g would be nice i think. Any
>suggestions?

Yes, but it was too long ago to be useful. At the time, all that was
available was 802.11b. The SBC (single board computer) were various
overpriced PC104 designs (Kontron?) with a mezzanine PCMCIA adapter
board and an Orinocco classic silver card. This was not going to be
the final production robot, but the company imploded before the cost
and configuration could be optimized.

--
Jeff Liebermann jeffl@comix.santa-cruz.ca.us
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

"Andreas" <soror78@hispeed.ch> wrote in message
news:1131212076.424116.269190@g43g2000cwa.googlegr oups.com...
> hi stephen,
>
> thanks for your answer. you're right about the ACK. I didn't include it
> in the calculation because i thought the ACK Packages are very small.
>
> I think we will transmit the commands with TCP and then send a UDP
> broadcast to start all 50 robots simultaneously. With "intelligent"
> robots with integrated collision detection i hope we will only need 2
> or 3 messages per robot and per second. I hope we will get this through
> the WLAN.

sounds like a scary amount of traffic for this - you are at 150 msg / sec
(ignoring ACKs)
>
> Is there an important difference between broadcast and IP multicast?

not for this, unless you want to use IGMP like suppressed announcements.

>
> Regards,
>
> Andreas
--
Regards

stephen_hope@xyzworld.com - replace xyz with ntl

Jeff Liebermann schrieb:


> Is this a club, skool, or class project?
> http://www.cs.cmu.edu/~brettb/robocup/
> http://www.eurobot.org/eng/
> http://www.robot-ch.org/site/index.php?sel_lang=english
> Which one?

It's not a robot-contest. It's just for a exposition. It should combine
art with technology. The robots move on 5 railways and build symbols,
changing colors, ... .

> >I think we will build "intelligent"
> >robots with implemented collision detection and motor control. In case
> >we send only commands like "go to position X with speed Y". Then we
> >will only need about 2 or 3 Messages per second and robot.
>
> That will barely work. That's far too high an update rate.

Also too high? I thought WLAN would be more powerful.

> Let's run the numbers. 3 position updates per second per bot requires
> 333msec latency. If a position report is delayed by 333msec, it won't
> work. However, 50 bots on a channel requires 6.67msec latency, and
> that's not going to happen in an 802.11g collision infested
> environment. Even splitting it over 3 channels at 20msec latency is
> going to be difficult (one channel per team). Fortunately, you don't
> have to update all 50 robots at one time and will probably be
> concentrating on a few active players. The active bots can possible
> do 3 updates per second, but the other will need to wait much longer.
> I'll leave the algorithmic problem to you, but I suspect that you will
> need to drastically reduce your transmission rate.

Well, I see. Hmm, then I will try to reduce the traffic to 1 message
per second and robot. Unfortunately all robots will move most of the
time. So I have to get the data for all 50 robots through the WLAN. I
think I will try to transmit several commands in one packet, so the
robots run their own timer to execute the sequence of commands. I hope
a WLAN can handle 50 packets per second and a few broadcast-messages at
the end of the second to start all robots synchron.

> >Can you
> >rememer what kind of WLAN modules they used? I could only find modules
> >with 802.11b for embedded Systems (we would like to connect them with a
> >serial port). A module with 802.11g would be nice i think. Any
> >suggestions?
>
> Yes, but it was too long ago to be useful. At the time, all that was
> available was 802.11b. The SBC (single board computer) were various
> overpriced PC104 designs (Kontron?) with a mezzanine PCMCIA adapter
> board and an Orinocco classic silver card. This was not going to be
> the final production robot, but the company imploded before the cost
> and configuration could be optimized.

Thanks nevertheless. We will use microcontroller (Atmega128) to run our
robots. We have to save every cent we can, so we won't be able to buy
SBCs.

Thanks a lot for your help.

Regards,

Andreas

hi stephen,

well I thought WLAN would be more powerful. Seems like I am totally
wrong. Well, I hope to get 50 msg/sec through the WLAN. Perhaps on 2
channels, if it's too much for an single channel.

Regards,

Andreas

On 8 Nov 2005 06:28:57 -0800, "Andreas" <soror78@hispeed.ch> wrote:

>It's not a robot-contest. It's just for a exposition. It should combine
>art with technology. The robots move on 5 railways and build symbols,
>changing colors, ... .

Nice idea. Sounds interesting.

>Also too high? I thought WLAN would be more powerful.

Think of 802.11g as a shared bandwidth among all the robots on one
channel with a maximum of 3 non-overlapping channels available. That's
because exactly only one transmitter can effectively transmit at a
time. The total aggregate thruput is about 20Mbits/sec maximum for a
54Mbit/sec connection. Everything that goes wrong (reflections,
collisions, interference, microwave ovens, cordless phones, video
xmitters) will reduce the aggregate bandwidth. I'm not sure what
number to use in the calculations but I'll guess about 10Mbits/sec
aggregate thruput for 802.11g and perhaps 2Mbits/sec for 802.11b.

>> Let's run the numbers. 3 position updates per second per bot requires
>> 333msec latency. If a position report is delayed by 333msec, it won't
>> work. However, 50 bots on a channel requires 6.67msec latency, and
>> that's not going to happen in an 802.11g collision infested
>> environment. Even splitting it over 3 channels at 20msec latency is
>> going to be difficult (one channel per team). Fortunately, you don't
>> have to update all 50 robots at one time and will probably be
>> concentrating on a few active players. The active bots can possible
>> do 3 updates per second, but the other will need to wait much longer.
>> I'll leave the algorithmic problem to you, but I suspect that you will
>> need to drastically reduce your transmission rate.

>Well, I see. Hmm, then I will try to reduce the traffic to 1 message
>per second and robot. Unfortunately all robots will move most of the
>time. So I have to get the data for all 50 robots through the WLAN. I
>think I will try to transmit several commands in one packet, so the
>robots run their own timer to execute the sequence of commands. I hope
>a WLAN can handle 50 packets per second and a few broadcast-messages at
>the end of the second to start all robots synchron.

I think they can but you'll probably need to add acknowledgements that
the robots have received the command along with some manner of routine
for recovering from lost commands, collisions, and position errors.
I'm sure 1 message per second will work. However do NOT expect to get
low latency or even consistant latency with 50 active radios. The
chances of mutual interference and collisions are just too high.

If you're updating all 50 devices all the time, then you might as well
go to some type of polling scheme instead of a collision based CSMA/CD
system. It's more efficient and offers predictable and fairly
consistent latency. Look into Star-OS and Karlnet which unfortunately
might be expensive.

>Thanks nevertheless. We will use microcontroller (Atmega128) to run our
>robots. We have to save every cent we can, so we won't be able to buy
>SBCs.

I dunno about this...
http://www.atmel.com/dyn/products/pr...p?part_id=2018
With a 16MHz clock, you're going to have some difficulty moving
54Mbits/sec data (plus overhead) through a serial/USB port. It can be
done with buffering, but your latency will increase. Using a USB
radio, I'm not even sure you can cram motion control and an 802.11 MAC
layer into 4KBytes of stored code. You could use a more complex stand
alone radio with an RS-232 interface, but that will be expensive.

There are Atmel based wireless sensor nets available:
http://www.xbow.com/Products/product...ls.aspx?sid=61
but they use 433/900Mhz and at a much slower data rate. However, this
might give you some ideas.

--
Jeff Liebermann jeffl@comix.santa-cruz.ca.us
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558