managing user accounts without NIS

[Robert G. Brown]

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.

  rgb

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