RE: High Speed Firewalls

["David Newman" <dnewman () networktest com>]

Even a perfect server -- one that can move 12.5 Mbytes of data in 0 seconds
with 0 latency -- won't help us on the wire.

The point I made was that TCP/IP itself adds some overhead to file
transfers -- stuff like connection setup and teardown and packet headers --
that makes it impossible to move 100 Mbit/s of *user data* in 1 second, even
if that's the media rate. The wire itself, of course, can move 100 Mbits per
second, but that's not the same thing as transferring a file in that
duration.

I've never tried it, but I doubt we'd hit the theoretical maximum of 100
Mbit/s even on the loopback interface, since Mr. TCP still does his thing.

dn


> -----Original Message-----
> From: Linder, Daniel G. [mailto:Daniel.Linder () NorstanConsulting com]
> Sent: Monday, March 20, 2000 1:31 PM
> To: David Newman; crispin () wirex com
> Cc: firewall-wizards () nfr net
> Subject: RE: High Speed Firewalls
>
>
> Excuse me if this has been hashed through before, but there are a couple
> other things that I have not heard discussed in reference to
> throughput but
> I'll bring them up anyway:
>
>       1 - Have you tried just doing a "time dd if=/path/to/12.5MB.file
> of=/dev/null"?  This will tell you the maximum speed the server (assuming
> UNIX) can pull the file off of the hard drive.
>
>       2 - Try "time dd if=/dev/zero of=/path/to/12.5MB.file bs=500k
> count=25"?  This will (if I did my math right!) create a 12.5MB file from
> the /dev/zero device.  This should show how quickly the server
> (again UNIX)
> can blast 12.5MB to the drive.
>
>       3 - Try disabling *EVERY* daemon/service and just doing the FTP
> and/or the above tests.  I am certain that even a stripped down OS will
> cause some contention.
>
> Dan