CDB or way to get negotiated SCSI Speed of a HDD

Through a CDB or some other way I need to try to find out what the negotiated speed of my SCSI HDD is after post.  Does anybody know how to get this information from the drive or maybe from a standard 39160 controller?  I would much rather query the drive than the controller.

Thanks
LVL 6
CowboyJeeperAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

SysExpertCommented:
I would check the adpatec site for utilities that may help out for this.

Some general SCSI utiliies may also have this.

I hope this helps !
0
chicagoanCommented:
Adaptec's tools are pretty dated and I wouldn't try to load them on anything newer than NT. The 39160 displays the negotiated speed at post, if you want to tune your scsi bus, take a look at http://www.micro-magic.com/scsimechaniceval/
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
ESQuicksallCommented:
I don't see my previous answer posted so I'll do it again (with a little more information).

There is no mode page with the results of an SDTR (Synchronous Data Transfer Request - in short speed).  I don't think the protocol would allow it.  Consider the consequences.  If we changed a mode page to reflect the revised speed, we'd have to send a unit attention to indicate that the mode page changed.  That means a check condition, so we'd have to negotiate the speed all over again!

FYI: It's a well-known flaw in the parallel version of the SCSI protocol.  When you (the initiator) get a CHECK CONDITION, you don't know the reason until you send a REQUEST SENSE and the target sends you data.  If the reason was indeed a power-on or other reset (not necessarily a bus reset), then the target would be sending you async data, waiting for a REQ/ACK handshake, and you'd still be trying to clock it in synchronously.  That causes a bus hang.  

To avoid the mismatch between the initiator's and target's negotiated speeds, every parallel initiator I know of does a renegotiation after each check condition.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Storage

From novice to tech pro — start learning today.