Synchronous SCSI at 10MB/s on Lombard? (fwd)

Synchronous SCSI at 10MB/s on Lombard? (fwd)

[Derek Homeier]

Sorry for crossposting, but I didn't get any response to this on the
user list.
---------- Forwarded message ----------
Date: Tue, 21 Mar 2000 02:12:47 +0100 (MET)
From: Derek Homeier <supas100@astrophysik.uni-kiel.de>
To: linuxppc-user@lists.linuxppc.org
Subject: Synchronous SCSI at 10MB/s on Lombard?

One more question...

Has anyone tried to set the rate for synchronous SCSI tranfer for the MESH
controller in the G3 series Powerbooks to 10? The kernel docs claim it does
10 MB/sec on machines where the bus is internal only:

CONFIG_SCSI_MESH_SYNC_RATE:                                                 x
  x                                                                         x
  x On Power Macintoshes (and clones) where the MESH SCSI bus adaptor       x
  x drives a bus which is entirely internal to the machine (such as the     x
  x 7500, 7600, 8500, etc.), the MESH is capable of synchronous             x
  x operation at up to 10 MB/s. On machines where the SCSI bus              x
  x controlled by the MESH can have external devices connected, it is       x
  x usually rated at 5 MB/s. 5 is a safe value here unless you know the     x
  x MESH SCSI bus is internal only; in that case you can say 10. Say 0      x
  x to disable synchronous operation.                                       x

but for an uneducated test I have set it to 10, and this seems to work so
far on my Lombard. The throughput as reported by hdparm has effectively
doubled (from 3.3 to 6.6 MB/s), so does anyone know whether this is
safe or there are any dangers implied when setting the transfer rate that
high (if it only you could call this high!) on the external bus?

Thanks for any advice,
							Derek


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Synchronous SCSI at 10MB/s on Lombard? (fwd)

[Joseph Garcia]

Derek Homeier wrote:
> Has anyone tried to set the rate for synchronous SCSI tranfer for the MESH
> controller in the G3 series Powerbooks to 10? The kernel docs claim it does
> 10 MB/sec on machines where the bus is internal only:

I have tried it on my PDQ/300.  My SyQuest worked fine, but according to /proc,
it was still running at 5.  however, my yamaha cdrw did not work.  set 5, it
reports its sync speed is 4.2.  when MESH is told to max at 10, my RW is still
recognized, reports 8.4, but does not respond to mounting, reading, nor
writing.  It could be that the 6.6 you have achieved is still doable, but my 8.4
is not. so setting MESH to 7 or 8 may be a safer fast speed.  havent tried it
though.

--
Joseph P. Garcia      jpgarcia@execpc.com      jpgarcia@lidar.ssec.wisc.edu
CS Undergraduate                      Student Employee - Systems Programmer
University of Wisconsin - Madison                            UW Lidar Group

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Synchronous SCSI at 10MB/s on Lombard? (fwd)

[Derek Homeier]

On Thu, 23 Mar 2000, Joseph Garcia wrote:

> Derek Homeier wrote:
> > Has anyone tried to set the rate for synchronous SCSI tranfer for the MESH
> > controller in the G3 series Powerbooks to 10? The kernel docs claim it does
> > 10 MB/sec on machines where the bus is internal only:
>
> I have tried it on my PDQ/300.  My SyQuest worked fine, but according to /proc,
> it was still running at 5.  however, my yamaha cdrw did not work.  set 5, it
> reports its sync speed is 4.2.  when MESH is told to max at 10, my RW is still
> recognized, reports 8.4, but does not respond to mounting, reading, nor
> writing.  It could be that the 6.6 you have achieved is still doable, but my 8.4
> is not. so setting MESH to 7 or 8 may be a safer fast speed.  havent tried it
> though.
>
I didn't know you could set it at some speed in between - I rather thought
these were basically two different settings, with 5 or 10 MB/s being the
nominal transfer rate, and actual transfer rating below that. According
to dmesg my Orb drive is found and communicated at 10MB/s, thus the 6.6
(as the 3.3 in the slower mode) would seem to be limited by the controller.
I always heard the Mac SCSI controllers were quite slow, 3-3.5 MB/s being
a common rate for the external bus. The continuous r/w performance of the Orb
itself is much higher, ~ 12 MB/s. For real world performance, I'm getting
about 4.5 MB/s read/write on larger files (in fast mode).
I had some problems with the drive initially, but they also occured with
the driver set to slow mode, and mostly seem to have settled now.
But maybe this is a safe setting only for HD devices, as I frequently hear
that you shouldn't mix HDs and CDROMs, scanners etc. on one chain, the
latter seem to tend to have worse SCSI implementation.

Thanks,
							Derek

--
Derek Homeier                                           Tel: +49-431-880-4103
Institut fuer Theoretische Physik und Astrophysik       Fax: +49-431-880-4100
der Christian-Albrechts-Universitaet                    Feet:        Room 142
D-24098 Kiel, Germany		      email:  homeier@astrophysik.uni-kiel.de
-----------------------------------------------------------------------------


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Synchronous SCSI at 10MB/s on Lombard? (fwd)

