Messages in this thread | | | Date | Thu, 05 Dec 1996 15:00:24 -0500 | From | Gary Schrock <> | Subject | smbfs performance (was Re: smbfs vs nfs) |
| |
At 01:23 PM 12/4/96 -0500, you wrote:
>line of 1 or 2k/s, and writing anything large tends to completely screw
>over the smbfs connection (large being 20+ megs, size varies on what screws
>it up). And the only way I've been able to figure out how to fix the
>screwed up connection is to reboot the linux box. Considering that the
>machines the linux box is talking with are on the same local subnet, these
>performance numbers are dismal, and certainly fall below the performance of
>win95 box to win95 box transfers.
Ok, since I did get a couple of comments about people not being able to reproduce the things I mentioned above, I decided to run a few timing tests. Course, it gets kind of annoying when you can't manage to reproduce the problems you've had in the past :). In fact, my read numbers were a lot higher than the last time I looked at this, the write numbers were a little higher and I couldn't reproduce the problem with large writes killing the mount point (although I had it happen about a week ago on the same kernel version). However, I feel the disparity between the read and write speeds that I got is still indicative of some sort of problem. The file used to perform the test was a zipped copy of the wordperfect for windows installation on the win95 machine.
eyelab:~# cat /etc/motd
Linux 2.1.7. (POSIX).
eyelab:~# df
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/hda6 215989 137434 67402 67% /
/dev/hdb1 232028 187261 32785 85% /usr
//psy219.psy.msu.edu/e
717472 408096 309376 57% /mnt
//psy219.psy.msu.edu/h
1188608 996640 191968 84% /mnt2
Ok, here's the reads:
<bigger>eyelab:/usr/src# time cp /mnt/corel.zip .
0.92user 60.00system 6:02.07elapsed 16%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+0minor)pagefaults 0swaps
</bigger>
This yields a throughput of apx 224k/s (like I said, a lot higher than the last time I looked, I don't ever remember getting that type of throughput on smbfs before). Ok, now we have the write:
eyelab:/usr/src# time cp corel.zip /mnt
0.24user 136.71system 2:15:25elapsed 1%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+0minor)pagefaults 0swaps
Which yields a througput of apx 11k/s, which, while higher than what I mentioned in the previous note (although I have seen performance that low, I'm just unable to reproduce it on demand apparently :) ), is still a significant difference from the reads.
Potentially relevant statistics:
Eyelab is a 486dx2 66 with a couple of old ide drives in it, 20 megs of ram, and
an old 8 bit 3com network card.
Psy219 is a pentium 90, 16 megs of ram, the drive that was being written to is fairly new (and thus has pretty decent transfer rates), 16 bit intel etherexpress 16 card.
Both machines are on the same local subnet, ftp transfers in either direction typically run about 200k/s to 300k/s. Neither machine was heavily loaded at the time the task was being run (eyelab runs a light traffic web server and handles email, and typically has load averages of .1, psy219 was being used somewhat during the read test, and nobody was using it during the write test).
If anyone has suggestions for things that I should try out, I'm more than willing to give them a shot.
Gary Schrock
root@eyelab.msu.edu
| |