OT: PC Driving Me Nuts

By the way, no matter how expensive, they're *still* better than EMC.

Reply to
Huge
Loading thread data ...

So basically the Enterprise has gone SCSI (normally fibre channel or SAS, rather than parallel SCSI which is now dead), and the home/PC market has gone SATA. Cable lengths probably have a lot to do with this split, but it also simplies things in that Enterprise class drives are now only produced in FC and SAS formats, and home/PC class drives are now only produced in SATA formats.

Only Enterprise class SCSI drives are still manufactured, and they have different performance and life expectency from home/PC SATA drives, probably lower manufacturing volumes, and thus it's not surprising they cost more. Incidentally, the Enterprise class disks are much lower capacity than home/PC disks (I think around 500GB max at the moment), as it's not currently possible to achieve Enterprise life expectency and data integrity at the high data densities home/PC disks have reached.

Incidentally, the "disk mechanicals" are not the same. Only quite recently have home/PC SATA drives reached 10,000 RPM, whereas Enterprise disks have been 10,000 and 15,000 RPM for some time. Enterprise disks also have faster seek times, which is less of an issue for home/PC disks which normally run with write-caches enabled (a big no-no in the Enterprise world).

Reply to
Andrew Gabriel

Ah - thanks for that. Shall bear it in mind.

(Actually, we've got the IBM branded one. Don't. You get worse support, because you have to go via a clueless IBM numpty before you get to the people who made the thing :-( )

Reply to
Clive George

I still run mixed ATA/SCSI/SATA systems, and the performance difference on drives is quite noticeable. ATA and SATA seem mostly similar in real word usage, but for a while I was[1] running a 36GB enterprise class UWLVD SCSI drive as a main boot partition, and it would slash WinXP boot times to about a third of their typical.

[1] For some reason I could never get reliable operation on this drive in spite of being a SCSI veteran of many years and trying all the normal tricks. Its predecessor was a 18GB Barracuda which worked flawlessly until it failed under warranty, and the 36GB was its replacement. You would get occasional file corruption - which would then manifest as strange errors or more typically a failure to boot.
Reply to
John Rumm

I used to run all SCSI, but as the drives have gradually died I've replaced them with SATA, so that I now have one mixed system with the remaining SCSI drives attached to an LVD 160 card. Boot times are about the same for this as SATA, both noticeably faster than IDE.

This particular mixed PC kept giving me sudden freezes and the like, and when I examined the System Event log for those events that had managed to create one, SCSI was clearly implicated. Finally, almost in despair as being the only thing I hadn't tried, I swapped the tidy comparatively modern cable for an older one, the plastic wrapping of which has deteriorated to the point the individual strands were separating from each other! Despite the state of the old cable, the problems vanished, and as conviction grew in time the shiny newer one was consigned to the metals recycling box. I hate to tempt fate, but (touch wood), the PC's still working like that now, some years later.

I don't know if there's anything else I can suggest in your circumstances, as you claim to have tried a lot already, but for the benefit of others if not yourself, I have two pages on my website that might helpin such situations, one specifically about SCSI and other about diagnosing PC hardware faults ...

formatting link

Reply to
Java Jive

And by extension, Dell....

Reply to
Clint Sharp

In message , Huge writes

Problem is that they aren't. Most SCSI disks are much better quality than the IDE 'equivalent' IME.

I don't think you'll find that's the case any more. It certainly used to be (I've done it many times for personal use) but now the divide between the 'professional' and home product is too wide.

I suspect there is a considerably larger market for SATA/PATA drives and it's a volume thing along with a touch of enterprise mark up.

>
Reply to
Clint Sharp

Similar here really. I used to run lots of Amiga kit and hence using SCSI meant I could share stuff with the PC. But the list of SCSI kit I need to keep running is dwindling. The machine I am typing this on has a

8GB SCSI LVD boot drive on a AHA-2940U2W (plus a couple of DVD/CD devices), plus IDE and SATA additional drives. This one has always been fine.

The problem one (my games / video editing box) has a AHA-29160N with just a couple of scanners on it now. Its also got a striped set on a paradise PATA RAID controller.

One of Pournelle's laws IIRC - always suspect the cable.

Its a few years since I gave up fiddling with the problem drive, but I am fairly sure I tried alternate cables.

I have no particular need to get that drive working - although I suppose it is a shame having a high spec drive sit there doing nothing. Next time I rebuild this machine I may try swapping it in for the 8GB unit. It may be it will be happier running on the slower host adaptor.

on a 16 bit bus section though - I had to read it three times!)

Yup, pretty sure I tried all of those, which is why I took it out in the end. It was only the second SCSI device to ever cause me a problem. The first was a Conner CFP1060S 1GB SCSI drive (back in the days where 200MB was a big drive!) That turned out to have a firmware error that showed up on Linux, and as it also transpired Amigas. Fortunately they did a patch for it that fixed it.

Reply to
John Rumm

Thanks

That's still considerably less times than I have reworded it! :-)

Seriously though, it is a very complicated situation which I admit is not easy to explain, so it always was unlikely that I did a perfect job. If you wish, feel free to suggest a rewording of your own (bearing in mind the need to preserve sensible pagination if the content is printed), and if I think it's better, I'll amend the page accordingly.

I had one of those go down as well.

Reply to
Java Jive

Yes. I had a quick look at the booting section, and it's good.

