Using current dbench (dbench 3.0.3) from
http://samba.org/ftp/tridge/dbench/dbench-3.03.tar.gz

Unpack dbench on the Linux client to e.g. your local homedirectory, build it.

Launch smbd on the same box

mount -t cifs //localhost/sharename /mnt

from the local homedirectory, dbench -D /mnt/targetdir 70

which launches dbench with 70 local processes (cifs client will throttle that
back somewhat) against the remote mounted directory specified.  I have also
found failures specifying a much shorter time such as 70 seconds (e.g. dbench -t
70 -D /mnt/targetdir 70)

I see three symptoms against Samba 3.0.20 which I do not see running against
3.0.14a Samba on the same server.

a) oscillating slow response - my traces, polling periodically the pending mid
queue, in the cifs vfs show multiple ReadX and OpenX and Transact2 (do not know
which trans2 subcommand) outstanding for more than 2 seconds, sometimes even a
few over 4 seconds.  Have seen a couple timeouts (15 seconds).  This is much
longer than expected for only 70 processes (the test machine is 1.2GHz Pentium III)
b) a few read failures (probably caused by the timeout and subsequent session
drop and reconnect).  I have seen a couple runs in which there was a session
drop (due to the timeout and the client giving up on a read).
c) cleanup phase errors (looks like sharing violations)

smbfs also returned errors to the same 3.0.20 server during the cleanup phase,
which would need more investigation to track down whether it is an smbfs bug or
server problem (less important issue - but possible confirmation of 3.0.20 problem)

This is clearly not enough data (one test machine, RHEL4 with current kernel
2.6.13) but that it worked to 3.0.14a and not to 3.0.20 (and occurred multiple
times) was worrisome.