Slashdot Mirror

True... the phrase I was searching for was 'protocol overhead'. I did a quick google and found the following:

http://sd.wareonearth.com/~phil/net/overhead/

Since we are talking ethernet, here are the numbers:
Ethernet: 1500/(38+1500) = 97.5293 %
TCP: (1500-52)/(38+1500) = 94.1482 %

Different hashes are for different purposes.

No argument there.

The CRC class of hash functions actually makes certain statistical guarantees for the longest run of possible errant bytes in source data and are extremely faster, making them far more suitable for file integrity checks.

CRC is great for packet-sized input, but not so great over larger chunks of data; also, the way its design targets burst errors means that widely separated point errors aren't as effectively caught. There's a reason Ethernet jumbo frames haven't gone much over 9000 bytes -- Ethernet's CRC-32 is much less effective at message sizes over 12000 bytes or so. Cryptographically strong hashes tend to be less sensitive to input length.

http://sd.wareonearth.com/~phil/net/ping/
/var/lib/ubuntu_dist_channel contains information that fits well within pings payload size, I do recon that ping could indeed accomplish what you are griping that it cannot.

You're wrong on somethings..

1) bunch of blah and stuff about memory. Since your explanation is memory->application->CPU->kernel memory->protocol stack->CPU memory->NIC driver->bus (basically, it was hard to follow with all the fud), you obviously have no idea how an OS works (I can't think of any modern, common OS's that have such a path). None of this happens as you describe, they are all parts, but the flow is nothing like you describe. See LKML for 2.6 on network programming if you want to see how this works on Linux, which is relatively transparent http://lkml.org/lkml/2005/5/17/78 also you can look at BSD.

2) The PCI Bus is irrelevant for gigabit ethernet (which is about the only network controller commonly in production, legacy stuff like 10/100 is more common- but is almost out of production) and for faster types (10GE or myrinet or infiniband), totally irrelevant. The 32bit PCI bus limit is about at gigabit speeds, and it is shared with everything else on the PCI bus- therefore suboptimal:

http://www.codepedia.com/1/PCI+BUS

PCI-X and gigabit controllers directly off the Controller chipsets is how networking is mostly done now.

3) blah blah, network slower than computers (ridiculous depends on the network and computer exclusively- in consumer computers it swings in a pendulum, when 100Mb came out most of the stuff in the PC couldn't keep up- it was faster to install over the network than from CD ROM because the CD drive was slower, it is going through that again with gigabit- most consumer PCs disk systems can't even approach filling gigabit). Then some conflation about what QoS, and policing can do... QoS only helps if the pipe is full:

http://en.wikipedia.org/wiki/Quality_of_service

or

http://www.cisco.com/univercd/cc/td/doc/cisintwk/i to_doc/qos.htm

4) ISP and stupidity. ISP's may or may not be stupid. They are driven by market forces and the market force is people don't currently want to pay for a tiered service class internet. When they do, they will offer it. Technically it has been feasible for years. Read NANOG mailing list, you will see they are not stupid, but instead are in a low margin business.

5) blah blah blah, microsecond delay, destinguishable from millisecond via a consumer computer with a common OS by a person?? hahahahah. not without a measuring device. It is possible with enough training (I suppose musicians can). Since you can buy commodity off the shelf lan gear that will turn in sub millisecond delay, I don't think spending the extra-money on low microsecond delay will help

Bunch of pseudo-science modded up on Slash again...

