🚀 go-pugleaf

 >>No, Patrick isn't talking nonsense. The test in the latest c't clearly
 >>shows that the SCSI interface on the Fireball is not capable of
 >>sustaining the kind of transfer rate the drive achieves on the outer
 >>tracks.  ....

bb@wjh.harvard.edu (Brent Byer) writes:

 >Yup.  Based on the specs (5400rpm, 177 sectors/track [outer]),
 >it is spinning 8MB/sec.  If, in fact, its SCSI interface can't
 >handle that throughput, then the Quantum engineers blew it.
 >
 >If they couldn't speed up the interface, it seems they should
 >have re-done the disk layout so that there were fewer sectors/trk
 >and more cylinders (ie, same capacity [cf IBM DeskstarXP]).

It looks like Quantum's aim was first and foremost to make the fastest
low-cost EIDE drive in the 1GB class. And with resounding success. The
SCSI interface was characterized by the c't as "lieblos" (loveless).
Maybe the SCSI version was indeed almost an afterthought.

 >There's an interesting gotcha lurking here ... with the
 >Fireball's puny 128K cache, and 48K of that being used
 >for firmware (see specs), they can't buffer one full
 >(outer) track!  Unless my own (organic) logic is faulty,
 >it sounds like they really lose when they lose.

You're right. I hadn't thought of that. Funny thing is, that doesn't
show up in terms of transfer rate. The c't would've remarked on that.

 >I might be wrong, though, since Kevin Martinez's "Sequential
 >Read Performance" graph for the Fireball 1080S shows no
 >significant discontinuity for large transfer sizes.  It
 >gets 5MB/sec when doing transfers of 64KB-256KB ea.  Hmmmm....

I don't doubt the validity of Kevin's data. It would be interesting
to test the Fireballs on a wide range of configurations.

Quantum? What about a Fireball Pro[tm] with 256k or 512k cache?

 - Peter