AW: The CIFSbench package

[Martin Kuhne]

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.

Martin

-----Ursprüngliche Nachricht-----
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
          there.
  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
          explode. 

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. 

Chris -)-----

-- 
Christopher R. Hertel -)-----                   University of Minnesota
crh at nts.umn.edu              Networking and Telecommunications Services