Sign in with
Sign up | Sign in
Your question

network speeds

Last response: in Wireless Networking
Share
Anonymous
a b F Wireless
October 20, 2004 2:42:06 AM

Archived from groups: alt.internet.wireless (More info?)

I am confused about speed on networks, at the moment I have an alcatel
broadband asdl connection at half meg.

I have bought a wireless adsl set up, now apart from the loss of speed when
sharing the internet, would I experience a loss in my connection, when I
connect up alone via wireless, and alternatively connecting to my wireless
modem via a Ethernet card.

More about : network speeds

Anonymous
a b F Wireless
October 20, 2004 2:42:07 AM

Archived from groups: alt.internet.wireless (More info?)

Im not 100% sure if I understand your question but I will try to answer.

If 2 are sharing the wireless network then you will be sharing bandwidth
wirelessly.

If one is wireless and the other is wired you will be sharing the bandwidth
in a mixed enviroment.

Or maybe I need more info!


"B A T M A N" <batman@clara.co.uk> wrote in message
news:1098222125.13705.0@eunomia.uk.clara.net...
> I am confused about speed on networks, at the moment I have an alcatel
> broadband asdl connection at half meg.
>
> I have bought a wireless adsl set up, now apart from the loss of speed
when
> sharing the internet, would I experience a loss in my connection, when I
> connect up alone via wireless, and alternatively connecting to my wireless
> modem via a Ethernet card.
>
>
>
Anonymous
a b F Wireless
October 20, 2004 3:16:31 AM

Archived from groups: alt.internet.wireless (More info?)

Question is really about one user on a networked set up, is there a speed
difference between the following.
1. Straight forward broadband set up
2. Internet access via wireless
3. Internet access via ethernet connection.

1 and 2 would be on a net work, but the speed question is just while I am
using the network, nobody else.


"AirHead" <campbell@alliancecable.net> wrote in message
> Im not 100% sure if I understand your question but I will try to answer.
> If 2 are sharing the wireless network then you will be sharing bandwidth
> wirelessly.
> If one is wireless and the other is wired you will be sharing the
bandwidth
> in a mixed enviroment.
> Or maybe I need more info!
>
>
> "B A T M A N" <batman@clara.co.uk> wrote
> > I am confused about speed on networks, at the moment I have an alcatel
> > broadband asdl connection at half meg.
> >
> > I have bought a wireless adsl set up, now apart from the loss of speed
> when sharing the internet, would I experience a loss in my connection,
when I
> > connect up alone via wireless, and alternatively connecting to my
wireless
> > modem via a Ethernet card.
> >
Related resources
Anonymous
a b F Wireless
October 20, 2004 3:16:32 AM

Archived from groups: alt.internet.wireless (More info?)

>> "B A T M A N" <batman@clara.co.uk> wrote
>> > I am confused about speed on networks, at the moment I have
>> > an alcatel broadband asdl connection at half meg.
>> >
>> > I have bought a wireless adsl set up, now apart from the loss
>> > of speed
>> when sharing the internet, would I experience a loss in my
>> connection,
> when I
>> > connect up alone via wireless, and alternatively connecting
>> > to my
> wireless
>> > modem via a Ethernet card.
>> >
>

The speed of access to the Internet that you experience depends on
the slowest link in the chain of connection.

ADSL 'half meg' means 500Kbits/sec.

Wireless connection will be nominally 11Mbits/sec (realistically
5Mbits/sec) or 55Mbits/sec (...25Mbits/sec) depending on whether it
is 802.11b or 802.11g, respectively.

Ethernet (wired) will be nominally 100Mbits/sec (...75Mbits/sec).

So the slowest link in the various chains is ADSL, by an order of
magnitude. Which means they should all give the same perceived
speed of access to the Internet.
Anonymous
a b F Wireless
October 20, 2004 4:02:06 AM

Archived from groups: alt.internet.wireless (More info?)

"Frank le Spikkin" <zaq@invalid.jp> wrote in message
news:Xns9587F2F7EA11AFlSxxx@130.133.1.4...
> >> "B A T M A N" <batman@clara.co.uk> wrote

