Re: What are the requirements for a PC to accept a wireless card?

[POSTED TO alt.internet.wireless - REPLY ON USENET PLEASE]

In <56rhm1hpadk5vpfo76h3jq6r4l92drq6bc@xxxxxxx> on Wed, 02 Nov 2005 09:14:07
-0800, Jeff Liebermann <jeffl@xxxxxxxxxxxxxxxxxxxxxx> wrote:

>On Wed, 02 Nov 2005 12:22:11 GMT, John Navas
><spamfilter0@xxxxxxxxxxxxxx> 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.

There were also USR, Hayes, and Multitech modems that would do that.

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

Sending flow control must be supported by the driver and the hardware, because
they can't just assume that they can spew data as fast as USB 1.1 can go,
since the wireless link may well have shifted down to a lower speed. Setting
the max speed of the wireless to 11 Mbps doesn't solve the problem of a speed
shift down to (say) 1 Mbps. I'd be willing to bet that receive flow control
exists as well, since there can be cases when the host isn't able to receive
data.

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

With all due respect, I think that's an exaggeration -- collisions are a fact
of life with 802.11, and a fairly significant percentage of lost packets is
normal. Regardless, TCP/IP will automatically throttle to whatever throughput
is possible.

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

We'll just to disagree on this one.

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

It's not just a matter of packet loss.

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

Again, I disagree. Letting each protocol optimize throughput will almost
certainly produce better results than crude throttling.

--
Best regards, HELP FOR CINGULAR GSM & SONY ERICSSON PHONES:
John Navas <http://navasgrp.home.att.net/#Cingular>
.

Relevant Pages

  • Re: How to speed up internet
    ... I just asked why a few posters are supplying 'bit' instead of 'byte' nos., ... for whenever you download something like an app., ... Modems are rated on the box as K-bit speeds, not K-byte, as it sounds faster ...
    (microsoft.public.windowsxp.help_and_support)
  • Re: chaging your @home IP address... could you take a bunch of them....probably... could you get som
    ... > the speed being an editable option for the modems. ... > remember a while back when faster transmission speeds were achieved via ... > "Computer games don't affect kids, I mean if Pacman affected us as kids, ...
    (Vuln-Dev)
  • Re: dial up modem
    ... There are three types of loosemodem driver. ... distribution and release, and don't work on other distributions, or ... at speeds up to 33.6 (which is better than the free/low-cost winmodem ... I still have several modems, ...
    (comp.os.linux.hardware)
  • Re: chaging your @home IP address... could you take a bunch of them....probably... could you get som
    ... the speed being an editable option for the modems. ... remember a while back when faster transmission speeds were achieved via ... As for current hacks for cable modems, there are a few that I have ... "Computer games don't affect kids, I mean if Pacman affected us as kids, ...
    (Vuln-Dev)
  • Round robin packet routing
    ... Cisco routers they will use a round robin method of sending out the ... packets through the four modems to us. ... that our Linux router will simply take the packets in from the four PPP ... interfacing and route them through our local network interface (provided ...
    (comp.os.linux.networking)