A couple of comments -- There's about 440 bytes for the MBR code nowadays (more than half a sector). It used to be a few bytes more, but Vista decided to steal some space before the partition table for its own purposes, so you can't boot Vista if you go over 440 bytes of MBR code.

For the BIOS disk ids, 0 and 1 are the floppies, and 0x80 and

0x81 are the hard drives, which came along later ;-).
Reply to
Andrew Gabriel

Thanks also.

Yes, I should update or amend that - the actual amount used by the boot loader seems to depend on the make and era of the operating system that installed it.

But my point is that the disk designation depends on what of many programs you happen to be running. BIOS has one way of designating them, Diskprobe which you might use to troubleshoot the disk another, Ghost which you might use to back it and restore it another, and so on, so Disk 0 in one is something else in another.

Reply to
Java Jive

I'd go with this one.

Just jumper both items as 'cable select' ...

Reply to
Adrian C

I will see what I can do...

I had two - the original which I reflashed, and a second I bought a about year later (which had fixed firmware by then). The first one went on forever (10+ years in a fairly poorly ventilated box with constant use. I expect it still works!), the later one died after about four years IIRC.

Reply to
John Rumm

Probably worth noting that many SCSI hosts don't actually execute the boot sector code anyway, and use their own to get as far as the NT Loader stage.

Reply to
John Rumm

How about something like:

"While it is possible to connect a 'narrow' (8-bit) device to a 'wide' (16-bit) bus using a suitable 68 to 50 way adaptor, this should be avoided if possible, since it can introduce complications with bus termination. If your 16-bit card has a dedicated 8-bit connector, it is better to use that for 8-bit devices. Note however that with some cards (e.g. Adaptec's AHA-2940UW), even this does not necessarily solve the problems, since the 8-bit connector is still on the same physical 16 bit bus as the 16 bit connector, but connected only to the control bits and lower half of the 16 bit bus. This may mean that to get correct termination of the bus, you may need to apply it to the high and low sections of the bus in completely different places

For an explanation of this along with diagrams illustrating the various permitted layouts, the is FAQ from Adaptec."

Reply to
John Rumm

I think some of it must just be a hang-over from the early days when SASI was morphing into SCSI; there was an awful lot of pre-CCS stuff around which didn't support various commands that were later standard, and all sorts of devices that didn't cooperate well on the bus with each other because they misinterpreted the spec.

To be fair, it did seem to get better - so I suspect there were things going on in the early IDE days as I speculate about above with SCSI. But I still always found that SCSI storage out-performed IDE, plus it was useful being able to house the devices separate from the main machine (I so wish that SCSI supported hot-plugging as a fundamental part of the original spec!)

As others mentioned,

a) The drive mechanisms aren't always the same,

b) Vendors can do well by over-inflating prices for SCSI and selling to corporates whilst peddling lesser IDE solutions to the 'home' market.

In a way it's a pity IDE ever happened, but it was a logical progression from the ST506/412 drives which used to dominate the cheap end of the market.

cheers

Jules

Reply to
Jules

I've always thought of it as two separate 8-bit buses, and wide devices just happen to straddle the two at once. Terminate the end of each bus, avoid stubs, avoid automatic termination, use good-quality cables, ensure a good power supply, and things always seem to just work out.

Things only get really murky when connecting two SCSI controllers to the same bus (perfectly legal to do, but tends to involve some interesting software issues)

Around that sort of era Conner seemed to be total junk, regardless of the drive technology. They truly were awful, with firmware that was generally riddled with bugs and a healthy dislike for sharing a bus with anything from a different vendor...

cheers

Jules

Reply to
Jules

you are right harry, by the sound of this mobo.it's too old to recognise these devices as atapi and they should be connected as you say, hdd as primary master, and cd rom as secondary master.

Reply to
critcher

Indeed. Technically speaking the controllers are actually present on each SCSI device - the thing that interfaces to the computer is a host adaptor rather than a controller in the normal sense.

That particular drive (once fixed) seemed to play ball quite nicely with quite a full SCSI bus including CD ROMS, a tape streamer, Jaz drive, scanner, and some other hard drives. Had an Amiga at one end and a PC at the other as well.

Reply to
John Rumm

Thanks, and sorry for not replying sooner, been concentrating on something else.

The following seems to me an improvement taking the best bits of each and is still concise enough to maintain pagination ... Any advances?

""" If possible, avoid connecting to the same bus both 'wide' 16-bit and 'narrow' 8-bit devices (the latter using 68 to 50 way adaptors), as this can lead to performance and termination issues. Where 16-bit cards have an 8-bit connector, use that for 8-bit connections, but note that with some such cards, for example Adaptec's AHA-2940UW, these separate connectors may nevertheless actually be on one bus - the bus can be regarded as entering the controller via the 16-bit connector, the high 8 data bits end on the controller, while the low 8 data bits and the control bits continue out through the 8-bit connector. Additionally connecting external devices to the backplane complicates this situation still further. For an explanation of such complexities with diagrams illustrating the various permitted layouts, see Adaptec's FAQ. """

And later under Termination:

""" The controller may also be at one end of an internal cable on another connector. On some controllers, this might be an entirely separate secondary bus needing normal termination, but with Adaptec's AHA-2940UW we have also seen that this controller can be at the end of the high 8-bits of the main bus, and so should terminate them, while at the same time being in the middle of the low 8-bits and the control bits, and so should not! """

Please always reply to news group as the email address in this post's header does not exist. Alternatively, use the contact address at:

formatting link

Reply to
Java Jive

HomeOwnersHub website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.