> I am confused about speed on networks, at the moment I have an alcatel
> broadband asdl connection at half meg.
>> I have bought a wireless adsl set up, now apart from the loss of speed
when sharing the internet, would I experience a loss in my connection, when
I
> connect up alone via wireless, and alternatively connecting to my wireless
> modem via a Ethernet card.

<snip>

> The speed of access to the Internet that you experience depends on
> the slowest link in the chain of connection.
>
> ADSL 'half meg' means 500Kbits/sec.
>
> Wireless connection will be nominally 11Mbits/sec (realistically
> 5Mbits/sec) or 55Mbits/sec (...25Mbits/sec) depending on whether it
> is 802.11b or 802.11g, respectively.
>
> Ethernet (wired) will be nominally 100Mbits/sec (...75Mbits/sec).
>
> So the slowest link in the various chains is ADSL, by an order of
> magnitude. Which means they should all give the same perceived
> speed of access to the Internet.

Thank you, very well explained and taken in. :-))
Anonymous
a b F Wireless
October 20, 2004 5:28:12 AM

Archived from groups: alt.internet.wireless (More info?)

In article <Xns9587F2F7EA11AFlSxxx@130.133.1.4>,
Frank le Spikkin <zaq@invalid.jp> wrote:
:The speed of access to the Internet that you experience depends on
:the slowest link in the chain of connection.

That is -almost- true, but turns out to not -quite- be true.

The maximum *bandwidth* that one can get is no higher than the data
payload-carrying rate of the slowest link in the chain.

If the data carrying protocol uses acknowledgements for flow
control or loss detection, then each step that requires those
acknowledgements is also limited by the round-trip time to the
generator of data who wants to be acknowledged. For example, if
you are using a gigabit channel and need acknowledgement of each
packet individually before sending the next packet, then the waiting
time might be very small compared to the time to send a full packet
if the devices are very close together, but if the receiving device
is on the moon, the round trip time to get the packet is going to
ruin your bandwidth in an individual ACK scheme.

TCP uses a windowing scheme that allows the sender to send a series
of data packets in succession before having to see an acknowlegement.
If the time required to transmit a full window (maximum amount of data)
is more than the time required to get the acknowledgement back for the
first packet in the series, then one might be able to keep sending
indefinitely without ever having more than the maximum amount of data
in transmission at once. If, though, the time required to transmit
a full window is less than the time to get an acknowledgement back
for the first packet, then the transmitter must wait, with nothing
going out, until the acknowledgement arrives. The maximum throughput
then becomes limited by the ratio of dead transmission time to
live transmission time. If you think of the moon again, you can
see that one might be able to send data on a link very quickly and
yet experience very low data transfer speeds. If the transmission
time to the moon is 1 second, and the data rate is 1 gigabit per
second, then the window must allow one to have at least a
gigabit in transit in order to get the full data rate.

In any case, even if the windows and protocols are such that data is
able to be kept streaming, the speed that a human *experiences* depends
mostly on the latency of response, not on the rate of transmission. If
it takes 3 seconds for a remote computer to echo a typed character,
then the human -experiences- the remote computer as being very slow.
The link and remote computer might be very fast and well able to handle
input as fast as a human can possibly type, but other than trained
touch-typists who keep their eyes on the data to type instead of on the
screen, the *experience* is determined by when the time to respond to
each character, not by the -rate- at which response can be made.
What a human -experiences- can be very different than the physics
of a situation.
--
Ceci, ce n'est pas une idée.
Anonymous
a b F Wireless
October 20, 2004 5:28:13 AM

Archived from groups: alt.internet.wireless (More info?)

On 20 Oct 2004 01:28:12 GMT, roberson@ibd.nrc-cnrc.gc.ca (Walter
Roberson) wrote:

