calculating throughput and maximizing

the "wire" runs at 10Mbps. because you use a repeater, the interface is 1/2 duplex - ie. only 1 device attached to the repeater (which includes your PC, the Netgear port etc) can send at any one time. In practice it takes time to "hand over" the channel, so you lose some capacity in idle time between packets. Any useful transfer involves sending packets both ways between 2 devices, so you will get less than 10Mbps.

Good 1st step is to assume you get 40% to 80% thruput - that equates to 0.5 to 1 Mbyte / sec

Could

Any good reference on Ethernet should describe how the original 10 Mbps version works - it hasnt changed in more than 20 years. Try

First remember that it is 10 megabits/second, so about 1.2 megabytes/second. 1.0 megabytes/second is fairly close.

You need a large enough file to avoid startup overhead, and also the effect of file caching. Most ftp clients give timing values, but you can also time it with a clock or watch. 100 megabytes should take about 100s.

A fairly modern processor should come close to 1 megabyte/second, assuming the disk is fast enough. I have seen Windows systems that ran much slower than they should for no known reason with some software/hardware combinations, usually one direction only. If you can't get 0.5 megabytes/second with hardware less than a few years old, something is wrong.

-- glen

Hi All,

Thank you for responding to my query.

Glen,

Could you please elaborate on "You need a large enough file to avoid startup overhead, and also the effect of file caching. "

Do you mean the ethernet header?

Also going to probably go a bit off topic. Can you please give a brief description of the encapsulation process at each layer. Is that what it normally means when referring to overhead. I am trying to understand these concepts but having a hard time. Is there any book out there that will explain it in simple terms. Thanks

Indeed. If we assume a 1460 byte MSS, and an ACK for every other segment, since the link is half-duplex that would be

(2 * 1460) / (( 2 * 1518) + 60)

to get the ratio of data to data + headers which becomes

2920 / 3096

or 0.94 which means "light speed" for TCP would be 0.94 * 10 Megabits/s or 9.4 Megabits per second or 1.12 MB/s (M == 1048576). A little smaller if timestamps are enabled - the 1460's would become

1448s. And there would no doubt be some collisions, although their effect would be small - although speaking of collisions, there is the possibility of capture effect I suppose?

Or run a test that doesn't involve file transfer at all - eg

or the like.

rick jones

(snip)

Starting up the TCP connection takes some time. I am not sure how ftp does its timing, but for small files it can show speeds greater than ethernet speed. It might be that it doesn't start timing until the first packet is received, which may be all the data for a small file. There is also time for the file system to look up the file in the directory, which you don't want to include.

The header (ethernet, IP, TCP) should all be (approximately) proportional to the file size, closer for larger files.

Each layer, ethernet, IP, TCP, has information needed for that layer. Normally they are constant size for each packet, so a fixed fraction overhead.

-- glen

Hi Glen,

Thanks for your response. Is there any way to find out what the startup overhead might be for a particular transfer. In addition can you please elaborate on

"The header (ethernet, IP, TCP) should all be (approximately) proportional to the file size, closer for larger files"

Wouldn't the ethernet layer encapsulate the datagram from the ip layer and the ip layer encapsulate the datagram from the tcp layer. Hence if each layer adds its own header and the layer below encapsulates that than w> newbie123 wrote:

Hi Rick,

Thanks for your reply. Please excuse my ignorance but could you please expla> glen herrmannsfeldt wrote:

since the link is half-duplex that would be

hey newbie123 put you replies at the bottom. It makes it easier for everyone to read. as you start at the top and scroll down.

1518 is the MSS for Ethernet ... 1460 is the maxium payload size for TCP + 20 bytes TCP header + 20 bytes IP header + 14 bytes Ethernet header + 4 bytes Ethernet trailer = 1518.

BernieM

Though there are possible options in the TCP header, possible options in the IP header, and different possible encapsulation formats in the Ethernet header, so the 20/20/14 should be treated as "typical in most configurations and connections", not as invarients.

Also, newbie123 should note that there is a -minimum- packet size permitted in ethernet (usually given as 512 bits, but the mininum is larger for high speed links). Packets of minimum size turn out to be relatively common (e.g., TCP ACKs), so it turns out to be important to include the effect of the minimum in one's theoretical calculations.

