On Fri, 2005-07-08 at 00:58 -0500, steve ulrich wrote: > candidly, i have a bit of incredulity associated with these numbers > given that typically poor instrumentation available at the > application layer for measuring this type of stuff. if you're really > interested in the number of bits you're moving i wouldn't look too > the instrumentation available from ncftp. i take my instrumentation > right from the interfaces, but then that's just me. > > when using TCP based protocols for file transfer i haven't seen the > 1.2x10^n Mbyte numbers that mr. hallacy quotes. i've seen numbers > better than the numbers you've initially quoted, but i haven't seen > the numbers mr. hallacy quotes. I assume you agree with everything but the GE numbers, I can see why. In most applications (Internet based) you'll have a hard time ever saturating a single GE link due to MTU issues. On the local network (where I'm coming from) we're using 9k MTU's because the servers in question never need to talk to the 'net. This leads to much higher performance (the most I've ever squeezed out of a 1500 byte MTU over GE is around 450mbit/s). This is also UDP (NFS) pulling data off a striped dual 12-disk 3ware array. Data gets off the disk a lot faster than it will ever go over the wire (at least, in our application). > in fact, there's quite a body of > interesting work taking place in the research community that points > to further optimization in the L4 protocols to improve performance. > most of these enhancements focus on improving the windowing > mechanisms on TCP. for the most part TCP implementations haven't > kept pace with the improvements in network capacity and the ability > to clock data into larger payloads more efficiently. TCP has a > nagging thing about "fairness". Yes, but that's only per-stream. I'm talking about many connections.