>TCP uses a windowing scheme that allows the sender to send a series
>of data packets in succession before having to see an acknowlegement.
>If the time required to transmit a full window (maximum amount of data)
>is more than the time required to get the acknowledgement back for the
>first packet in the series, then one might be able to keep sending
>indefinitely without ever having more than the maximum amount of data
>in transmission at once. If, though, the time required to transmit
>a full window is less than the time to get an acknowledgement back
>for the first packet, then the transmitter must wait, with nothing
>going out, until the acknowledgement arrives. The maximum throughput
>then becomes limited by the ratio of dead transmission time to
>live transmission time.

Lets see if I can convert that into English. Conventional TCP allows
one to sent 64KBytes before requireing an acknowledgement. A remote
web server will shovel 64KBytes into your computah, and then just sit
there until it get some acknowledgements from your machine[1].
Therefore the upper limit is:
64KBytes / latency = bandwidth
For this system, it's:
64KBytes / latency = 512Kbits/sec
or
latency = 64/512 = 0.125 sec = 125 msec
Therefore, if you are downloading from a server that has a total
latency (round trip) of 125msec or less, you will get your full
512Kbits/sec download speed. However, if the latency is more than
125 msec, then the download speed will start to decrease as the server
stalls waiting for ACK's.

This is never a problem with indoor wireless links as the latency is
typically 2-3 msec. The typical ADSL connection 20-40msec to the
ISP's gateway is also not a problem. However, as the data goes
through crowded IXP's, latency could increase somewhat. At 125 msec,
the connection would be deemed broken if it had such a high latency.
It's a big problem with satellite internet and high speed fiber
optics.

There are various fixes for this problem. The most common is RFC-1323
"TCP Extensions for High Performance." This allows for window sizes
larger than 64KBytes.

[1] This is why the return path bandwidth is so important to proper
performance. You can have lots and lots of download bandwidth, but if
your upstream bandwidth is clogged with traffic, your download
performance will suffer. For example, I have 1500/256kbits ADSL
service. If I'm playing server, and someone is using ALL of my
256Kbits/sec upload bandwidth to grab files of my machine, then I
can't download very fast, even though I have 1500Kbits/sec of download
bandwidth available, because my ACK's are getting stalled by the
outgoing traffic.


--
Jeff Liebermann jeffl@comix.santa-cruz.ca.us
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 AE6KS 831-336-2558
Anonymous
a b F Wireless
October 20, 2004 11:35:13 AM

Archived from groups: alt.internet.wireless (More info?)

In article <63obn0pjg1vd5uqifefav4bjeca9gjkm63@4ax.com>,
Jeff Liebermann <jeffl@comix.santa-cruz.ca.us> wrote:
:o n 20 Oct 2004 01:28:12 GMT, roberson@ibd.nrc-cnrc.gc.ca (Walter
:Roberson) wrote:

:>If, though, the time required to transmit
:>a full window is less than the time to get an acknowledgement back
:>for the first packet, then the transmitter must wait, with nothing
:>going out, until the acknowledgement arrives. The maximum throughput
:>then becomes limited by the ratio of dead transmission time to
:>live transmission time.

:Lets see if I can convert that into English.

You didn't convert it into English, you converted my English
into mathematics :) 

:Therefore the upper limit is:
: 64KBytes / latency = bandwidth

Tsk, that formulae is wrong. You can't get infinite bandwidth
out of a connection that has zero latency (i.e., the connection
path is length zero.) You can't modulate particle state faster
than the speed of light over the maximum diameter of the particle.
The maximum diameter of the particle will, in turn, be limited
by the amount of energy you have available to put into the system
to do apply work to the particle. If you are (say) sending the
orbital electrons on an atom of copper out to, oh, 2 meters,
then you are probably going to run into substantial problems
with quantum interference with other nearby particles.

Your formulae needs to be inverted, to something like,

tolerable latency = Limit {x -> bandwidth} 64 KBytes / x

The limit as the bandwidth approaches zero -is- sensibly infinite
latency. The formulae you stated is unstable and physically incorrect
as the latency approaches zero.


:For this system, it's:
: 64KBytes / latency = 512Kbits/sec
:o r
: latency = 64/512 = 0.125 sec = 125 msec