[Joseph Garcia]

Derek Homeier wrote:
> I didn't know you could set it at some speed in between - I rather thought
> these were basically two different settings, with 5 or 10 MB/s being the
> nominal transfer rate, and actual transfer rating below that. According

I'm not sure myself.  never tried it. ^_^;

> to dmesg my Orb drive is found and communicated at 10MB/s, thus the 6.6
...
> that you shouldn't mix HDs and CDROMs, scanners etc. on one chain, the
> latter seem to tend to have worse SCSI implementation.

Thats interesting.  I will have to try that some time.  Right now, my chain has
the CDRW after the Syquest, and I never figured in the potential sync problems.
However, I recall one of my friends mentioning that 10M/s should not be possible
because the compact connector on powerbooks is missing those extra 12 or so pins
needed.  Maybe the Orb is reporting 10, but falling back or compensating for the
lack of pins.  Or maybe connectors have changed.  My chain's Syquest has a
Centronix connector, my RW has a 50 pin mini-trapezoid.  Could explain some
things.  Whatever works i guess.

--
Joseph P. Garcia      jpgarcia@execpc.com      jpgarcia@lidar.ssec.wisc.edu
CS Undergraduate                      Student Employee - Systems Programmer
University of Wisconsin - Madison                            UW Lidar Group

"Ask yourself, Why do you seek the developer kernel?  Is it for its glory,
 or for yours?"

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Synchronous SCSI at 10MB/s on Lombard? (fwd)

[Dan Bethe]

> far on my Lombard. The throughput as reported by hdparm has
> effectively
> doubled (from 3.3 to 6.6 MB/s), so does anyone know whether this is
> safe or there are any dangers implied when setting the transfer rate
> that
> high (if it only you could call this high!) on the external bus?

	I second the question.  And what does "safe" mean?  Could these
aggressive settings damage your data, your hardware, or both?  If it's
just data, then that's okay for me to try.  I'll turn it off when I
find corrupted data.
	Thanks!

=====
"Don't expect your own messiah; this neverworld which you desire is
only in your mind." -- http://www.dreamtheater.net/songb4.htm#IV5


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Synchronous SCSI at 10MB/s on Lombard? (fwd)

[Michel Lanners]

Hi all,

On  23 Mar, this message from Joseph Garcia echoed through cyberspace:
> Derek Homeier wrote:
>> I didn't know you could set it at some speed in between - I rather thought
>> these were basically two different settings, with 5 or 10 MB/s being the
>> nominal transfer rate, and actual transfer rating below that. According

That's my understanding as well. The 5MB/s or 10 MB/s is the raw byte
througput of the SCSI bus; for net rate, you have to count driver
overhead, command overhead, idle times on the bus, disk slowness, etc...

>> to dmesg my Orb drive is found and communicated at 10MB/s, thus the 6.6
> ...
>> that you shouldn't mix HDs and CDROMs, scanners etc. on one chain, the
>> latter seem to tend to have worse SCSI implementation.
>
> Thats interesting.  I will have to try that some time.  Right now, my chain has
> the CDRW after the Syquest, and I never figured in the potential sync problems.

On my 7600's internal MESH, I had both hard drives (sync at 10MB/s) and
the factory-installed CDROM (sync at 5MB/s) and never had any
particular problem. SCSI host adapters do negotiate separate parameters
per target; that's how you can mix narrow and wide devices on one bus,
by the way.

> However, I recall one of my friends mentioning that 10M/s should not be possible
> because the compact connector on powerbooks is missing those extra 12 or so pins
> needed.  Maybe the Orb is reporting 10, but falling back or compensating for the
> lack of pins.  Or maybe connectors have changed.  My chain's Syquest has a
> Centronix connector, my RW has a 50 pin mini-trapezoid.  Could explain some
> things.  Whatever works i guess.

No, no, there's nothing with pin count involved here. Macs have always
had narrow buses (i.e. 8bits wide), and the difference in pin count of
the connector is compensated by having different numbers of ground
pins. On good cable material, this should have no influence on
throughput.

On  23 Mar, this message from Dan Bethe echoed through cyberspace:
> 	I second the question.  And what does "safe" mean?  Could these
> aggressive settings damage your data, your hardware, or both?  If it's
> just data, then that's okay for me to try.  I'll turn it off when I
> find corrupted data.

Setting the speed too high might corrupt data, but will never damage
hardware. As stated above, host and target negotiate a compatible set
of settings; this should already guarantee valid data transfers. The
reason Apple states 5MB/s as limit for external buses is to depend less
on the quality of the cables involved, and to permit longer chains
conneting many external devices. Think 'hassle-free plug&play'....

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Synchronous SCSI at 10MB/s on Lombard? (fwd)

[Iain Sandoe]

>
>> far on my Lombard. The throughput as reported by hdparm has
>> effectively
>> doubled (from 3.3 to 6.6 MB/s), so does anyone know whether this is
>> safe or there are any dangers implied when setting the transfer rate
>> that
>> high (if it only you could call this high!) on the external bus?
>
>  I second the question.  And what does "safe" mean?  Could these
> aggressive settings damage your data, your hardware, or both?  If it's
> just data, then that's okay for me to try.  I'll turn it off when I
> find corrupted data.
>  Thanks!

