blakerwry said:
Would a full duplex interface really be beneficial when the disks themselves are half duplex by design (cannot read/write simultanesouly, even to the buffer)?
I imagine the more independent disks you have, the more beneficial it would be. Along with higher queue depth. But only to a point.
Full-duplex communications hasn't anything to do with the drive heads, this only concerns the drive controller circuits and its buffer.
A full-duplex storage device channel *can* be more efficient than a half-duplex channel -- but it depends. A full-duplex channel becomes more beneficial as you begin having higher storage device channel loading. Of course, the host computer needs to be running an operating system capable of multi-threading. In other words, forget MS/DR/PC-DOS and Win9X if you want to take full advantage of full-duplex storage device channels.
I would think having more channels would be a better solution (and one that's obviously already being implemented)
Multiple channels to the same drive? That's not going to gain you anything except complexity and expense. The whole idea is to use a fast simple serial channel physical interface with a communications rate that's higher than the hard drive's media rate -- and in the case of copper, a differential interface and twisted pair cabling with the proper twist ratio that uses common mode rejection -- to reduce various very well-known communication problems that exist with parallel interfaces.
as far as I know memory can either be written to or read from, but not both simultaneoulsy. Meaning that you can have a write, and then a read, but there has to be some time inbetween the two. This is a fundamental design of electronic memory.
Unfortunately, that is not so. Memory devices that simultaneously read AND write have been around for quite a long while. Dual-ported RAM (and there are a LOT of dual-ported memory types out there!) as well as the newer and more complex multi-ported memories can do the job very well indeed.
So even the buffer is not full duplex by design and thus the drive cannot be sending information from the buffer while receiving commands unless it has seperate buffers for the incoming commands and incoming/outgoing data. To create a truely full deplex disk requires a minimum of two distinct buffers, a 3 buffer design also seems probable.
Disc drives don't use a complex split buffer design, just nice efficient reliable ECC FIFO buffers.
This seems like a high cost for what, in my mind, is little benefit.
The benefit of full-duplex communications is absolutely REAL. Fibre-Channel SANs prove that every day.
However, if I could only have one of the following -- full-duplex communications or command queuing -- I'd take command queuing, because I already know that command queuing can bring a greater level of efficiency to hard drive storage throughput than full-duplex communications.
The way IDE has gotten around the problem of being half duplex while maintaining high speed levels with newer disk drives is by using an interface far faster than the media's capabilities. That way there always exists times when data is not being sent from the drive and it's during those times that data can be sent to the drive without negatively impacting the data transfer coming out of the drive.
Actually, way the hell back in the mid-80s when Compaq and Western Digital first came up with the IDE hard drive concept, the target computing environment was the desktop computer running MS-DOS. So, in continuance with what I was talking about earlier, no DOS user needed a hard drive controller or a communications channel that utilised full-duplex communications (in this case, over a parallel cable).