No, you missed a bytes to bits conversion. The actual tolerable latency
is 8 times what you state.

:This is never a problem with indoor wireless links as the latency is
:typically 2-3 msec.

At 2 ms latency, the maximum sustainable payload bandwidth with
a 64 Kbyte window is only 32.768 megabits per second. 802.11g nominally
is 54 megabits per second, but a lot of that is used up in overhead,
giving an payload throughput that -approaches- 32 megabits per second.
I do not know what the current record is... a bit more than 26 was
the last solid figure I saw.

At 3 ms latency, the maximum sustainable payload bandwidth with a 64
Kbyte window is only 21.845 megabits per second, which is less than
measured 802.11g payload transfer rates. So if you do have a 3 ms
latency in your indoor wireless system, then you cannot get the maximum
TCP throughput out of your system if you are using the standard TCP
maximum 64 Kb window size (but you could if you were using the
window-size extensions.)
--
I predict that you will not trust this prediction.
Anonymous
a b F Wireless
October 20, 2004 2:11:49 PM

Archived from groups: alt.internet.wireless (More info?)

On 20 Oct 2004 07:35:13 GMT, roberson@ibd.nrc-cnrc.gc.ca (Walter
Roberson) wrote:

>You didn't convert it into English, you converted my English
>into mathematics :) 

Guilty (and sloppy) as charged.

>:Therefore the upper limit is:
>: 64KBytes / latency = bandwidth

>Tsk, that formulae is wrong. You can't get infinite bandwidth
>out of a connection that has zero latency (i.e., the connection
>path is length zero.)

That's not the formula for determining absolute bandwidth. It's for
calculating the upper limit for latency given a fixed bandwidth and
window size (RWIN). Or, it can be used to determine the maximum
bandwidth available for a given latency and window size (RWIN).

>You can't modulate particle state faster
>than the speed of light over the maximum diameter of the particle.
>The maximum diameter of the particle will, in turn, be limited
>by the amount of energy you have available to put into the system
>to do apply work to the particle. If you are (say) sending the
>orbital electrons on an atom of copper out to, oh, 2 meters,
>then you are probably going to run into substantial problems
>with quantum interference with other nearby particles.

As long as the times involved are non-relativistic, and you stay out
of multi-dimensional results (i.e. imaginary bandwidths), there will
be no quantum effects. I realize that it is possible to send messages
faster than the speed-o-light, as I have received replies to my email
before I sent them.

Incidentally, the speed of electricity is quite different from the
speed of an individual electron moving in a copper wire. Electricity
moves at considerably less than the speed-o-light, while electron
mobility is amazingly slow. I don't wanna look up the numbers.

>Your formulae needs to be inverted, to something like,
> tolerable latency = Limit {x -> bandwidth} 64 KBytes / x

Yech. How about something simpler like:
max_latency = ( Window Size ) / max_bandwidth
By specifying the maximum latency instead of the absolute latency, the
concept of using the formula to calculate a minimum latency is
eliminated.

>The limit as the bandwidth approaches zero -is- sensibly infinite
>latency. The formulae you stated is unstable and physically incorrect
>as the latency approaches zero.

The formula holds for all non-relativistic speeds and bandwidth but
will fail a reciprocity test because it was intended only to deal with
maxima, not minima. If that's unacceptable, perhaps simply limiting
the discussion to practical TCP/IP applications and leave out the
complications?

>:For this system, it's:
>: 64KBytes / latency = 512Kbits/sec
>:o r
>: latency = 64/512 = 0.125 sec = 125 msec

>No, you missed a bytes to bits conversion. The actual tolerable latency
>is 8 times what you state.

Oops, argh, grumble, etc. I just hate it when that happens. Thanks.
64KBytes / max_latency = 512Kbits/sec
or
max_latency = 8 * 64 / 512 = 1 sec

>:This is never a problem with indoor wireless links as the latency is
>:typically 2-3 msec.

