From owner-aic7xxx Fri Aug 14 14:33:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA16983 for aic7xxx-outgoing; Fri, 14 Aug 1998 14:33:17 -0700 (PDT) (envelope-from owner-aic7xxx@FreeBSD.ORG) Received: from eta.ghs.com (eta.ghs.com [208.8.104.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA16978 for ; Fri, 14 Aug 1998 14:33:16 -0700 (PDT) (envelope-from ross@teraflop.com) Received: from random.teraflop.com (random.teraflop.com [192.67.158.207]) by eta.ghs.com (8.8.5/8.7.3) with ESMTP id OAA11560; Fri, 14 Aug 1998 14:31:17 -0700 (PDT) Received: (from ross@localhost) by random.teraflop.com (8.8.8/8.8.8) id OAA20416; Fri, 14 Aug 1998 14:31:17 -0700 (PDT) Date: Fri, 14 Aug 1998 14:31:17 -0700 (PDT) From: Ross Harvey Message-Id: <199808142131.OAA20416@random.teraflop.com> To: gibbs@narnia.plutotech.com, matti.aarnio@sonera.fi Subject: Re: AHA2790UW has speed-limit problems ? Cc: aic7xxx@FreeBSD.ORG Sender: owner-aic7xxx@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > From: "Justin T. Gibbs" > [ Matti Aarnio ] > > > Four Ultra-Wide (SingleEnded) disks on high quality cable inside > > DEC PWS 433a workstation chassis attached to AHA2940UW host adapter. > > ::: > > The Kludge-Cure: > > > > Lower the speed of the device in the adapter bios configuration > > utility. In fact lower them all, and no SCSI-timeout problems appear. > > This would indicate bus signal quatlity problems at high speeds. I would agree that this sounds like a signal integrity problem. If you have more than one or two drives you either go differential or you have a statistically significant chance of suffering like this. Sure, you can eventually get the singled-ended big system to work, somehow, but was it worth it? You would never have this problems in a differential chain. Your fundamental problem is that you are trying to do something that single-ended SCSI was not intended for. The spec recommends against this. (Actually, SCSI-2 recommended against using single-ended _at all_ in fast sync mode, but of course this recommendation is almost universally ignored.) The surprising thing isn't when it doesn't work, but when it does. > > > Question: > > > > Is there ANYTHING that is possible to do to in this type of environment > > so that I could (reliably) run faster disk-transfer speeds ? > > Shorten the cables. Ensure that the distance between all connectors on > the cable are equal. Use a forced perfect terminator. Shortening the cables might help, but what is the principle behind equalizing the inter-tap distance? I would have guessed that intentionally non-equal intermediate segments would prevent the superposition of reflections from the stubs that fork the transmission line at each drive. I would worry more about (1) PVC cables; (2) segments less than 0.3m (stub clustering lumps loads and aggregates the impedance mismatch); (3) cheap terminators (FPT was a good recommendation); (4) unused segments or stubs, i.e., don't run a cable to the back panel if you aren't using it. I suspect that people think equalizing segment lengths helps because it forces them to use the recommended minimum stub (load) spacing. But what makes this win is the elimination of stub clusters, not the equalization of segment runs. --Ross Harvey To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe aic7xxx" in the body of the message