New hard disk architectures

On Fri, 23 Dec 2005 16:52:23 +0100, daytripper
wrote:

On Fri, 23 Dec 2005 06:14:16 +0100, "hackbox.info"

wrote:

On Mon, 19 Dec 2005 17:07:35 +0100, Yousuf Khan wrote:

They're just saying they can do a more efficient error correction over
4096 byte sectors rather than 512 byte sectors.

and its not only about capacity, speed maters too

Huh?

what is faster, four calls to crc routine or one call? This is an
unnecessary overhead for the drives firmware

--
I really have no idea what this means. And since I can't install linux on
it, I'm gonna go back to surfing pr0n.
the penguins are psychotic / just smile and wave

On Fri, 23 Dec 2005 17:09:55 +0100, "hackbox.info"
wrote:

On Fri, 23 Dec 2005 16:52:23 +0100, daytripper
wrote:

On Fri, 23 Dec 2005 06:14:16 +0100, "hackbox.info"

wrote:

On Mon, 19 Dec 2005 17:07:35 +0100, Yousuf Khan wrote:

They're just saying they can do a more efficient error correction over
4096 byte sectors rather than 512 byte sectors.

and its not only about capacity, speed maters too

Huh?

what is faster, four calls to crc routine or one call? This is an
unnecessary overhead for the drives firmware

What makes you think crc generation is handled by firmware?

I really have no idea what this means. And since I can't install linux on
it, I'm gonna go back to surfing pr0n.

Still think that ought to be "p0rn"...

On Fri, 23 Dec 2005 15:35:31 -0500, daytripper
wrote:

I really have no idea what this means. And since I can't install linux on
it, I'm gonna go back to surfing pr0n.

Still think that ought to be "p0rn"...

both are acceptable in current netspeak AFAIK, i think pr0n came about
as an attempt to defeat censor filters that might otherwise censor out
p[o|0]rn
--
A Lost Angel, fallen from heaven
Lost in dreams, Lost in aspirations,
Lost to the world, Lost to myself

On Fri, 23 Dec 2005 21:35:31 +0100, daytripper
wrote:

what is faster, four calls to crc routine or one call? This is an
unnecessary overhead for the drives firmware

What makes you think crc generation is handled by firmware?

Wild guess. It may be on ASIC, but I personally would put it in fpga or
firmware (primary, secondary is loaded from magnetic media on start).

I really have no idea what this means. And since I can't install linux
on
it, I'm gonna go back to surfing pr0n.
Still think that ought to be "p0rn"...

google it, second link, its a quote

--
I really have no idea what this means. And since I can't install linux on
it, I'm gonna go back to surfing pr0n.
the penguins are psychotic / just smile and wave

On Sat, 24 Dec 2005 16:13:44 +0100, "hackbox.info"
wrote:

On Fri, 23 Dec 2005 21:35:31 +0100, daytripper
wrote:

what is faster, four calls to crc routine or one call? This is an
unnecessary overhead for the drives firmware

What makes you think crc generation is handled by firmware?

Wild guess. It may be on ASIC, but I personally would put it in fpga or
firmware (primary, secondary is loaded from magnetic media on start).

That's the problem with wild guesses, they're usually wrong. There's little
reason to push media ECC and interface CRC out of controller Si and into a uP,
these are well-understood, highly developed algorithms that are best embedded
where they won't be a throttling influence.

I really have no idea what this means. And since I can't install linux
on it, I'm gonna go back to surfing pr0n.
Still think that ought to be "p0rn"...

google it, second link, its a quote

Thanks, someone 'splained it already...

On Sat, 24 Dec 2005 16:34:45 +0100, daytripper
wrote:

On Sat, 24 Dec 2005 16:13:44 +0100, "hackbox.info"

wrote:

On Fri, 23 Dec 2005 21:35:31 +0100, daytripper
wrote:

what is faster, four calls to crc routine or one call? This is an
unnecessary overhead for the drives firmware

What makes you think crc generation is handled by firmware?

Wild guess. It may be on ASIC, but I personally would put it in fpga or
firmware (primary, secondary is loaded from magnetic media on start).

