Marcus, thank you for your prompt reply and I am sorry I couldn't respond
earlier.
First let me say that the results I published were not for every site in
the world. I ran these benchmarks for the Theory Center with the Theory
Centers problems in mind. We are not interested in afs performance to
mac's or even desktop workstations. We are interested in how afs will perform
for large blocks of io to a much smaller disk or memory cache over atm.
On Sat, 12 Nov 1994, Marcus Watts wrote:
> About machine configuration
>
> The RS/6K has a relatively clever scheme to manage
> network interfaces - "ifconfig en0 detach" will actually
> make a network interface disappear, & the networking
> configuration is stored in /etc/objrepos and so can be
> readily changed merely by modifying the files & rebooting.
> So, it should be pretty easy to run with both interfaces
> but without any concerns about all those messy "multi-homed" issues.
I agree this is the way to go if you are interested in benchmarking afs
3.3a and you have a "real" console on the benchmark machines. Once again
we were aware of the option of detaching the ethernet interface to get the
correct mtu size but after one of the people here talked with Transarc about
afs 3.4 we decided to move ahead and benchmark with a pre beta version of
afs 3.4 instead.
> About AFS caching
>
> The client has 512M of ram - if so, a 10 M memory cache
> would seem to be a viable concept. (But not with a
> 1 M chunk size!)
Again we use a 1 MB chunk size because it performs best for our problem set.
This may not be an appropriate chunk size for a mac or any type of
machine that has a lot of interactive work with small io requests.
> the exact statistic - but something like 80% of all
> files are less than 4K in size. In one arbitrary directory
> I picked (the last program I compiled), I have 208 files -
> exactly one of which is over 1 M in size. 56 of them are
> over 4K in size. The remaining 152 are not more than 4K in size.
>
Again this does not hold true for out site especially for those machines
we are going to connect via atm.
> When you do an "fs flushv" - do you do a "system("fs flush X")",
> or do you do a "pioctl("X", VIOC_FLUSHVOLUME, &blob, 0)"?
> With the former, there may be a significant additional
> amount overhead in loading the shell, loading fs, and perhaps
> in terms of probing the path to find "fs".
I did use a system call but it has absolutely nothing to do with the time
it took to read or write blocks of IO since I start and stop the timer for
reads and writes well after the system call finished.
> I'm not really at all sure what your "lseek" tests have measured.
> With Unix, "lseek" per se is actually only a good measure of system
> call handling. Does "bonnie" read anything after it seeks? If so,
> it might be a good measure of random I/O. If not, then perhaps what
> is being measured here is the overhead of fetching the volume header,
> or of directory lookups, or something else. The low CPU utilization
> you report certainly suggests whatever is being measured is not
> system call overhead!
I didn't see much use in lseek either but the benchmark reports it and I
didn't see any harm in passing it along.
> In Conclusion
>
> I hope I haven't scared you away from benchmarking. It can be quite
> tricky to come up with meaningful results, and it's positively
> dangerous to associate meanings with the results. Nevertheless, it
> can still be quite educational, and there's certainly no substitute
> when it comes to questions like "how fast is it?"
>
> -Marcus Watts
> UM ITD RS Umich Systems Group
You haven't scared me away, well maybe from Umich but since it is probably
colder there than it is here I doubt I will be able to credit you for
that. The points you made are great and very useful but I do believe I
considered most of them.
Listen folks I did not intend that the results I posted be the end all
for benchmarks of afs over atm. I attempted to use a fairly common
benchmark that would exercise the system as a single process which
happens to be the problem we are trying to solve. We do have an atm, fddi
and a 512 way IBM sp2 switch which we plan on routing afs traffic over.
All 512 sp2 nodes will have 100 Mb/s access to our afs fileservers and
what we (CTC) need to decide is what is the best use of atm and fddi in
this environment?
Thanks again,
Louis R. Constable
Cornell Theory Center
