>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