That's the problem with wild guesses, they're usually wrong. There's
little reason to push media ECC and interface CRC out of controller Si
and into a uP, these are well-understood, highly developed algorithms
that are best embedded where they won't be a throttling influence.

ok, forget about CRC, more sectors for HDD firmware means more
computation, just like more smaller packets slows network connection

I really have no idea what this means. And since I can't install linux
on it, I'm gonna go back to surfing pr0n.
Still think that ought to be "p0rn"...

google it, second link, its a quote

Thanks, someone 'splained it already...

I mean the whole sig is a quote, not only the "pr0n" part

--
I really have no idea what this means. And since I can't install linux on
it, I'm gonna go back to surfing pr0n.
the penguins are psychotic / just smile and wave

On a sunny day (Sat, 24 Dec 2005 16:13:44 +0100) it happened "hackbox.info"
wrote in op.s2am86q5i3uckk@lozko:

On Fri, 23 Dec 2005 21:35:31 +0100, daytripper
wrote:

what is faster, four calls to crc routine or one call? This is an
unnecessary overhead for the drives firmware

What makes you think crc generation is handled by firmware?
[Even] in the old 8072A FDC the CRC was even done in the chip.
There was a speed advantage: 'read cylinder' versus 'read sector'.
It had to do with the disk head moving past the next sequenctial sector
on a cylinder during the time the processor was calculating / communicating
the next sector number to be read.
From some POV it would then make sense to buffer whole cylinders, dunno if
this is done.
Actually 'disk interleave read' came from that delay IIRC, the processor was
too slow to do sector 1,2,3,4 in a cylinder, so it did (for example)
1, 3, 5, 7.
(A cylinder is a circular track with sectors).
Have not kept up a lot how they do it now, but same problems will likely apply.

In article ,
says...
On a sunny day (Sat, 24 Dec 2005 16:13:44 +0100) it happened "hackbox.info"
wrote in op.s2am86q5i3uckk@lozko:

On Fri, 23 Dec 2005 21:35:31 +0100, daytripper
wrote:

what is faster, four calls to crc routine or one call? This is an
unnecessary overhead for the drives firmware

What makes you think crc generation is handled by firmware?
[Even] in the old 8072A FDC the CRC was even done in the chip.

CRC calculation is trivial in hardware. Why not?

There was a speed advantage: 'read cylinder' versus 'read sector'.
It had to do with the disk head moving past the next sequenctial sector
on a cylinder during the time the processor was calculating / communicating
the next sector number to be read.
From some POV it would then make sense to buffer whole cylinders, dunno if
this is done.

What do you think the "disk buffer" is doing? ;-) Once the head
is in position, might just as well grab whatever one can.

Actually 'disk interleave read' came from that delay IIRC, the processor was
too slow to do sector 1,2,3,4 in a cylinder, so it did (for example)
1, 3, 5, 7.

Yes, but this is ancient history. DMA is wunnerful.

(A cylinder is a circular track with sectors).

A track is the group of sectors found on the same surface/head. A
cylinder is the group of tracks that can be accessed without moving
the head.

Have not kept up a lot how they do it now, but same problems will likely apply.

Which problems? Magnetic density? Head/amplifier bandwidth? Surface
flatness? Yep, those problems are still the limiters. Electronics
certainly isn't.

--
Keith

On a sunny day (Mon, 26 Dec 2005 19:49:57 -0500) it happened Keith
wrote in :

What do you think the "disk buffer" is doing? ;-) Once the head
is in position, might just as well grab whatever one can.
Not exactly, the cache RAM in the disk drive would come into play here
from a design POV, any 'disk buffer' in the OS is the next level.
Also the drive will have to do bad sector management (remapping)...


Actually 'disk interleave read' came from that delay IIRC, the processor was
too slow to do sector 1,2,3,4 in a cylinder, so it did (for example)
1, 3, 5, 7.

