[ warning, i'm not a statistician, i just play one on the net... ]

> I have a 486DX/33 with a Ultrastor 14f and a 3com 3c509.
> There seems to be a performance problem if they are both
> 'active.'  i.e. iozone says ~310K to the local drive
> (a Micropolis 1588) which seems kind of slow, but is better
> than the ~20K I get via nfs/ftp/etc..  The other machine is
> a 486DX2/66 with IDE and a 3c509.  It seems to be fine.

OK, i seem to have a grasp of your hardware.

host	X	Y
speed	33	66
enet	509	509
disk	14f	IDE

however, i'm unclear what you mean:

> >From the 66 (to the 33) a 'get' transfers at ~320K/s, while
> a 'put' transfers at ~16K/s.

how are these measured?
Y % ftp X	then 'get file'?  'get file /dev/null'?
Y % ftp X	then 'put file'?  'put file /dev/null'?

did you try them one immediately following the other?  or perhaps
multiple times each?

> >From the 66, a 'get junk /dev/null' transfers at ~342K, while
> a 'get junk' transfers at ~25K.

i.e. 'B % ftp A' then 'get junk /dev/null' and 'get junk'?
If that's what you mean, it would seem that writing the file
to the (IDE) disk is cutting your throughput by a factor of 10...


unfortunately, for either, i'm not sure what you mean by "from the/to
the".

> I noticed that when doing the ftp get from the 66, the drive
> light on the 33 is pretty much solid, while during the ftp put
> the light hardly flashes, is this a problem, or is the data
> simply being cached?

it could be the buffer cache.

could you do the following:

on X:
cat /*bin/* > /dev/null
ftp Y		then 'put file_to_put'				(A)
ftp Y		then 'put file_to_put'				(B)
cat /*bin/* > /dev/null
ftp Y		then 'put file_to_put /dev/null'		(C)
ftp Y		then 'put file_to_put /dev/null'		(D)
rsh Y cat /*bin/* > /dev/null
ftp Y		then 'get file_to_get'				(E)
ftp Y		then 'get file_to_get'				(F)
rsh Y cat /*bin/* > /dev/null
ftp Y		then 'get file_to_get /dev/null'		(G)
ftp Y		then 'get file_to_get /dev/null'		(H)

do the mirror set of steps on B, after running
'cat /*bin/* > /dev/null' on each box, to clean out
the buffer cache.

you should pick file_to_get and file_to_put such that:
	(1) both fit into the buffer cache completely, and
	(2) neither are in /bin or /sbin of either machine.

That set of tests should give you some indication of what's up.

more or less:

if throughput increases dramatically from (C) to (D), then the
machine you're ftp'ing from is having problems when using the disk
and ethernet simultaneously.

if throughput increases dramatically from (G) to (H), then the
machine you're ftp'ing _to_ is having problems when using the disk
and ethernet simultaneously.

if only one of the machines is having problems A/B (i.e. the ratio
of the throughput from test (A) to the ratio of throughput from test (B))
should be approximately equal (or at least comparable to) to C/D, and
E/F should be approximately equal to (or at least comparable to) G/H.
What i mean is that if A = 20k/s and B = 200k/s, C and D might be,
say, 20-40k/s and 200-400k/s, give or take.  basically, check the
'sanity' of the results...  To make it a more realistic test,
you might want to use an MFS file rather than /dev/null in C, D, G,
and H, because then the normal buffer cache actions will be taken
when writing the file.

note that in a perfect world, A should be <= B, C should be <= D, E
should be <= F, and G should be <= H for each test.  (the reason is
that the first of each pair has to do the extra work of reading the
data off of the disk.) Unfortunately, since the files should be small
so that they fit in the buffer cache, their transfer times are
smaller, and thus the % error in reporting of both time to transfer
and throughput will be larger, so you can't guarantee that this'll be
true...

in general, though, if you've got disk/ethernet access problems, they're
most likely to show up in the (C) vs (D) and (G) vs (H) numbers.




chris

------------------------------------------------------------------------------