Re: [securenfs-devel] Fixed timings in thread-test client

[David W. <wo...@pl...>]

> 
>>Yes, I believe that 9729 ~ 9.5K.  However, there are 21 clients that
>>are sharing the same "pipe" so that is actually 9.5K * 21 bytes/sec, or
>>about 200K/sec.  Now, this is assuming that they all start and end at
>>the same time which is not exactly true, but hopefully close.  Do you
>>agree with that logic?
> 
> 
> I agree with the logic, but over a local bus on the same machine we
> should see a much bigger pipe that 200k/sec...  Could have something to
> do with how we recieve the messages too (byte by byte vs a whole buffer
> at a time), but I would think we could get MUCH higher.  Perhaps its
> time we ran the server on shemp and beat against it with a few clients
> to see what kind of responses we get?


Hmmm.. You make an interesting point.  I guess the question is, how does
Linux handle a localhost socket connection?  As far as I know, it
uses TCP/IP even though client and server are on the same host.  Hence
my guess is that it is not just a communication over the bus.  The
data may be routed through some kind of serial interface.  I'm guessing
that we should expect slower performance than say just regular IPC.

Yes, we definately should test it out with clients on different
machines.  I've already done a little of that on my home network, but
I haven't compared the results to localhost communications.


> 
> 
>>>I also get different sec/message rates depending on the # of clients.  ~
>>>0.001 with < 10, 0.01 10-15, 0.1 15-20, but that makes sense, as each
>>>must share bandwidth with the others.
>>>
>>
>>Yes, I get that too, and that makes perfect sense.  The important thing
>>is that they share the load equally.  My results show that all timings
>>are consistent for all clients (seem to be sharing the load equally).
>>Good news!
> 
> 
> I agree - Very good news! :-)
> 

Yeah!  Have a beer in celebration (hey any chance to celebrate eh?).

Dave

-- 
----------------------------------------------------------------
I encourage correspondence using GnuPG/OpenPGP encryption.
My public key:  http://www.cs.plu.edu/~dwolff/pgpkey.txt