>At 2 ms latency, the maximum sustainable payload bandwidth with
>a 64 Kbyte window is only 32.768 megabits per second. 802.11g nominally
>is 54 megabits per second, but a lot of that is used up in overhead,
>giving an payload throughput that -approaches- 32 megabits per second.
>I do not know what the current record is... a bit more than 26 was
>the last solid figure I saw.

The best I've done on the bench is about 36MBits/sec using Atheros
Super-G bondage at about 6ft range. Performance drops to about
25Mbits/sec in any kind of realistic indoor arrangement. I haven't
found a good way to measure latency with nanosecond resolution (or
repeatability) yet. I've used an oscilloscope and a logic analyzer to
sorta measure latencies at the ethernet cable between the test
computah and the access point of <1msec. However, that doesn't
include any of the delays in the ethernet card (PAD) or the IP
protocol stack. Using fping, 3msec is about what I get when I turn on
WEP128 and apply some router rules that require payload sniffing (i.e.
H.323) through a client and access point link.

See the graphs:
http://www.tomsnetworking.com/Sections-article59-page11...

Incidentally, on fun part of the ping problem was that some ping
implimentations (i.e. SCO OSR5) do a DNS lookup on EVERY ping packet.
http://www.aplawrence.com/Bofcusm/1625.html
That doesn't make much difference with "typical" dialup or broadband
connections, but drove me nuts while testing wireless latency.

>At 3 ms latency, the maximum sustainable payload bandwidth with a 64
>Kbyte window is only 21.845 megabits per second, which is less than
>measured 802.11g payload transfer rates. So if you do have a 3 ms
>latency in your indoor wireless system, then you cannot get the maximum
>TCP throughput out of your system if you are using the standard TCP
>maximum 64 Kb window size (but you could if you were using the
>window-size extensions.)

Yep. Incidentally, Windoze 2000 and XP support RFC-1323 large window
sizes as do many web servers and internet routers, which largely
reduces the problems. Satellite internet has additional tweaks to
improve performance in the presence of high latency. 802.11 is
bridging, not routeing and therefore is not directly affected by an IP
timing problem.

What I mean't by WLAN's being unaffected was in reference to the
512Kbit/sec DSL connection. Since the thruput is limited by the
narrowest bandwidth device, in this case, with the 0.5Mbit/sec DSL
line, a 25-35Mbit/sec thruput limit on the wireless end will not have
any effect.


--
Jeff Liebermann jeffl@comix.santa-cruz.ca.us
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 AE6KS 831-336-2558
Anonymous
a b F Wireless
October 20, 2004 4:47:09 PM

Archived from groups: alt.internet.wireless (More info?)

Wow. My head hurts. Just from reading the thread below.

--
Bob Alston

