managing user accounts without NIS
Robert G. Brown
rgb at phy.duke.edu
Thu May 25 09:05:31 PDT 2000
On Wed, 24 May 2000, Donald Becker wrote:
> This execution time includes shipping an arbitrary binary over to the remote
> node, rather than loading it from the local disk. For small processes where
> the executable is not already in the buffer cache this option is faster than
> loading it from the disk. I presume the 'rsh' tests are done with a
> preloaded buffer cache?
Effectively. After the first interation it would be anyway -- I run 100
loops to get decent statistics and it's a bit difficult to convince the
kernel to flush the cache buffer once it has cached something -- I'd
have to touch the binary between loops or something. I've also seen the
very significant delay associated with first-time file access, though,
and using the network to avoid this is very clever.
Can you still push the binary into a local cache to avoid the network
hit on the 2nd-Nth invocations (of a binary you execute repeatedly,
since none of this matters for binaries that are executed a few times a
day)? I'll have to grab bproc and play with it...sounds fun.
I'll change rshbench to use /usr/bin/uptime instead of /bin/date (which
I chose for identical reasons -- small binary, cheap call).
It sounds like you have designed bproc to operate in rootspace and avoid
(most of?) the overhead of starting a shell at all. I think that I'll
fractionate the time costs of 100 empty loops, 100 executions in a given
shell script, 100 executions forking a subshell, 100 executions in the
selected remote shell. I can even add a touch and foil the cache.
Robert G. Brown http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb at phy.duke.edu
More information about the Beowulf