On Thu, Apr 27, 2006 at 07:39:53AM +0200, Henrik Stoerner wrote:
On Wed, Apr 26, 2006 at 05:49:45PM -0400, Schwimmer, Eric E *HS wrote:
So this leads me to believe that it is a problem solely with fping; if they had a public forum or a mailing list, I'd be whining there instead of here. :) I can't say that I was expecting to find the 'magic bullet' for this problem here, but I was hoping that there might be some fping wizard out there some magic bullets to spare. Anywho, thanks for your thoughts, Henrik. I'll poke some more at the fping code and see if I can figure out whats going on (I doubt it)
I haven't spent much time looking at the fping code, so I have no idea how well it's been optimized. It might be an idea to compile fping with profiling enabled (i.e. add the "-g -pg" options to the compile- and link-flags) and run it through your test. This generates a "gmon.out" file which you can run through gprof like "gprof fping gmon.out" and it will tell you how much time is spent in various parts of the code. "gprof -l ..." will do it on a line-by-line basis.
I've had a look at the fping sources.
There aren't any really obvious reasons why it should take so long. If you run it with "time", it also claims that the user- and system-time are really low (I tried with ~1500 hosts), but the wall-clock time is like 90 seconds (default options). Which kind of points at the code not really doing parallel pings.
I think I'll try some modifications to it over the week-end. If any of it seems to improve it, I'll let you know.
Regards, Henrik