[2178] in linux-scsi channel archive
Re: SG_BIG_BUFF
daemon@ATHENA.MIT.EDU (Pete Popov)
Fri Jul 18 15:51:49 1997
To: Kai.Makisara@metla.fi
cc: linux-scsi@vger.rutgers.edu
In-reply-to: Your message of "Fri, 18 Jul 1997 10:09:53 +0300."
<Pine.OSF.3.96.970718095825.27434A-100000@abies.metla.fi>
Date: Fri, 18 Jul 1997 12:08:29 -0700
From: Pete Popov <pete@jones.asd.sel.sony.com>
> > Does anyone know if there is any reason why SG_BIG_BUFF is
> > limited to 32768 and ST_BUFFER_BLOCKS to 32?
> I don't want to comment on SG_BIG_BUFF (does not have any effect on tapes
> unless you use tapes through generic SCSI) but for ST_BUFFER_BLOCKS being 32
> there is a reason: once the buffers are allocated, they are not freed.
> This is because there with the current kernel memory allocation method
> it may not be possible to reallocate the buffer in future. The value 32
> seemed to me like a good compromise between throughput and "wasted"
> memory (and still seems so for most cases).
> It is completely safe to make ST_BUFFER_BLOCKS as large as the memory
> management allows on your hardware (256 for Alphas and 128 for others). If
> you want to save memory, you can tune the number of buffers allocated. See
> linux/drivers/scsi/README.st for details.
> Kai
Thank you for your reply. It sounds like it's safe to increase the
transfer size. I did some quick testing this morning and found that
my SDT-9000 (DDS3) tape drive can finally achieve a transfer rate
very close to its max. With 64KB transfers, in native mode, I got
1.12MB/sec; with 128KB I got 1.14MB/sec. Since the drive's native
transfer rate is 1.20MB/sec, I'm quite happy with the results. This
was something I was not able to achieve with 32KB transfer size under
Linux, let alone the tar default of 10KB/transfer.
Thanks again for your comments.
Pete
