Hacker News new | ask | show | jobs
by Dylan16807 1922 days ago
Since you added a huge amount since I replied, I'll make a separate reply.

> But you know what will be worse? Dual actuator drives. Why? Because of what dragontamer (who was right) mentioned, which you overlooked: the two actuators serve disjoint sets of blocks.

They don't have to do that.

I was talking about what you can do with dual actuators, not product lines that already exist.

I didn't realize how mach.2 was designed, though. That's a shame.

> But here's the kicker: they still share some resources that are subject to contention - most notably the external interface.

Each head, even at peak transfer rate, uses less than half the bandwidth of the external interface.

So even if both of them are hitting peak rates at the same time, and the drive alternates transfers between them, things are fine. For example, let's say 128KB chunks, alternating back and forth. Those take .2 milliseconds to transfer. That makes basically no difference on a hard drive.

> Doubled performance is an absolute best case which is never achieved in practice, and I say that because I've seen it.

I completely believe you, about drives where each arm can only access half the data.

> The only way dual actuators can really compete with separate drives is to duplicate all of the resources that change behavior based on the request stream - interfaces, controllers, etc.

Or upgrade them to 1200Mbps, which isn't a very hard thing to do.

1 comments

> I was talking about what you can do with dual actuators, not product lines that already exist.

Since you didn't know they're different until a moment ago, you were talking about both. Don't gaslight.

> Each head, even at peak transfer rate, uses less than half the bandwidth of the external interface.

So two will come damn close ... today. With an expectation that internal transfer rates will increase faster than standards-bound external rates. And the fact that no interface ever meets its nominal bps for a million reasons. Requests have overhead, interface chips have their own limits, signal-quality issues cause losses and retries (or step down down lower rates), etc. Lastly, request streams are never perfectly balanced except for trivial (mostly synthetic-benchmark) cases, and the drive can't do better than the request stream allows. There are so many potential bottlenecks here that any given use case is sure to hit one ... as actually seems to be the case empirically. Your theory remains theory, but facts remain facts.