Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 8 Apr 1998 11:05:44 -0400 (EDT)
From:      Kyle McPeek <kyle@stdio.com>
To:        Tom <tom@sdf.com>
Cc:        freebsd-scsi@FreeBSD.ORG
Subject:   Re: CAM Performance...
Message-ID:  <Pine.SUN.3.91.980408090148.15453A-100000@heathers2.stdio.com>
In-Reply-To: <Pine.BSF.3.95q.980407151409.1914A-100000@misery.sdf.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Tom,

I forgot to mention the nfs file server is a network appliance, raid 4 
and very fast.  Very few things I can do to tune it.  I don't think any 
improvements can be found there, except maybe nfs V3?

The network is all 100MB switched.  I have tested both 10 and 100mb 
speeds and the transfer rate at 100mb is about twice that of 10mb.  10 MB 
seems to be slowed down by the network, but 100mb appears to be slowed 
down by the disk.

The clients all have 64meg of memory.  Would softupdates help on an 
unmounted partition?

I will try 64K blocks.  

kyle.

On Tue, 7 Apr 1998, Tom wrote:

> 
> On Tue, 7 Apr 1998, Kyle McPeek wrote:
> 
> > Hi All,
> > 
> > For a project at work I need to be able to write 400MB sequentially to an 
> > Ultra-Wide harddisk (Seagate ST32171W 2GB) from an nfs mounted drive as 
> > fast a possible.  right now we have it down to around 3:45 seconds using 
> > the old scsi code.
> > 
> > I am using dd with bs=27163 (Approximately = data on one track) to write 
> > to /dev/rsd0s2c.
> 
>   Why that block size?  I think you will be much better with 64k blocks.
> How a particular drive organizes data to tracks is almost impossible to
> tell.  Using a block size which is not a multiple of 512 almost certainly
> slows things down.
> 
>   Since you going for NFS to disk, is the bottleneck the disk or the
> network?  If it is the disk, use two stripped drives for better
> performance.  
> 
> > Would the cam code improve sequential scsi writes?  Also, what sort of 
> > general speed improvements has everyone seen using the cam code?
> 
>   Probably not.  CAMs main benefits are better error recovery, and better
> handling of lots of simultaneous i/o.
> 
>   Softupdates would improve things a lot for this application (esp if you 
> have lots of RAM), but they don't work yet
> 
> > I do still plan to test the cam code myself, but I would like to know 
> > what other people have experienced.
> > 
> > Kyle McPeek
> > TEKsystems Consultant at 
> > Lexmark International.
> 
> Tom
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-scsi" in the body of the message
> 

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.91.980408090148.15453A-100000>