On Wed, 02 Nov 2005 12:22:11 GMT, John Navas
<spamfilter0@navasgroup.com> wrote:

>>May I humbly suggest you reconsider your opinion. Dialup external
>>modems so the same thing. If you set the serial port data rate to
>>19.2Kbits/sec, it will set the maximum connect speed to 14.4Kbits/sec.
>>To get 56K speeds, you need 57Kbits/sec or faster SIO speeds.

>Some, but not all.

Almost all that I've ever played with. Multitech, Supra, Hayes, USR,
etc. I used LOTS of these modems on Unix boxes for modem pools and
got to know their idiocyncracies and bad habits intimiately. Very old
photo of Cruzio with various Portmasters, USR modems, and lots of
cables:
http://www.LearnByDestroying.com/crud/cruzio.htm
The only ones that would run with a faster SIO rate than connect rate
out of the box were the early Telebit T2000 modems and that was later
fixed with a firmware update.

>>Admittedly, you can force the modem to connect at a higher speed, but
>>that will just eventually overflow the modem buffer.

>Error control (e.g., V.42) and TCP/IP actually handle that (congestion)
>gracefully.

True. You could set it up to run that way if you wanted. If the
initial connect was at 33.6 and the line conditions sucked, the modem
would slow down. However, if you setup the SIO for 9600 baud, you
could never go faster than V.32 at 9600 unless you forced the connect
speed to some specific rate. It was also specifically warned against
in the manuals to always keep the SIO rate faster than the connect
speeds. It could be done, but that was NOT normal or desireable
operation.

The same applies to USB 1.1 versus 2.0 for wireless. You can run an
802.11g wireless devices with a USB 1.1 port, but that is NOT normal
or desireable operation.

>>The same thing applies to USB which is just a fancy name for a serial
>>port with a weird connector. Max data rate for USB 1.1 is
>>12Mbits/sec. It makes no sense for the wireless to go any faster as
>>the driver buffer will overflow. So, they limit the speed to
>>11Mbits/sec.
>>
>>I would call this "defensive design"

>I would call this "dumb design" because it sacrifices speed in typical cases
>(bursty data) in order to simplify worst case operation.

Running it that way assumes that:
1. There's a hardware flow control mechanism that works. It can't be
in the PC's driver code because the flow problem is between the
wireless bridge side and the USB interface. That puts it inside the
USB device. Got RAM? Got money? How many seconds of bursty traffic
do you want to buffer?
2. CTS/RTS flow control is functional to prevent excessive
repetitious packets when the PC drops incoming packets because the USB
1.1 interface can't handle them. This will drop thruput somewhat.
3. The TCP layer can handle it. A basic wireless rule-of-thumb is to
NEVER transmit a packet if you know it will be dropped. Resends are
very bad for thruput. The 802.11g MAC layer will also reduce the
connection speed or the TCP layer will delay sending packets to deal
with the excessive NACK's. Anything to eliminate retransmissions.

The high speed bursty traffic does have one advantage. It clears the
air faster than a slower connection speed. This gives other devices
on the system more air time to transmit. However, it won't take too
many retransmissions to ruin any benifits offered by this improvement.

In my never humble opinion, it's much easier to just back off the
wireless connect speed and let the sending wireless device control the
traffic. Given the requirements for running at faster wireless speeds
versus just rate limiting the wireless connection, methinks this was
an acceptable compromise.

>>as I really would not want to
>>explain to customers why their USB wireless is eating packets due to
>>an inability for the USB/SIO interface to keep up with the wireless
>>data rate.

>Again, TCP/IP will actually handle that (congestion) gracefully. Otherwise,
>you could never interconnect a faster network to a slower network. See RFC
>2001 and 2581.

Sure, I use this for bandwidth management all the time. So, what's
the difference in design? Letting the wireless run as fast as
possible and dropping packets at the USB interface will eventually
result in the TCP layer noticing and slowing down sending packets. The
result would be something like 54Mbit/sec connection speeds, but the
thruput controlled by the slowest device (USB 1.1 or 12Mbits/sec). You
get all the problems of running at higher speeds (short range, low
noise immunity, interference potential), with no benifit in thruput
over 802.11b (11Mbits/sec). Same issue as the modem analogy. You
could run it this way, but there's no real benifit.

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