NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/37025
The following reply was made to PR kern/37025; it has been noted by GNATS.
From: "Martin S. Weber" <Ephaeton%gmx.net@localhost>
To: gnats-bugs%gnats.netbsd.org@localhost
Cc:
Subject: Re: kern/37025
Date: Mon, 1 Mar 2010 17:27:46 -0500
Alright, it seems I prematurely jumped to conclusions here. I left
the computer alone when it was still running tests with low
blocksizes; with higher blocksizes the image changes.
The following are results for reading and writing ~130MB of "random"
data (a release.tar containing a set of i386 binary sets) to the
samba share (read from or written to a local wapbl ffs). The server
is something native windows -- the network a 100MBit. I don't have
any control whatsoever over the server in case you wanna ask
questions, although I might find one thing or another out. The
client machine was a NetBSD 5.0_STABLE (GENERIC) #4: Tue Jan 5
13:58:42 EST 2010
Good news first: you'll see that mount_smbfs performs (nearly) en
par with smbclient, if the blocksize is just high enough.
writing:
block \ block type & attempt
size \ obs#1 bs#1 obs#2 bs#2 obs#3 bs#3
--------\-----------------------------------------------
1/2 kiB | 694kB 800kB 866kB 910kB 935kB 1021kB
1 kiB | 1272kB 1306kB 1553kB 280kB 1493kB 444kB
2 kiB | 2666kB 2760kB 2952kB 2972kB 2719kB 2877kB
4 kiB | 3760kB 3668kB 4593kB 4599kB 4647kB 4093kB
8 kiB | 4892kB 5040kB 6350kB 6014kB 6232kB 6200kB
16 kiB | 6675kB 7112kB 7913kB 7970kB 7850kB 7944kB
32 kiB | 8338kB 8459kB 8977kB 9189kB 9035kB 9148kB
64 kiB | 8664kB 8753kB 9203kB 9252kB 9275kB 9336kB
--------+-----------------------------------------------
default | 1022kB (at about the time of bs#3 measurement)
smbcl | #1: 8595kB #2: 9198kB #3: 9264kB
reading:
block \ block type & attempt
size \ ibs#1 bs#1 ibs#2 bs#2 ibs#3 bs#3
--------\-----------------------------------------------
1/2 kiB | 759kB 736kB 944kB 944kB 1049kB 328kB
1 kiB | 1319kB 1389kB 1567kB 1813kB 1532kB 1537kB
2 kiB | 2281kB 2083kB 2952kB 3114kB 2874kB 3007kB
4 kiB | 3285kB 3655kB 4487kB 4798kB 3609kB 4503kB
8 kiB | 4890kB 5196kB 5870kB 6468kB 5974kB 6358kB
16 kiB | 6286kB 7178kB 7268kB 7914kB 7415kB 7955kB
32 kiB | 7907kB 8611kB 8513kB 9495kB 8504kB 9621kB
64 kiB | 7968kB 8843kB 8584kB 9536kB 9275kB 9336kB
--------+-----------------------------------------------
default | 1070kB (at about the time of bs#3 measurement)
smbcl | #1: 9253kB #2: 9845kB #3: 9896kB
For the bad news:
- I had to keep some while :; do ls ; sleep 5; done running to have
access to the share every now and then, without it, the transfers
will stall pretty quickly.
- Even with that, sometimes the ls itself was stuck (in tstile)
while the dd was stuck in smbwrq (at least the one case where I
thought of checking dd's state). Things wouldn't move without me
doing ANOTHER ls on the samba share. Then, both the ls would
immediately do its job as would the dd pick up pace again (as seen
on xosview's NET traffic display).
- I didn't notice all of these "stuck" situations at once, that's
where the worst results in above tables come from : reading (1/2
kiB, bs#3), writing (1 kiB, bs#3)
- I'm not satisfied yet with the results and will do further
measurements (cp specifically although I doubt it will differ
from the dd-default case at least for writing)
For completeness: following outlines the measurement method:
==========
#! /bin/ksh
date
bs=512
while [ $bs -lt 66000 ]
do
echo "dd writing"
for block in obs bs
do
echo -n "bs:$bs block:$block "
dd if=release.tar of=$SMBSHARE/release.tar $block=$bs
done
echo "dd reading"
for block in ibs bs
do
echo -n "bs:$bs block:$block "
dd if=$SMBSHARE/release.tar of=release.tar $block=$bs
done
bs=$(($bs * 2))
done
echo "smbclient reading"
smbclient -c "cd $SMBHOME/$SMBSHARE; get release.tar" \
-I $SMBSRV -W $WRK -U $USR //$USR@$SMB/$SHR $password
echo "smbclient writing"
smbclient -c "cd $SMBHOME/$SMBSHARE; put release.tar" \
-I $SMBSRV -W $WRK -U $USR //$USR@$SMB/$SHR $password
date
==========
If you see a systematic/fundamental flaw in the above, please
let me know.
Regards,
-Martin
Home |
Main Index |
Thread Index |
Old Index