Date: Thu, 21 Aug 1997 22:17:41 -0600 From: "Justin T. Gibbs" <gibbs@plutotech.com> To: dkelly@hiwaay.net Cc: freebsd-hardware@FreeBSD.ORG Subject: Re: Quiet SCSI disk? Message-ID: <199708220418.WAA05068@pluto.plutotech.com> In-Reply-To: Your message of "Thu, 21 Aug 1997 21:38:52 CDT." <199708220238.VAA07533@nospam.hiwaay.net>
next in thread | previous in thread | raw e-mail | index | archive | help
>> > [about the 4GB DCAS 34330W]
>> >
>> > >Do you know how many tags it uses (tagged command queuing) ?
>
>Wait! How to I querry the drive, kernel, SCSI card, etc, to know how
>many tags are being used? Is this a value which changes dynamically
>as the system is running?
Good question. There is no way to querry a device to determine how
many transactions it supports. You basically have to bombard it with
commands until it says, "I give up! I give up! QUEUE FULL! QUEUE FULL!".
You can think of this as the SCSI equivalent of crying 'Uncle!'
Currently in FreeBSD, the number of tags in use will fluctuate based on
load up to some set maximum. On the Adaptec aic7xxx cards, this maximum
is usually 8. On the NCR cards, the maximum is 4, but you can raise this
number via the ncrcontrol utility while the system is running.
In the future, the SCSI system will dynamically set the maximum on a per
device basis based on the capabilities of the controller, the number
of transactions active when a device returns QUEUE FULL status, and
any 'quirk table entries' that apply to the device. To use my own
system, which is running experimental CAM SCSI code that has these
features, as an example:
ahc0: <Adaptec 2940A Ultra SCSI host adapter> rev 0x01 int a irq 15 on pci0.10.0
ahc0: aic7860 Single Channel, SCSI Id=7, 3/255I SCBs
ahc1: <Adaptec 2940 Ultra SCSI host adapter> rev 0x00 int a irq 12 on pci0.12.0
ahc1: aic7880 Wide Channel, SCSI Id=7, 16/255 SCBs
Both adapters can support up to 255 transactions (adapter 0 using Indirect
paging, hence the 'I' in it's SCB count).
Now the devices:
da0 at ahc0 bus 0 target 0 lun 0
da0: <QUANTUM XP34550S LXQ1> Fixed Direct Access SCSI2 device
da0: Serial Number PCB=2011303001 ; HDA=184631651330
da0: 20.0MB/s transfers (20.0MHz, offset 15), Tagged Queueing Enabled
da0: 4341MB (8890760 512 byte sectors: 255H 63S/T 553C)
da1 at ahc0 bus 0 target 1 lun 0
da1: <QUANTUM XP39100S LXY4> Fixed Direct Access SCSI2 device
da1: Serial Number PCB=2011303101 ; HDA=189704332253
da1: 20.0MB/s transfers (20.0MHz, offset 15), Tagged Queueing Enabled
da1: 8682MB (17781520 512 byte sectors: 255H 63S/T 1106C)
da3 at ahc1 bus 0 target 1 lun 0
da3: <SEAGATE ST32155N 0318> Fixed Direct Access SCSI2 device
da3: Serial Number 0TC6BH
da3: 20.0MB/s transfers (20.0MHz, offset 15), Tagged Queueing Enabled
da3: 2049MB (4197405 512 byte sectors: 255H 63S/T 261C)
da5 at ahc1 bus 0 target 3 lun 0
da5: <SEAGATE ST32155N 0318> Fixed Direct Access SCSI2 device
da5: Serial Number 0T1G79
da5: 20.0MB/s transfers (20.0MHz, offset 15), Tagged Queueing Enabled
da5: 2049MB (4197405 512 byte sectors: 255H 63S/T 261C)
da4 at ahc1 bus 0 target 2 lun 0
da4: <SEAGATE ST32155N 0318> Fixed Direct Access SCSI2 device
da4: Serial Number 0S1Q7K
da4: 20.0MB/s transfers (20.0MHz, offset 15), Tagged Queueing Enabled
da4: 2049MB (4197405 512 byte sectors: 255H 63S/T 261C)
da2 at ahc1 bus 0 target 0 lun 0
da2: <SEAGATE ST32155N 0532> Fixed Direct Access SCSI2 device
da2: Serial Number 0S9NBW
da2: 20.0MB/s transfers (20.0MHz, offset 15), Tagged Queueing Enabled
da2: 2049MB (4197405 512 byte sectors: 255H 63S/T 261C)
The drives are attached in parallel and while the order of unit number
assignments is preserved, they are listed in the order that the probes
complete which is not necessarily the same order as the unit numbers.
It's a small price to pay for a much faster boot. The geometry is not
the geometry from mode page 5, but the translated geometry that the
controller exports. This means that utilities like fdisk will have the
appropriate geometry to use even on uninitialized disks. But I digress...
Here are the quirk entries that determine tag policy:
static struct xpt_quirk_entry xpt_quirk_table[] =
{
{
/* Reports QUEUE FULL for temporary resource shortages */
{ T_DIRECT, SIP_MEDIA_FIXED, quantum, "XP39100S", "LX??" },
/*quirks*/0, /*mintags*/24, /*maxtags*/32
},
{
/* Reports QUEUE FULL for temporary resource shortages */
{ T_DIRECT, SIP_MEDIA_FIXED, quantum, "XP34550S", "LX??" },
/*quirks*/0, /*mintags*/24, /*maxtags*/32
},
{
/* Broken tagged queueing drive */
{ T_DIRECT, SIP_MEDIA_FIXED, "HP", "C372*", "*" },
/*quirks*/0, /*mintags*/0, /*maxtags*/0
},
{
/* Default tagged queuing parameters for all devices */
{
T_ANY, SIP_MEDIA_REMOVABLE|SIP_MEDIA_FIXED,
/*vendor*/"*", /*product*/"*", /*revision*/"*"
},
/*quirks*/0, /*mintags*/2, /*maxtags*/64
},
};
And here are the interresting console messages:
Aug 16 03:30:16 dm /kernel: (da3:ahc1:0:1:0): tagged openings reduced to 63
Aug 20 16:14:00 dm /kernel: (da0:ahc0:0:0:0): tagged openings reduced to 31
Aug 20 16:14:00 dm /kernel: (da0:ahc0:0:0:0): tagged openings reduced to 29
The Seagate drives match the default quirk entry and so start out
with 64 tags. The system generated 64 transactions at one point
in time to one of these drives, got a QUEUE FULL status, and so
lowered the number of tags to 63. On the Atlas II, the drive will
report QUEUE FULL for temporary resource shortages, so we 'peg'
the number of tags to a number that gives decent performance (24).
Although this machine has seen two QUEUE FULL messages from the
Atlas II drive, it hasn't reduced the tag number to the lower limit
yet. I believe that the IBM drive that was mentioned earlier
behaves similarly to the Atlas II, so it may be beneficial to add
a quirk entry for it too.
The goal of this system is to make it so you don't have to worry
too much about the number of tags that are in use. Once the base
system is complete, however, additional facilities will be added
so that you can obtain performance statistics on all devices
including the number of transactions/sec and the maximum/average
number of transactions active.
>Others have mentioned the Symbios cards and Adaptec cards. How does
>this relate? Is one clearly superior to the other in this respect?
Performance wise, I believe that they are very similar. Cost wise,
the Symbios cards are a clear winner. Support wise, all I can say is
that the new CAM code will have aic7xxx support before Symbios support
(actually, it has aic7xxx support now), but that both will be equally
well supported by the time that the new SCSI code enters the tree
(late this year).
>The Adaptec 3940 has
>an advantage in large systems such as ftp.cdrom.com by providing dual
>SCSI buses on one PCI card.
I've heard that there is a new Symbios controller that supports two
busses without the added overhead of a PCI->PCI bridge. I don't know
if Stefan has added support for it yet. I do know that the driver in
current does support Ultra speeds though.
>--
>David Kelly N4HHE, dkelly@hiwaay.net
>=====================================================================
>The human mind ordinarily operates at only ten percent of its
>capacity -- the rest is overhead for the operating system.
>
>
>
--
Justin T. Gibbs
===========================================
FreeBSD: Turning PCs into workstations
===========================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708220418.WAA05068>