> -----Original Message-----
> From: Alex Turner [mailto:armtuk@gmail.com]
> Sent: Wednesday, April 20, 2005 12:04 PM
> To: Dave Held
> Cc: pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] How to improve db performance with $7K?
>
> [...]
> Lets say we invented a new protocol that including the drive telling
> the controller how it was layed out at initialization time so that the
> controller could make better decisions about re-ordering seeks. It
> would be more cost effective to have that set of electronics just once
> in the controller, than 8 times on each drive in an array, which would
> yield better performance to cost ratio.
Assuming that a single controller would be able to service 8 drives
without delays. The fact that you want the controller to have fairly
intimate knowledge of the drives implies that this is a semi-soft
solution requiring some fairly fat hardware compared to firmware that is
hard-wired for one drive. Note that your controller has to be 8x as fast
as the on-board drive firmware. There's definitely a balance there, and
it's not entirely clear to me where the break-even point is.
> Therefore I would suggest it is something that should be investigated.
> After all, why implemented TCQ on each drive, if it can be handled more
> effeciently at the other end by the controller for less money?!
Because it might not cost less. ;) However, I can see where you might
want the controller to drive the actual hardware when you have a RAID
setup that requires synchronized seeks, etc. But in that case, it's
doing one computation for multiple drives, so there really is a win.
__
David B. Held
Software Engineer/Array Services Group
200 14th Ave. East, Sartell, MN 56377
320.534.3637 320.253.7800 800.752.8129
