AW: The CIFSbench package
mkuhne at microsoft.com
Wed Mar 10 17:48:45 GMT 1999
How about a client that is optimized for your server (no use to throw away
the benefits in this case), performs reasonably well to the rest of the
modern world, and supports basic connectivity to legacy inplementations?
Users will not accept slow performance in a mixed environment. Resolution of
this problem will depend on how well the standard was written and on the
cooperation of all involved parties.
Performance problems can be severe even without violating specs. I've seen
an ancient IBM DOS client that did not support windowing, and the NT server
was configured for delayed acknowledgements. (explanation simplified) This
resulted in a 200ms round trip time for each frame i.e performance like a
floppy disk drive.
In this case you are stuck; You can disable delayed acks but at a
performance loss for more modern clients.
Best thing obviously is letting the user choose.
Von: Christopher R. Hertel [mailto:crh at nts.umn.edu]
Gesendet am: Mittwoch, 10. März 1999 17:10
An: Multiple recipients of list
Betreff: Re: The CIFSbench package
Interesting discussion, re CIFSBench. I have a question...
Given the complexities and permutations of SMB, how possible is it (or
how easy is it) to tune a client for a particular server?
For example, let's say I'm writing a client. I might imagine three ways
to get it to do a particular task:
Way 1: Fastest all around. Could get better speed out of my own server
but this mechanism is the best compromise for any server out
Way 2: Top speed against my server but abysmal against all others.
Way 3: Slower against my server, but very, very slow against other
servers. Some other servers crash violently, causing sparks to
fly from their power supplies and nearby small animals may
How to choose, how to choose...
If you happen to be the client and server leader, you'd probably pick #2.
If you were worried about market share, then #3 might be a better option.
If'n you're the market leader but not a commercial organization, or if you
just plain care about your customers, then #1 is the obvious choice.
In any case, it's not just the client software that could be tuned this
way. The benchmark suite could also suffer from such fiddling (which is,
of course, why the thing should be Open Source).
These issues are probably obvious to everyone else, but I like to
celebrate when the little bulbs flicker on in my head.
Christopher R. Hertel -)----- University of Minnesota
crh at nts.umn.edu Networking and Telecommunications Services
More information about the samba-technical