CIFS Load Generator source available ...

[Ulf Bertilsson]

Anybody with an tarball laying around ? :)

> -----Original Message-----
> From: Richard Sharpe [mailto:rsharpe at ns.aus.com]
> Sent: Thursday, June 27, 2002 8:08 AM
> To: samba-technical at lists.samba.org
> Subject: CIFS Load Generator source available ...
> 
> 
> CIFS Load Generator
> Developed for SNIA CIFS Benchmarking Working Group
> Richard Sharpe
> Panasas, Inc & Samba Team
> 11-Jun-2002
> 
> INTRO
> This is a short document on how to use the code and where it 
> came from.
> 
> BACKGROUND
> This code has been extracted from Samba's smbtorture utility.
> 
> It is now up on the samba.org site in CVS and can be checked out with:
> 
>    cvs co cifs-load-gen
> 
> RUNNING IT
> To run the code, simply execute ./bin/cifs_bm after having 
> configured and 
> made the code.
> 
>   ./bin/cifs_bm -U<user%pass> -Wworkgroup -c <client-file> 
> [-N clients] \
>       [-I<ip>] [-b >num>] //server-or-ip/share
> 
> 
> NOTE. You need to know the max size of WriteX or ReadXs in 
> the client file, 
> as cifs_bm defaults to 256*1024. Use a flag of '-b <num>' for 
> the block size
> you want. For example, '-b 1024' will give you a buffer of 
> 1024*1024 bytes.
> 
> THE CLIENT FILE
> The client file is essentially the same as smbtorture uses. 
> There are a number of them in the clients directory.  
> 
> Each consists of a series of lines, each with either an 
> operation to perform 
> on the server, or one of a number of special keywords.
> 
> The keywords are:
> 
> BM_SETUP: Provides a series of setup operations. Currently, 
> the driver does
> noting with this command, except set an internal variable 
> called state to
> BM_SETUP. No measurements are taken during this phase.
> 
> BM_WARMUP: Provides a series of warmup operations. Currently, 
> the driver does nothing with this command, except set an 
> internal variable called state to BM_WARMUP. No measurements 
> are taken during this phase.
> 
> BM_MEASURE: Provides a series of operations that will be measured.
> 
> RECONNECT: Disconnect from the server and reconnect to it.
> 
> SYNC <n>: Wait for up to <n> seconds for the master to say 
> go. It waits for all the clients to SYNC.
> 
> There are about 14 commands that are implemented. Look at the 
> collection of 
> .txt files to get an idea of what they are ...
> 
> Some of the bit fields are important. For example, on an:
> 
>   NTCreateX <file> <flag1> <flag2> <FID> 
> 
> command, <flag2> needs the 0x01 bit set if it is to ignore 
> failures due to 
> files already existing.
> 
> An additional command is: Lock <file> etc ... Check the code 
> for params for
> now.
> 
> PROBLEMS
> There are still many problems. 
> 
> 1. It would be nice if the child/client processes would 
> synchronise each 
>    phase with each other. A Sync command is now implemented.
> 
> 2. FIND NEXT is not really implemented. This needs doing.
> 
> 3. More operation types are needed. Lock is now implemented. 
> However, see
>    below.
> 
> 4. Some way to generate a load file would be nice.
> 
> 5. There is no way to specifiy a schedule of users and 
> passwords to use to
>    log onto the server.
> 
> 6. NetBench specifies its driver file as a series of parts, each part 
>    containing a series of commands. It then randomizes the 
> order of the 
>    parts. It would require a rewrite of cifs_bm to achieve this.
> 
> 7. There is no way yet to spread the load over a series of interfaces.
> 
> 8. There is no way to separate out connection to server, 
> logging in and 
>    connection to the share. They are all one event. Thus we 
> cannot measure
>    the server's ability to handle logons (SessSetup&X), connections
>    (probing its ability to fork or create threads), and 
> connecting to shares
>    (TCON etc). This calls for commands like: Tcon <share>, 
> Tdis <share>, 
>    etc.
> 
> 9. The latency info needs to be kept in long longs, and the 
> read and write
>    throughput needs to be cleaned up.
> 
> 10. It would be nice to have an embedded programming 
> language, like TCL or
>     ...
> 
> 11. It has been suggested by a guy from Sun that the current 
> model of one
>     process per client might be affected by scheduler 
> latencies. In addition
>     if we want to simulate really large numbers of clients, 
> we might need to
>     move to a multi-threaded client.
>  
> Regards
> -----
> Richard Sharpe, rsharpe at ns.aus.com, rsharpe at samba.org, 
> sharpe at ethereal.com
> 
> 
>