bobalston9 AT aol DOT com
"Jeff Liebermann" <jeffl@comix.santa-cruz.ca.us> wrote in message
news:902dn0t0p8b0q13u75n6prvngekh2uko16@4ax.com...
> On 20 Oct 2004 07:35:13 GMT, roberson@ibd.nrc-cnrc.gc.ca (Walter
> Roberson) wrote:
>
>>You didn't convert it into English, you converted my English
>>into mathematics :) 
>
> Guilty (and sloppy) as charged.
>
>>:Therefore the upper limit is:
>>: 64KBytes / latency = bandwidth
>
>>Tsk, that formulae is wrong. You can't get infinite bandwidth
>>out of a connection that has zero latency (i.e., the connection
>>path is length zero.)
>
> That's not the formula for determining absolute bandwidth. It's for
> calculating the upper limit for latency given a fixed bandwidth and
> window size (RWIN). Or, it can be used to determine the maximum
> bandwidth available for a given latency and window size (RWIN).
>
>>You can't modulate particle state faster
>>than the speed of light over the maximum diameter of the particle.
>>The maximum diameter of the particle will, in turn, be limited
>>by the amount of energy you have available to put into the system
>>to do apply work to the particle. If you are (say) sending the
>>orbital electrons on an atom of copper out to, oh, 2 meters,
>>then you are probably going to run into substantial problems
>>with quantum interference with other nearby particles.
>
> As long as the times involved are non-relativistic, and you stay out
> of multi-dimensional results (i.e. imaginary bandwidths), there will
> be no quantum effects. I realize that it is possible to send messages
> faster than the speed-o-light, as I have received replies to my email
> before I sent them.
>
> Incidentally, the speed of electricity is quite different from the
> speed of an individual electron moving in a copper wire. Electricity
> moves at considerably less than the speed-o-light, while electron
> mobility is amazingly slow. I don't wanna look up the numbers.
>
>>Your formulae needs to be inverted, to something like,
>> tolerable latency = Limit {x -> bandwidth} 64 KBytes / x
>
> Yech. How about something simpler like:
> max_latency = ( Window Size ) / max_bandwidth
> By specifying the maximum latency instead of the absolute latency, the
> concept of using the formula to calculate a minimum latency is
> eliminated.
>
>>The limit as the bandwidth approaches zero -is- sensibly infinite
>>latency. The formulae you stated is unstable and physically incorrect
>>as the latency approaches zero.
>
> The formula holds for all non-relativistic speeds and bandwidth but
> will fail a reciprocity test because it was intended only to deal with
> maxima, not minima. If that's unacceptable, perhaps simply limiting
> the discussion to practical TCP/IP applications and leave out the
> complications?
>
>>:For this system, it's:
>>: 64KBytes / latency = 512Kbits/sec
>>:o r
>>: latency = 64/512 = 0.125 sec = 125 msec
>
>>No, you missed a bytes to bits conversion. The actual tolerable latency
>>is 8 times what you state.
>
> Oops, argh, grumble, etc. I just hate it when that happens. Thanks.
> 64KBytes / max_latency = 512Kbits/sec
> or
> max_latency = 8 * 64 / 512 = 1 sec
>
>>:This is never a problem with indoor wireless links as the latency is
>>:typically 2-3 msec.
>
>>At 2 ms latency, the maximum sustainable payload bandwidth with
>>a 64 Kbyte window is only 32.768 megabits per second. 802.11g nominally
>>is 54 megabits per second, but a lot of that is used up in overhead,
>>giving an payload throughput that -approaches- 32 megabits per second.
>>I do not know what the current record is... a bit more than 26 was
>>the last solid figure I saw.
>
> The best I've done on the bench is about 36MBits/sec using Atheros
> Super-G bondage at about 6ft range. Performance drops to about
> 25Mbits/sec in any kind of realistic indoor arrangement. I haven't
> found a good way to measure latency with nanosecond resolution (or
> repeatability) yet. I've used an oscilloscope and a logic analyzer to
> sorta measure latencies at the ethernet cable between the test
> computah and the access point of <1msec. However, that doesn't
> include any of the delays in the ethernet card (PAD) or the IP
> protocol stack. Using fping, 3msec is about what I get when I turn on
> WEP128 and apply some router rules that require payload sniffing (i.e.
> H.323) through a client and access point link.
>
> See the graphs:
> http://www.tomsnetworking.com/Sections-article59-page11...
>
> Incidentally, on fun part of the ping problem was that some ping
> implimentations (i.e. SCO OSR5) do a DNS lookup on EVERY ping packet.
> http://www.aplawrence.com/Bofcusm/1625.html
> That doesn't make much difference with "typical" dialup or broadband
> connections, but drove me nuts while testing wireless latency.
>
>>At 3 ms latency, the maximum sustainable payload bandwidth with a 64
>>Kbyte window is only 21.845 megabits per second, which is less than
>>measured 802.11g payload transfer rates. So if you do have a 3 ms
>>latency in your indoor wireless system, then you cannot get the maximum
>>TCP throughput out of your system if you are using the standard TCP
>>maximum 64 Kb window size (but you could if you were using the
>>window-size extensions.)
>
> Yep. Incidentally, Windoze 2000 and XP support RFC-1323 large window
> sizes as do many web servers and internet routers, which largely
> reduces the problems. Satellite internet has additional tweaks to
> improve performance in the presence of high latency. 802.11 is
> bridging, not routeing and therefore is not directly affected by an IP
> timing problem.
>
> What I mean't by WLAN's being unaffected was in reference to the
> 512Kbit/sec DSL connection. Since the thruput is limited by the
> narrowest bandwidth device, in this case, with the 0.5Mbit/sec DSL
> line, a 25-35Mbit/sec thruput limit on the wireless end will not have
> any effect.
>
>
> --
> Jeff Liebermann jeffl@comix.santa-cruz.ca.us
> 150 Felker St #D http://www.LearnByDestroying.com
> Santa Cruz CA 95060 AE6KS 831-336-2558


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.779 / Virus Database: 526 - Release Date: 10/19/2004
Anonymous
a b F Wireless
October 20, 2004 4:47:10 PM