Yes, but this is ancient history. DMA is wunnerful.
DMA has actually nothing to do with it.
Although DMA will free up the processor when putting the disk data (from the
disk drive cache memory usually) into the computer memory, even without DMA
this could be done, but of course it would take a lot more processor cycles.
So DMA frees up the processor from doing IO, it does not really speed up the
transfer as the (overall) transfer is set by mechanical parameters in the
drive. (seek time comes into play, rotation speed).
This is a funny misconception, I once designed (good old days) a small
embedded system that worked 100% without interrupts and without DMA, so
using polling, and just made the instructions so the timing exactly fitted.
A modern processor would have no problem executing a few IO instructions.
But it would suck resources.
Actually you may be right if we look at the max IO speed that can be done
via the PCI bus from the processor POV, I dunno exactly what that is...
New PCI bus is here, things are getting more and more complicated, faster
and faster, and you need a thousands of $$ scope to even be able to measure
something. I really dunno where it will go, perhaps optical.

Which problems? Magnetic density? Head/amplifier bandwidth? Surface
flatness? Yep, those problems are still the limiters. Electronics
certainly isn't.
Oh? head amplifier bandwidth, sensor technology, servo system is not
electronics?
Not to mention the whole uc in the drive....
It is all tightly interconnected.
You are dreaming if you think it is not.

In article ,
says...
On a sunny day (Mon, 26 Dec 2005 19:49:57 -0500) it happened Keith
wrote in :

What do you think the "disk buffer" is doing? ;-) Once the head
is in position, might just as well grab whatever one can.
Not exactly, the cache RAM in the disk drive would come into play here
from a design POV, any 'disk buffer' in the OS is the next level.
Also the drive will have to do bad sector management (remapping)...

You really don't think the drive can buffer more than the OS -
faster. A disk "cache" isn't. That's why it's called a "buffer"
and not a "cache". Read ahead/behind is a win, write-buffering is
a rather questionable strategy. "Cacheing", I think not. You'll
never *hit* that cache.

Actually 'disk interleave read' came from that delay IIRC, the processor was
too slow to do sector 1,2,3,4 in a cylinder, so it did (for example)
1, 3, 5, 7.

Yes, but this is ancient history. DMA is wunnerful.

white space is wunnerful too

DMA has actually nothing to do with it.

It has a *lot* to do with it. The processor just tells the stupid
DMA controller what to do and it does it. Hardware is faster than
software, dontchaknow.

Although DMA will free up the processor when putting the disk data (from the
disk drive cache memory usually)

Wrong. Data is *rarely*, if ever, in the drive's "cache".

into the computer memory, even without DMA
this could be done, but of course it would take a lot more processor cycles.

*TA-DA*, enter DMA.

So DMA frees up the processor from doing IO, it does not really speed up the
transfer as the (overall) transfer is set by mechanical parameters in the
drive.

Bull****. This is *exactly* why drives were interleaved; the
processor didn't have the power to rub its belly and shake hands at
the same time. DMA relieved it of the shakeing-of-hands.

(seek time comes into play, rotation speed).

You're talking apples and orangutans.

This is a funny misconception, I once designed (good old days) a small
embedded system that worked 100% without interrupts and without DMA, so
using polling, and just made the instructions so the timing exactly fitted.
A modern processor would have no problem executing a few IO instructions.

Whoopie!!

But it would suck resources.

Delete "resources" from the above.

Actually you may be right if we look at the max IO speed that can be done
via the PCI bus from the processor POV, I dunno exactly what that is...
New PCI bus is here, things are getting more and more complicated, faster
and faster, and you need a thousands of $$ scope to even be able to measure
something. I really dunno where it will go, perhaps optical.

Disks aren't interleaved anymore. The hardware is fast enough to
read sequential sectors. Sheesh!

Which problems? Magnetic density? Head/amplifier bandwidth? Surface
flatness? Yep, those problems are still the limiters. Electronics
certainly isn't.

Oh? head amplifier bandwidth, sensor technology, servo system is not
electronics?

Servo systems aren't the speed limiters. The head and read/write
amplifiers are the limiting factors.

Not to mention the whole uc in the drive....

So what? The UC on the drive is simply a cost reduction. Hardware
*could* do the entire job.

It is all tightly interconnected.
You are dreaming if you think it is not.

The snoring is coming from your end.

--
Keith