Date: Sun, 1 Jul 2001 08:02:08 -0500 From: David Leimbach <dleimbac@earthlink.net> To: Ted Mittelstaedt <tedm@toybox.placo.com>, questions@freebsd.org Subject: Re: Real numbers on why loopback is slow in FreeBSD please read... Message-ID: <20010701080208.A767@mutt.home.net> In-Reply-To: <001801c10205$27b12f60$1401a8c0@tedm.placo.com>; from tedm@toybox.placo.com on Sun, Jul 01, 2001 at 01:09:30AM -0700 References: <20010630112406.A1143@mutt.home.net> <001801c10205$27b12f60$1401a8c0@tedm.placo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Dave, > > There's probably another reason that people aren't really paying attention > to your posting - they aren't seeing the same figures. I think my personal home machine is actually getting better numbers than the FreeBSD 4.2 box I have at work. Its also autonegotiating its 100Mbit capable adapter down to 10Mbps... It's a weird HP box. > > Here's the output on my own home system, a Pentium 166Mhz: > > mail# ping -s 4096 -f 127.0.0.1 > PING 127.0.0.1 (127.0.0.1): 4096 data bytes > ..^. > --- 127.0.0.1 ping statistics --- > 2574 packets transmitted, 2573 packets received, 0% packet loss > round-trip min/avg/max/stddev = 0.235/0.252/0.438/0.013 ms > mail# > > As you can see, with a packetsize of 4096 (8192, your largest size, > isn't > valid for ping) pinging the loopback as fast as possible, I'm only seeing > an average of 252 microseconds, not 400 microseconds as you posted. > > Doing the same thing again with a packetsize of 64 shows the following: > > mail# ping -s 64 -f 127.0.0.1 > PING 127.0.0.1 (127.0.0.1): 64 data bytes > ..^C > --- 127.0.0.1 ping statistics --- > 2995 packets transmitted, 2994 packets received, 0% packet loss > round-trip min/avg/max/stddev = 0.071/0.075/0.229/0.004 ms > mail# > > Now I'm seeing only 75 microseconds average. Once again, this is vastly > different than the 200+ microseconds your seeing on your test. > > Now, you said in your posting that your perf stats run a ping pong test > so whatever your running ought to be identical to "ping -f -s somedatasize". > You didn't post how fast the CPU of your system is, nor any of the other > particulars. And, you certainly didn't post the code that your using > to generate your numbers. Its not really identical to ping. We use an some in house algoritms I am not sure I can talk about without getting fired to "cache small messages before they are sent". Small is a threshold that can be adjusted by the user of the MPI library. The code being used to generate the numbers I can give but unless you know any MPI its pretty useless to you. Its a parallel application and you have to remember that its running in two places simultaneously. > > Would you consider the possibility that your code that you wrote to > do this is horribly inefficient, instead of FreeBSD? I have observed that > most > of the problems that people have troubleshooting is when they start assuming > that what they have done couldn't possibly have a problem, so they waste all > kinds of time searching for the problem that they are convinced that > something > else has. You need to consider that your code is faulty and test this > hypothesis with other people's code that does the same thing. If your code > and > everyone else's code running on FreeBSD all come up with the same numbers, > that are repeatable on other people's system, then we would get interested. > But as of now I have attempted to duplicate your hypothesis of inefficient > loopback performance under FreeBSD and found that there is no basis for it. I would consider that the code is faulty I was the only one writing it.. :) and also if we didn't get reviews from our customers stating how much faster we were than our competition at doing this exact kind of work. On a 100Mbps connection between two machines we are getting bandwidth of about 11MB/s [yes B for Byte]. Since 8 bits are in a byte and you have to deal with packet header overhead and the fact that TCP/IP really isn't that great a protocol when compared to some of the less paranoid kinds [ATM comes to mind..]. I would say we are pretty close to optimal in our code. This led me to think that FreeBSD is the problem. If you don't believe my claims you can feel free to download MPI/Pro for Linux for free at www.mpi-sofftech.com. This will allow you to run up to 16 process jobs [16 processes on potentially 16 different machines in a cluster] over a TCP/IP connection. I have only ever seen less than 11MB/sec with MPI/Pro on Solaris but it was about 10.9MB/sec. The whole point of this is I am trying to verify a target for MPI/Pro on FreeBSD. That demo I was talking about in the previous paragraph will not run out after an "evaluation period" but it is only available for Linux and Win32. We would like to support all the Unixes and are currently also looking at Tru64 and Mac OSX [though we are understaffed and I am doing all three plus some other work. I am working on the FreeBSD port in my spare time though out of appreciation for being able to use such a great system.] I am not trying to criticize FreeBSD I am just trying to squeeze all the performance I can out of it.... > > > > Ted Mittelstaedt tedm@toybox.placo.com > Author of: The FreeBSD Corporate Networker's Guide > Book website: http://www.freebsd-corp-net-guide.com > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010701080208.A767>