TCP has a mechanism called "Slow Start" where it uses minimum bandwidth and then progressively more and more until the available capacity is full. Therefore, you need to move a large amount of data before you're seeing the true performance numbers.

Also, since you mentioned "mapping the drive" in an earlier message, I assume you're using Windows. Windows uses NetBIOS (aka SMB) for file sharing, and their implementation is widely recognized as the single worst-performing file sharing protocol on the planet, particularly if your system is using the UDP form instead of the TCP form.

So, do your tests by FTPing a huge file (100MB+) directly between machines. Any time difference between that and copying the file via "drive mapping" you need to blame on Windows, not Ethernet or TCP.

The headers and ACKs are marginal if you're moving large amounts of data via FTP, about 6% overhead all included (SMB has more). The real performance killer is the half-duplex. All of those TCP ACKs (for FTP, or SMB ACKs) mean there's traffic flowing both ways between machines. Half-duplex networks have pretty significant performance problems with high levels of bidirectional traffic due to collisions.

Why do you have 10Mb/s machines anyways? You can get decent 100Mb/s full-duplex Ethernet cards online for under $5/ea and solve most of your problems for less than the cost of lunch.

S

Disagree. When I was testing this several years ago, I had no problem getting close to 10 Mbps using ttcp on half duplex Ethernet.

*This* I certainly agree with.

Steinar Haug, Nethelp consulting, snipped-for-privacy@nethelp.no

Stephen Sprunk wrote: (snip)

The MS implementation of TCP is even worse in some situations. I haven't figured out the situation yet, but it is usually with the windows machine receiving from a non-windows machine. I have seen

1Mb/s on a 100Mb/s link with minimal other traffic. It sped up when I put in a 10Mb/s repeater to get the link down to 10Mb/s.

-- glen

That sounds like the classic "bad wiring that works at 10baseT but not

100BaseT" problem, or a duplex mismatch.

The problem with FTP reporting insanely fast transfer times pre-dates slow-start. Admittedly my DIMM memory is getting old (my age is measured in 6 bits :) but on the client, when sending, it could simply dump the entire file into the socket buffer, call close, and declare victory (give timing) even though data was still getting to the remote.

rick jones

IIRC 1518 is the maximum Ethernet frame size. I think that includes the CRC (Cyclic Redundancy Check - or is it called the FCS - Frame Check Sequence?). Well, the size for classic Ethernet anyway - before VLANs or Jumbo Frames and whatnot. From that one has to subtract the 4 byte CRC taking us to 1514 bytes, then the Ethernet header of 14 bytes taking us to 1500 bytes, which happens to be the MTU of IP over Ethernet. From this we subtract the (typically) 20 byte IPv4 header and the (again typically) 20 byte TCP header which leaves us with a TCP MSS of 1460 bytes. If the TCP "Timestamps" option is enabled as part of PAWS - Protection Against Wrapped Sequence numbers - RFC 1323) that adds 12 bytes to each TCP header so the effective MSS becomes

1448 bytes.

MSS - aka Maximum Segment Size (in this context) is something at the TCP layer (that TCP "packets" are most properly called "segments" is a hint as to that being the case :). MTU is at the IP/Link layer and maximum frame size is at the link-layer.

As for full vs half duplex, consider the implications for steady-state transmission between the two cases for data segments and the ACKs. Remember that TCP uses a "sliding window" and not "stop and go" and think about what might be able to be happening "in parallel." That will then explain why the formula I used for half-duplex is what it is.

rick jones

PS - and as others have suggested, please don't "top-post" :)

I don't believe so. Also, it didn't speed up all that much, maybe up to 2Mb/s. Transfer from Windows to the non-windows host was fast, though that doesn't completely rule out hardware.

I don't have access to the systems I saw that on, so I can't go back and prove/disprove it.

-- glen

(snip)

With the ethernet 1500 MTU, and with a sufficiently large file, almost all the packets will be full. With the assumption that they are full, the overhead is a constant fraction of the packet size, and so of the overall transfer size.

A 1 megabyte file is not too large these days, though if you are timing it by hand that probably isn't big enough.

-- glen