"Safe" is a bit tricky in this case - it is likely to be
temperature-dependent and subject to fairly random behaviour when you get
close to the limit.

Most likely the data is at highest risk - with the possibility of trashing
the entire disk (rather than just Linux partitions).

It is very hard to see a way in which the H/W could be damaged because most
aspects of the scsi transfer are negotiated.  You would have to work fairly
hard a finding a series of catastrophic failures resulting in overheating...

apropos the number of pins:
There are two reasons for more pins on scsi
1/ to use a differential bus - which was also an option on scsi-1

This allows longer interconnect and/or greater noise immunity.

2/ to have access to the UW/scsi-2/3 features

(e.g. more data or address bits).

AKAIK the Macs have never had any external (or 'standard' internal) busses
that were differential (although maybe the IIfx did).  There are some cards
like that that were installed as standard - e.g. on my G3/Minitower - but
it's usually link-selectable anyway.

apropos chaining different devices:
A number of scsi drivers (e.g. IIRC the ones one the suns) used to probe at
different rates (for sync operation) and back off to the lowest rate that
worked in the chain.

I don't know if this principle is used by the Linux drivers (but I'm sure
some guru will comment).

AFAIK this is necessary at some stages of the bus negotiation - although
once the transaction is agreed there may be the option of going faster (hmmm
seems a bit dodgy electrically).

Anyway this was/still is a good reason for separating high performance
devices from low.

Personally, the pain of dealing with an unreliable and unpredictable system
doesn't seem worth push one's luck ;-)

By far the best solution is to check the specs on the devices you have
(usually obtainable on the www), and take a peek at the ANSIs for SCSI
(although you might have to buy these or get them through a library).

Iain.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Synchronous SCSI at 10MB/s on Lombard? (fwd)

[Derek Homeier]

On Fri, 24 Mar 2000 11:46:30 +0000, Iain Sandoe <iain@sandoe.co.uk> wrote:

>>  I second the question.  And what does "safe" mean?  Could these
>> aggressive settings damage your data, your hardware, or both?  If it's
>> just data, then that's okay for me to try.  I'll turn it off when I
>> find corrupted data.
>>  Thanks!
>
> "Safe" is a bit tricky in this case - it is likely to be
> temperature-dependent and subject to fairly random behaviour when you get
> close to the limit.
>
> Most likely the data is at highest risk - with the possibility of trashing
> the entire disk (rather than just Linux partitions).
>
> It is very hard to see a way in which the H/W could be damaged because most
> aspects of the scsi transfer are negotiated.  You would have to work fairly
> hard a finding a series of catastrophic failures resulting in overheating...
>
> aspects of the scsi transfer are negotiated.  You would have to work fairly
> hard a finding a series of catastrophic failures resulting in overheating...
>
> apropos the number of pins:
> There are two reasons for more pins on scsi
> 1/ to use a differential bus - which was also an option on scsi-1
>
> This allows longer interconnect and/or greater noise immunity.
>
> 2/ to have access to the UW/scsi-2/3 features
>
> (e.g. more data or address bits).
>
> AKAIK the Macs have never had any external (or 'standard' internal) busses
> that were differential (although maybe the IIfx did).  There are some cards
> like that that were installed as standard - e.g. on my G3/Minitower - but
> it's usually link-selectable anyway.
>
> apropos chaining different devices:
> A number of scsi drivers (e.g. IIRC the ones one the suns) used to probe at
> different rates (for sync operation) and back off to the lowest rate that
> worked in the chain.
>
> I don't know if this principle is used by the Linux drivers (but I'm sure
> some guru will comment).
>
> AFAIK this is necessary at some stages of the bus negotiation - although
> once the transaction is agreed there may be the option of going faster (hmmm
> seems a bit dodgy electrically).
>
> Anyway this was/still is a good reason for separating high performance
> devices from low.
>
> Personally, the pain of dealing with an unreliable and unpredictable system
> doesn't seem worth push one's luck ;-)
>
> By far the best solution is to check the specs on the devices you have
> (usually obtainable on the www), and take a peek at the ANSIs for SCSI
> (although you might have to buy these or get them through a library).
>
Thanks a lot, hardware damage was also my main concern. This and Michel's
poting pretty much cleared anything I wanted to know. I haven't seen any
messages about scsi negotiation errors so far, so I guess I'll push my
luck a little farther ;^).
I had a lot of scsi troubles with an external hd and a Tandberg tape under
mklinux, mostly due to a bad quality cable and bad termination, but then
the Mach Kernel spew tons of error messages at me.
The Orb is capable of Ultra scsi, so I suppose fast scsi should pose no
problems on this side. I haven't tried to hook the tape drive to that chain,
maybe I'll test it, too, but I'd have to get another adapter cable first
(and a good one, this time!), now having to connect 25-pin sub-D, 50-pin HD
and a Centronix connector |-(.

Cheers,
							Derek


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/