Archived from groups: alt.internet.wireless (More info?)

On Wed, 20 Oct 2004 12:47:09 -0500, "Bob Alston"
<bobalston9NOSPAM@aol.com> wrote:

>Wow. My head hurts. Just from reading the thread below.
(...)

You should read some of the traffic in the more technical mailing
lists. That makes *MY* head hurt.

The nice thing about mathematics and formulas is that they can explain
quite a bit about phenomenon without potentially inexact descriptive
prose. The bad thing is that it instantly alienates much of the
potential audience. When I give one of my song-n-dance presentations,
I figure that the first equation is good for losing half the audience.
Each additional equation will lose half of those not asleep. More
equations will eventually lead to terminal somnolence or impromptu
rioting. In this case, I figured a simple equation couldn't possibly
hurt. I was wrong.

Take two aspirin and avoid contact with any equations for a while.
You should recover shortly.



--
Jeff Liebermann jeffl@comix.santa-cruz.ca.us
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 AE6KS 831-336-2558
Anonymous
a b F Wireless
October 20, 2004 10:51:44 PM

Archived from groups: alt.internet.wireless (More info?)

In article <902dn0t0p8b0q13u75n6prvngekh2uko16@4ax.com>,
Jeff Liebermann <jeffl@comix.santa-cruz.ca.us> wrote:
|On 20 Oct 2004 07:35:13 GMT, roberson@ibd.nrc-cnrc.gc.ca (Walter
|Roberson) wrote:

|>At 2 ms latency, the maximum sustainable payload bandwidth with
|>a 64 Kbyte window is only 32.768 megabits per second. 802.11g nominally
|>is 54 megabits per second, but a lot of that is used up in overhead,
|>giving an payload throughput that -approaches- 32 megabits per second.
|>I do not know what the current record is... a bit more than 26 was
|>the last solid figure I saw.

|The best I've done on the bench is about 36MBits/sec using Atheros
|Super-G bondage at about 6ft range. Performance drops to about
|25Mbits/sec in any kind of realistic indoor arrangement.

Super-G bonds two 802.11g channels together as I recall. That
would mean that the raw bandwidth would be 108 Mbits/sec, and
that in this best-case scenario, that doubling the raw bandwidth only
gave you about 38% more effective throughput? Were you measuring
throughput with UDP or TCP? The ~26 figure I mentioned was my
recollection of the results of a UDP throughput test on a
non-bonded 802.11g device, and it would have been tomsnetworking that
I saw the result on. {As I am sure you know, but for the information
of anyone else who might be reading this thread: UDP does NOT
use transmission windows like TCP does, so UDP only has to stop
transmitting when another device wants to use the channel, whereas
TCP may have to stop transmitting if it has not received an acknowledgement
that the previous data was received.}
--
Whose posting was this .signature Google'd from?
Anonymous
a b F Wireless
October 21, 2004 3:57:36 AM

Archived from groups: alt.internet.wireless (More info?)

On 20 Oct 2004 18:51:44 GMT, roberson@ibd.nrc-cnrc.gc.ca (Walter
Roberson) wrote:

