RE: [Nolug] LAN speed confusion

Hi Jimmy.

>>> In practice, the behavior of the TCP protocol will prevent a link from
being utilized more than 75% - 80%, at least for any one TCP
connection, without specialized tuning at the endpoints

I thought that due to the streaming nature of the FTP protocol you could get
90-95%. Not having to wait for the ACK before sending another packet makes
a lot of difference, doesn't it?

Regards,

John

    John Souvestre - New Orleans LA - (504) 454-0899

-----Original Message-----
From: owner-nolug@stoney.kellynet.org
[mailto:owner-nolug@stoney.kellynet.org] On Behalf Of Jimmy Hess
Sent: Friday, July 13, 2012 8:46 pm
To: nolug@nolug.org
Subject: Re: [Nolug] LAN speed confusion

Gee that's confusing and ambiguous. the data rate of communications
lines are usually measured in bits per second. In other words if
you say "4 megabytes per second" you really mean "4x8 Mbits/s"
instead of "4 MBytes/s", and for the love of $deity, don't quote
a data rate as "4 Megs".

Divide the half duplex and full duplex speeds originally stated in half, and
they would be correct. Half-duplex = 50 Mbits/s (6.2
transfer rate) each direction, when both directions are at
theoretical (impossible) 100% utilization; or 12.5 Mbits/s max in one
direction when the other direction is 0% utilized; however, that's
impossible in practice with the TCP protocol, because all connections
require bidirectional traffic (even if just acknowledgements in one
direction).

With a full duplex connection, one transmit direction does not inhibit the
other _except_ when there is congestion or significant
delay; if upstream is 100% utilized, or latency/loss increased due
to load, the downstream receive rate for TCP will drop, because the
congested upstream will interfere with the delivery of acknowledgement
packets.

In practice, the behavior of the TCP protocol will prevent a link from
being utilized more than 75% - 80%, at least for any one TCP
connection, without specialized tuning at the endpoints; and the
problem gets even bigger with higher speed links, such as 1 gigabit plus.

You may consider that upgrading a link speed beyond normal WAN speeds
will improve the aggregate capacity of the site's networking, and
the aggregate performance of the TCP connections in the whole, but if
the latency characteristics between endpoints are "WAN-like"; it
will be unreasonable to expect that the TCP protocol, with its
congestion handling, will give you anything close to the whole link speed
for any one connection.

If you want performance look at UFTP or the Micro-Transport Protocol
used by BitTorrent
as possible alternative transfer methodologies.. because uTP's
purpose for existence is addressing congestion control issues that lead to
poor performance of bulk file transfer operations using the TCP protocol.
http://en.wikipedia.org/wiki/Micro_Transport_Protocol

P.S. different capitalization just doesn't work for expressing or
emphasizing an importance difference between two units, because people
rarely follow any convention in practice, people quote values as "mbps"
when they are talking about MBytes/S, and "MBps" when
they are quoting a number measured in Mbits/s, more often than
they use those correctly.

You know what that looks like to me:

on 7/13/12, chris jones <techmaster@gmail.com> wrote:
> it's because your logic is off. 100mbps is roughly 12mbps. 100mbps
> ethernet maxes out at 12mbps in any one direction. full duplex means
> you can have simultaneous 2way communication. in theory this could
> double your speed, assuming both ends are sending each other equal
> amounts of data. but this is rarely the case. it usually involves a
> computer reading or writing data to/from another computer. the remote
> computer usually has no interest in the client. it's only concerned
> with receiving data and storing it, or presenting that data when it is
> requested. so all you're going to see is 12mbps. i also doubt your
> internet is 25mbps. it's probably 25mbps, which is roughly 4mbps.
___________________
Nolug mailing list
nolug@nolug.org

___________________
Nolug mailing list
nolug@nolug.org
Received on 07/14/12