Seth,
HeeHaw, that's it. Thanks much!
hdparm -d1 -X23 /dev/hda
Same dd test to xfs was 3 min instead of 22!
System cpu% single figures, response normal.
The over the wire test went from 26 min to 5,
achieving about 70mb through put.
Cheers, Gary
------------------------------------------------------
Gary Orser , (406) 994-6451, orser@xxxxxxxxxxxxxxxxxxx
Montana State University
Center for Computational Biology
1 Lewis Hall, Bozeman MT, 59717
On Thu, 30 Aug 2001, Seth Mos wrote:
> On Wed, 29 Aug 2001, Gary Orser wrote:
>
> > Tad,
> >
> > Hmm, It looks like nfs3 wasn't working.
> >
> > I upgraded to 4.5.9, with the 4.5.9-xfs patches
> > and now nfs3 works ok, however:
> > (must have been the version of nfs-utils)
> >
> > I just copied a large file from the sgi server to this linux box
> > (512m 1.4g Athlon) and the box got buried.
> >
> > Over a 100mb switched line a 3G file took 26 minutes, ok not spectacular.
> >
> > Load average was over 7, system cpu % was over 85%.
> >
> > The single processor on the origin 2000 (r10000) running nfsd was barely
> > turning over.
> >
> > Terminal response was just barely usable on the linux box.
> > (e.g. it took 4 min. to get top running in another console window)
> >
> > This was an ide drive but still...
>
> I think you will need to switch on DMA to get respons back from the box.
> This is very critical when using IDE drives. In PIO modes your CPU wll
> have to work harder.
>
> > Adding to this a little later on...
> > I did a little further stress testing
> >
> > dd if=/dev/zero of=./test bs=1M count=3000
> > xfs=23 mins
> > ext2=22 mins
> > eliminating nfs and xfs
> > same buried processor. It must be a kernel thing.
> >
> > kswapd and kupdated were the big cpu hogs, although
> > there was never any swap used.
>
> Sounds like your isn't using DMA.
>
> Cheers
> Seth
>
|