mcm@rti.UUCP (Mike Mitchell) (01/06/90)
I've been playing with the 'nhfsstone' program from Legato Systems, Inc.,
and I've been wondering a few things. As it comes from Legato, 'nhfsstone'
can only check out NFS file systems. I looked at the code, and it reads a
kernel data structure to get statistics. The statistics that is uses are
operation counts. Each sub-process knows how many operations that it has
performed, but the parent process does not know how many operations each
child has performed. Why can't the children communicate this information
to the parent using a temporary file or pipes? Why is reading the kernel
data structure necessary? (Because it is there?)
I modified the program to use shared memory to pass the data around, and
now I can get statistics for local file systems. Does anyone see any problem
with this approach? The only short comming that I see is that the program
does not know the actual load of the server, only the generated load.
The results of using this version would be skewed if the client and server
had a high load on them already. The original 'nhfsstone' program checks
for a high client load.
I would like a way to compare other filesystems' performance to NFS performance
in a semi-standard way. Does anyone have a better approach?
--
Mike Mitchell {decvax,seismo,ihnp4,philabs}!mcnc!rti!mcm mcm@rti.rti.org
"If you hear me talking on the wind, You've got
to understand, We must remain perfect strangers" (919) 541-6098venkat@sequent.UUCP (Venkat Malla) (01/09/90)
In article <3392@rti.UUCP> mcm@rti.UUCP (Mike Mitchell) writes: >I've been playing with the 'nhfsstone' program from Legato Systems, Inc., >and I've been wondering a few things. As it comes from Legato, 'nhfsstone' >can only check out NFS file systems. I looked at the code, and it reads a >kernel data structure to get statistics. The statistics that is uses are >operation counts. Each sub-process knows how many operations that it has >performed, but the parent process does not know how many operations each >child has performed. Why can't the children communicate this information >to the parent using a temporary file or pipes? Why is reading the kernel >data structure necessary? (Because it is there?) What the sub-processes do is generate pseudo NFS ops to simulate an NFS environment on the client side. Since these dont necessarily reflect in the actual NFS ops performed, the kernel NFS stats are read periodically and the operation-mix is monitored (couldn't figure out the formulas used here, anybody did?) and the NFS load adjusted. > >I modified the program to use shared memory to pass the data around, and >now I can get statistics for local file systems. Does anyone see any problem >with this approach? The parent merely sets up the client processes and finally gathers the stats they record. You dont need to pass the data around. Each sub-process is independent and acts like a separate client (to simulate several processes grabbing the few file-handles available). > >I would like a way to compare other filesystems' performance to NFS performance >in a semi-standard way. Does anyone have a better approach? > Nhfsstone is tailored to measure NFS performance (diff. implementations). Other file systems may use a different protocol. You could perhaps use the connectathon general tests for such comparison.
uppal@hpindda.HP.COM (Sanjay Uppal) (01/11/90)
Could someone give me a pointer to the source code for this "Nhfsstone" program ? Is it proprietary or publicly available ? Sanjay Uppal <uppal> (NN9T, VU2SMT) phone: (408) 447-3864 Hewlett-Packard (IND) uucp: ...!hplabs!hpda!uppal NS arpa: uppal%hpda@hplabs.hp.com
mojo@legato (Joseph Moran) (01/12/90)
In article <38810003@hpindda.HP.COM> uppal@hpindda.HP.COM (Sanjay Uppal) writes: >Could someone give me a pointer to the source code for this >"Nhfsstone" program ? Is it proprietary or publicly available ? "Nhfsstone" (pronounced n-f-s-stone, the "h" is silent) is a copyrighted product of Legato Systems, Incorporated and is provided for unrestricted use and distribution of the binary program derived from it. nhfsstone is a NFS load generating program. It is used on an NFS client to generate an artificial load with a particular mix of NFS operations. It reports the average response time of the server in milliseconds per call and the load in calls per second. The program adjusts its calling patterns based on the client's kernel NFS statistics and the elapsed time. Load can be generated over a given time or number of NFS calls. The current version of the program can only be compiled on 4.x BSD based UNIX systems. To obtain the nhfsstone source shar file, send email to "request@Legato.COM" or {sun,uunet}!legato!request. The Subject line and/or body of the message should have contain the command line: send unsupported nhfsstone Note the exact spelling of "nhfsstone". To issue delivery, you should also add a line of the form: path <address> where <address> is the preferred email address to use. Generally, using a domain-style email address works best. A uucp path starting with "sun!" or "uunet!" can also be used. Joseph Moran Legato Systems Inc. 260 Sheridan Avenue Palo Alto, CA 94306 (415) 329-7886 mojo@Legato.COM or {sun,uunet}!legato!mojo
uppal@hpindda.HP.COM (Sanjay Uppal) (01/16/90)
Thanks a lot to all who responded on how to obtain a copy. A first glance at the code shows that this benchmark differs from the "nfsstone" benchmark put out by Barry Shein et al from Encore Computer Corporation. Oddly enough both benchmarks have the same name (or at least pronounced in the same way). Are these related in any way ? I suppose I could delve deep enough and get a list of pro's and con's for each and then choose one - has anyone already done this study ? Sanjay Uppal <uppal> (NN9T, VU2SMT) phone: (408) 447-3864 Hewlett-Packard (IND) uucp: ...!hplabs!hpda!uppal NS arpa: uppal%hpda@hplabs.hp.com