Oh and Jumbo FRAMES are commonly 9000B in size (although the term can refer to anything bigger than 1500B:

http://sd.wareonearth.com/~phil/net/jumbo/

or 9K on cisco:

http://www.cisco.com/warp/public/473/148.html

There is zero explanation of the testing methodology, much less the goal of the test. Citing packets per second is a bad measurement without defining the size or size range of the packets. Especially considering that fully realizing gigabit speeds is best accomplished by using jumbo frames (9000 byte frames vs typical 1500 byte frames). In any case, the 48 port 3570 switch the author tested is intended for user connection aggregation in a lan closet, not core data center operations. And the 13k price is list, expect to pay 25% less then that. In short, the author is at best woefully uninformed and at worst a crank.

http://sd.wareonearth.com/~phil/jumbo.html
http://www.thenerds.net/index.php?page=productpage &affid=3&pn=WSC3750G48TSS&srccode=cii_9324560&cpnc ode=12-12880717-2

Does the tool you use to measure speed only count the data payload size, or does it count the size of all packet headers involved (including the lowest protocols used over the cable line)? eg. over ethernet cables (just a dumb cable), you can lose 8% speed just due to packet headers...

best for the internet as a whole
are you sure?

From a paper written by Phil Dykstra, back in 1999.

"A recent example comes from the Pacific Northwest Gigapop in Seattle which is based on a collection of Foundry gigabit ethernet switches. At Supercomputing '99, Microsoft and NCSA demonstrated HDTV over TCP at over 1.2 Gbps from Redmond to Portland. In order to achieve that performance they used 9000 byte packets and thus had to bypass the switches at the NAP! Let's hope that in the future NAPs don't place 1500 byte packet limitations on applications."

Ok, forget it mentions the M word, this article is about using jumbo frames (9000 byte packets) instead of the 1500 byte ones that were originally specced in 1980 (back when ethernet was.. not quite as fast as it is today).

Seeing as how the internet as a whole is based on this packet size, and the article (http://sd.wareonearth.com/~phil/jumbo.html) describes the stunning performance gains that can be had with jumbo frames, the internet as a whole is actually being held back significantly by it (ie. increase the frame buffer by 6, you get about a 40 times throughput)(bigger frames than 9000 bytes are not practical due to other TCP design limitations).

His recommendations are - if you're on a LAN, enable jumbo frames today.

IPv6 will not have this restriction and so will be faster, maybe things like HDTV on demand will drive its adoption on the internet.

"I have never known the CPU to get dragged down by network traffic"

Unusual at 100Mbps, but when you scale up to gigabit and higher, the overhead starts to add up. See http://sd.wareonearth.com/~phil/jumbo.html.

I just installed gigabit at my home network but sprung for a cheaper switch, the only problem with it is that it doesn't do jumbo framing, and here is a list of jumbo frame compatible hardware

to test your link speeds you should not be using Samba, instead use ttcp (windows version,java version, or your favorite distro should have a copy, I know it's in the ports of FreeBSD)

Why should you care about jumbo frames? I found this nice guide about that here.

Wow! I found the exact same site in the story summary!

A friend of mine just went nuts when he found out about a new switch from SMC, the SMC8508T. While it's unmanaged, it offers non-blocking architecture across the entire line as well as support of jumbo frames up to 9K, which is extremely unusual for SOHO stuff. Not even a lot of expensive Cisco stuff does jumbo frames. And he paid $150 for it.

Why should you care about jumbo frames? I found this nice guide about that here.

Perhaps in the upcoming standarization they will finally switch to so called "jumbo frames", aka raise the maximum amount of data that can be sent in one chunk. As the singaling rate has gone up from 10Mb-1Gb, there has been a 100x increase in signaling rate and therefore a 100x decrease in the amount of time it takes one packet to cross the network. Since we are still using the same paltry sizes, cpu usage goes way up and throughput is somewhat capped. Switching to a larger frame size would allow higher throughput and lower CPU utilization. Many networking vendors have started adding support for larger frame sizes into their products for these reasons, but being added to the official standard would greatly increase the adoption of such jumbo frames.
For more info, see:
http://sd.wareonearth.com/~phil/jumbo.html
http://www.psc.edu/~mathis/MTU/
http://www.nwfusion.com/columnists/2004/0105tolly. htm

By default the MTU size on a gigabit card is way too low.

And no, this is not some fancy test lab, but a real network with various switches etc in the way.