noone@all.com hath wroth:

>> Why? What problems are you seeing with 802.11?

>latency.

Duz ping look like this?

fping 192.168.1.50 -c
Fast pinger version 2.16
(c) Wouter Dhondt (http://www.kwakkelflap.com)
Pinging 192.168.1.50 with 32 bytes of data every 1000 ms:
Reply[1] from 192.168.1.50: bytes=32 time=70.7 ms TTL=127
Reply[2] from 192.168.1.50: bytes=32 time=2.4 ms TTL=127
Reply[3] from 192.168.1.50: bytes=32 time=18.1 ms TTL=127
Reply[4] from 192.168.1.50: bytes=32 time=28.2 ms TTL=127
Reply[5] from 192.168.1.50: bytes=32 time=2.4 ms TTL=127
Reply[6] from 192.168.1.50: bytes=32 time=2.4 ms TTL=127
Reply[7] from 192.168.1.50: bytes=32 time=2.4 ms TTL=127
Reply[8] from 192.168.1.50: bytes=32 time=2.3 ms TTL=127

If so, you have interference problems, probably from other 802.11
devices on your own system. You can learn quite a bit about
interference from watching pings go by. Also see list of probable
sources of junk at:
<http://wireless.wikia.com/wiki/Wi-Fi#Interference>

>..lots of packet loss...

Packet loss at the IP level (using netstat) is indicative of a serious
problems. The wireless link will attempt retransmissions at the MAC
level which will not be visible on the IP level unless the number of
retransmissions exceeds a reasonable number of retries. This varies
with speeds, but is usually 3 or 4 retransmissions. If you're seeing
IP packet loss, there's something seriously broken.

>queuing up of commands because of a
>wireless retry bottleneck...

Sure. That's the inevitable result of packet loss, which is the
inevitable result of interference, multipath, or bad system planning.

>ethernets lack of QOS causes problems when a
>single pipe is transmitting audio video and command and control signals
>bidirectionally.

You can't fix packet loss with QoS. The best you can do is prioritize
packets and hope the time critical packets make it through. If you're
running real time video (30 frames per second) through a wireless
pipe, depending on compression type (MPEG4?) and picture size, you're
probably exceeding the channel bandwidth. If you're trying to do
video with TCP instead of UDP, you're probably filling the pipe with
retransmissions. These increase exponentially with ethernet after a
specific threshold (about 70% of full bandwidth). Give me some
numbers and I'll tell you where you've gone wrong. Ever consider
using a different channel or system for video and command/control?

>Bingo! the unlicensed bands are 'garbage bands'. What more can be said
>on that point?

Nope. You get what you didn't pay for. However, it's usually nowhere
near as bad as what you seem to be experiencing. Something else is
wrong.

>> If you want a clear channel, buy one from the FCC or one of auction
>> winners.
>
>Been thru this point many times. Goes back to the engineering triangle:
>cheap, quick, to spec...pick any two.

I've solved more problems by re-writing the specs than by engineering.
Back when I was burning myself with a soldering iron on a daily basis,
I was forced to actually make things work. These days, it's so much
easier to just question the specs and requirements. It's often
amazingly useful to negotiate performance specs to realistic levels.

>I don't consider yours and mine comments above to be mutually exclusive.
>From my perspective it goes back to the unreliable shared medium problem.
>smaller packets get thru more easily. what I find unacceptable is the
>ACK/NAK retries issue in 802.11.

Take a step backwards and consider what 802.11 is really doing. It's
encapsulating 802.3 ethernet packets. Ethernet has its own collision
detection and recovery mechanism, which is probably causing your
current problems. Suggestion.... unplug the 802.11 and just run it on
ethernet at 10baseT HDX (half duplex). That should be fairly close to
typical wireless performance but without the timing issues of
wireless. If that does not work (and I predict that it won't), then
you have fundamental system design problems that have nothing to do
with wireless.

>point taken...just investigating alternatives at this point. 802.11 is
>not designed for bursty low-latency transmission where QOS is important.

Actually, it is but not continuously. It's your video that's probably
causing the constipation and retransmissions. 802.11 was not designed
for streaming media and does it very badly. Hint: Got any NTSC UHF
TV xmitters handy?

>yes...this is a known problem...the customer wants reliable non-line-of-
>sight at distances that are at the outer edge of the ranges and rates
>advertised to the less than knowledgeable public.

In my never humble opinion, NLOS is pure hype and baloney. Even those
that have claimed Non-Line of Sight features are now changing the
acronym to Near Line of Sight to cover their posteriors. You can get
NLOS to work, but you can't make it reliable. It will work one day
and fail the next. It's incredibly sensitive to changeing
environmental conditions and always demonstrates lousy link
reliability.

>packet drop is not a
>problem...what is a problem is that run of the mill 802.11 devices don't
>let the end user fine tune retry or rate negotiation strategies.

Wrong. You can use one of the Linux based alternative firmware
implimentation and tweak the hell out of just about everything. With
the proper NDA and license, you can get source to the MAC layer and
really make a big mess. Don't think it's not being done. MERU
Networks got caught by Cisco tweaking holdoff timing values to make
their products look better when dealing with 802.11 interference.
<http://www.networkcomputing.com/channels/wireless/showArticle.jhtml?articleID=194400865>

>and dropping the MTU size is problematic in my current architecture
>because some of our 802.11 bridge hardware doesn't comply with the RFC
>regarding MTU negotiation.

MTU negotiates the MAXIMUM packet size, not the minimum. If you
fragment the hell out of the 802.3 ethernet packets, 802.11 will just
package them into a 1500 byte encapsulated packet. Of course, you can
shrink that with the fragmentation threshold. The do not fragment
flag only applys to larger packets, not smaller. If you force
everything to smaller packets, the MTU negotiation does nothing.

>The vendor states that as a pure ethernet
>bridge they don't have to. I see their point but it still pisses me off.

I agree with the vendor.

>tanks

I think you have a major system design problem here with all the worst
case conditions. My guess(tm) is you have a high bandwidth video
requirement, a real time response requirement, an uncontrolled and RF
polluted environment, and an unreasonable NLOS requirement. Take the
wireless out of the puzzle and see if it still works. If you're
lucky, and it does, find a data imparement tester to simulate the crap
you'll see with any wireless system. I use Dummynet:
http://info.iet.unipi.it/~luigi/ip_dummynet/
If the system works without wireless, then lets talk about what
wireless system is appropriate. I don't think it can be done with a
single radio system.

--
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