Slashdot Mirror

A good test product is ttcp. TTCP measures both bandwidth and latency. You can learn more at http://www.pcausa.com/Utilities/pcattcp.htm.

You'll need a partner somewhere on the 'Net, but you'll get an accurate measurement.

The problem I always had with speedtest.net is that the data it transfers is static, so that content caching services can skew the validity of the data. Also, your own internal browser can cache the information so subsequent tests to the same website may reflect incorrect results.

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)

The article says that they used ttcp which is a memory-to-memory bandwidth testing program. Most would consider that unrepresentative of reality. On the other hand, today's supercomputers have a tremendous amount of memory (1.2 TB, 6 TB, 10 TB, 33 TB, etc.) so memory to memory is possible.

Others have suggested that disk speeds cannot sustain that rate. However, supercomputer disk arrays can easily keep up (4 GB/s or 32 Gb/s).

Finally, it is possible to achieve nearly the same result (multiple streams instead of a single stream) transfering real data (23.23 Gb/s).

[Bias alert: I am a member of the team that set a previous Internet2 Land Speed Record, Guinness World Record and won the "Bandwidth Lust: Distributed Particle Physics Analysis Using Ultra-High Speed TCP on The Grid" or "Moore's law move over" award at SC2003.]

Now, before you complain that the technology is not available to "mere mortals," let me point out that we first started experimenting with 1 Gb/s Ethernet at work 5 years ago. Now it is readily available at reasonable prices for consumer desktop machines. (Apple has had it standard in G4 desktops for 4 years.) The problem is not with consumer hardware, it is having access to true broadband (not cable modem or DSL), at least in the USA. Although your LAN may support 1 Gb/s, your download speed is limited to 1-3 Mb/s (cable) or 256 -786 Kb/s (DSL). (Your upload speeds are significantly lower.) Since the link provider has very little incentive to upgrade service, I doubt that will change very quickly.

So, yes it is possible. No you can't have it (yet)!

Test TCP (TTCP) is a command-line sockets-based benchmarking tool for measuring TCP and UDP performance between two systems. It was originally developed for the BSD operating system starting in 1984. The original TTCP and sources are in the public domain, and copies are available from many anonymous FTP sites.

Test TCP (TTCP) Benchmarking Tool for Measuring TCP and UDP Performance.

The original NDIS specification predates Windows NT, 95, et al. It was, in fact, targeted at DOS and OS/2. A little Googling [see this, this, and this] shows that it has a long (if not glorious) history. IIRC, NDIS binaries would load unmodified in Win NT and Win 95. This is pretty cool given these two OS's vastly different I/O models.

They use PCA-USA's windis shim. A good product, and cheap - about $500.

The nice thing about PCA-USA is that it gives you a copy of the NDIS stream, so you can create an anti-sniff proof network sniffer, among other things.

Seems to be a very sensibly designed packet sniffer - along the lines of how I would build such a thing.

If this report shows us anything, it's that we should not object to the implementation, but to the concept. Even if it is sensibly designed from off-the-shelf products, there is no way for them to gaurauntee they're picking up only the packets they want. In fact, it's quite impossible. How do you track someone with a dynamic IP? What's their signature? You don't know - you have to read everyone's traffic to find them.

If your system has a driver that lets you get at raw packets (the moral equivalent of raw DLPI access on Solaris, SOCK_PACKET or packet filter access on Linux, BPF access on BSD, etc.), the driver could provide a way to enable or disable promiscuous mode on cards that support it, read and write raw packets, etc..

Unfortunately, NT either doesn't come with such a driver by default, or doesn't document it (NT Server comes, I think, with Network Monitor, which includes such a driver, although the version that comes with NT is claimed not to support promiscuous mode; you need the version that comes with System Management Server to get that).

The Microsoft Developer Network stuff comes with sample driver and userland code to do that, at least on NT, and PCAUSA sells the Win32 NDIS Framework, which includes a driver and a userland library to let you do that on W9x and WNT (complete with a BPF interpreter in the driver, so you can do BPF-style packet filtering when capturing).

I've not used either of them, so I can't say one way or the other how well they work.

If your system has a driver that lets you get at raw packets (the moral equivalent of raw DLPI access on Solaris, SOCK_PACKET or packet filter access on Linux, BPF access on BSD, etc.), the driver could provide a way to enable or disable promiscuous mode on cards that support it, read and write raw packets, etc..

Unfortunately, NT either doesn't come with such a driver by default, or doesn't document it (NT Server comes, I think, with Network Monitor, which includes such a driver, although the version that comes with NT is claimed not to support promiscuous mode; you need the version that comes with System Management Server to get that).

The Microsoft Developer Network stuff comes with sample driver and userland code to do that, at least on NT, and PCAUSA sells the Win32 NDIS Framework, which includes a driver and a userland library to let you do that on W9x and WNT (complete with a BPF interpreter in the driver, so you can do BPF-style packet filtering when capturing).

I've not used either of them, so I can't say one way or the other how well they work.