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