>In article <902dn0t0p8b0q13u75n6prvngekh2uko16@4ax.com>,
>Jeff Liebermann <jeffl@comix.santa-cruz.ca.us> wrote:
>|On 20 Oct 2004 07:35:13 GMT, roberson@ibd.nrc-cnrc.gc.ca (Walter
>|Roberson) wrote:
>
>|>At 2 ms latency, the maximum sustainable payload bandwidth with
>|>a 64 Kbyte window is only 32.768 megabits per second. 802.11g nominally
>|>is 54 megabits per second, but a lot of that is used up in overhead,
>|>giving an payload throughput that -approaches- 32 megabits per second.
>|>I do not know what the current record is... a bit more than 26 was
>|>the last solid figure I saw.
>
>|The best I've done on the bench is about 36MBits/sec using Atheros
>|Super-G bondage at about 6ft range. Performance drops to about
>|25Mbits/sec in any kind of realistic indoor arrangement.

>Super-G bonds two 802.11g channels together as I recall.

Yep. It uses the effective bandwidth of two channels, but does it by
hogging the small guard band between channels 1, 6, and 11 with a
bunch of slop into the spectra occupied by channels 1 and 11. See:
http://www.tomsnetworking.com/Sections-article59-page5....
It should be possible to still use channels 1 and 11 in the presence
of Super-G but reports show substantial interference to ordinary
802.11g on 1 and 11.

Broadcom's Afterburner uses only one channel. Well, one 26MHz wide
channel. I couldn't find much on how it works other than they tinker
with the 802.11 protocol to remove as much overhead as possible.

Atheros Super-G is faster than Broadcom's Afterburner according to Tim
Higgins:
http://www.tomsnetworking.com/Reviews-142-ProdID-WRT54G...
However, I hit the limit at 36Mbits/sec (UDP) for both, so something
else may have been slowing performance.

I haven't played with GlobeSpan Virata Nitro XM which is suppose to
actually deliver 70Mbits/sec (UDP only) or Prism GT chipset. The
problem with XM is that bulk of the performance comes from data
compression.

>That
>would mean that the raw bandwidth would be 108 Mbits/sec, and
>that in this best-case scenario, that doubling the raw bandwidth only
>gave you about 38% more effective throughput?

Worse than that. I got about 25-30Mbits/sec with ordinary 802.11g and
maxed out at 36Mbits/sec with both Super-G and Afterburner. The
numbers are consistent with what I read on Tim Higgins' site for
Afterburner, but not for Super-G. I may have screwed up here.

One would think that bonding two channels should give exactly twice
the thruput of one channel, but that's not what Tom's Networking and I
measured. There are still some inefficiencies in the bonded system or
some problems with my arrangement. I have some guesses, but I'd
rather not speculate when I'm half asleep.

Also, when I replaced the wireless link with a direct CAT5 connection,
I was able to measure 80Mbits/sec which is almost wire speed for
100baseTX-HDX. I had to force the switches to use HDX instead of FDX
because none of the wireless hardware I has would do FDX.

>Were you measuring
>throughput with UDP or TCP?

UDP, of course. No ACK's to slow things down. A pair of 2.4Ghz P4
boxes with 10K rpm SCSI drives running SUSE something. Cat a file to
a named pipe that ends in an IP socket using netcat -u. The actual
performance measurement was made with a pair of 3Scum 3300 managed
10/100 ethernet switches, using SNMP to extract traffic statistics. I
could have done it with one, but we had two to play with, so why not?
Two were also handy for using a scope and logic analyzer to measure
latency. The nice part of this arrangement is that it largely takes
the computahs out of the picture.

>The ~26 figure I mentioned was my
>recollection of the results of a UDP throughput test on a
>non-bonded 802.11g device, and it would have been tomsnetworking that
>I saw the result on. {As I am sure you know, but for the information
>of anyone else who might be reading this thread: UDP does NOT
>use transmission windows like TCP does, so UDP only has to stop
>transmitting when another device wants to use the channel, whereas
>TCP may have to stop transmitting if it has not received an acknowledgement
>that the previous data was received.}

Yep. 25-30 Mbits/sec is what I got with ordinary 802.11g using UDP.


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