[Tfug] A/V drives

[Harry McGregor]

Bexley Hall wrote:
> Hi, Harry,
>
> --- On Wed, 12/24/08, Harry McGregor <micros at osef.org> wrote:
>
>> You are missing two things.  One, A/V rated drives went out
>> about 5 years ago, with the 120GB range drives.  I don't know
>> of many, if any AV drives still made.
>
> Actually, A/V drives are still being made.  Hitachi is a
> big player -- though they are now geared to STB's, smaller
> form factors, etc.  Note that this market has other
> pressures that a "single desktop user" market doesn't;
> notably, cost, size, power dissipation, etc.  I.e., you
> want to *cut* the performance of the device to the point
> where it just meets your needs, if possible.
These AV drives don't tend to have the thermal recalibration "fixes" of
AV drives of old.  Normally they just have reduced noise output, and
lower overall thermals, and of course reduced cost and lower rpms normally.
> But, whether they represent "current" technology or not is
> not related to my question -- if I asked why RMW instructions
> represent a boon to machines with *core*, would you feel
> the need to tell me "no one uses core anymore"?  :>
>
> (actually, core was in use in the 80's in the shuttle fleet;
> I think there is at least one military project which still
> relies on core...)
>
> Rather, my question was an attempt to identify characteristics
> of A/V drives that made them "different" from "regular" drives.
> Having an account of someone who had gone through the regular
> drive -> A/V drive transition and his/her observations along
> the way would have been *ideal*.
I skipped the A/V drive hype, and stuck with LVD SCSI (u80/u160) at the
time.  We used that for capture, and some 120GB drives for bulk storage.
>> Secondly, A/V rated drives did not throw out thermal
>> recalibration, the could delay it slight, hopefully until idle.
>
> Exactly.  Note my reference to *defering* T-cal.
Length of deferring matters, in many of the older A/V drives, it was of
the order of ms or maybe a few seconds at most.
>
> But, this presupposes there is a time when you *know* you
> can safely do this without compromising performance!
> So, it seems like A/V drives just kicked the can down the
> road in the *hope* that there *might* be a more opportune
> time to do this, "later".
Yep
> I.e., this wasn't a "fix".  Rather, it is akin to buying a faster
> computer to avoid "making coasters" with early CD writers (buffer
> underrun).  There's no *guarantee* that the computer still
> won't make coasters -- since it depends on what else the machine
> is doing at the time, how much swapping, etc.

Or the way I avoided coasters with the $1K 2x SCSI sony cd writer I was
working with... bag of ice on top of the drive.

> OTOH, adding track-size buffers and supporting track-at-a-time
> burning was a *real* solution to the coaster problem.
yep
> The (original) A/V drive approach is similar to throwing
> MIPS at a problem to try to make a non-RT system behave
> deterministicly.
>
Your still never going to get true RT performance out of it...
> Or, doing away with dynamic object creation to try to make
> GC-based languages behave deterministicly.
>
> These are just work-arounds, not solutions.
>
> My concern is there are some technologies (not related to
> A/V drives at all) that will probably be commercially viable
> in 2012 and I need to make an educated gamble as to which
> "problems" in those technologies will be surmounted (with time)
> vs. those that won't.  And, decide if I want to design with
> support for them in mind or sidestep the issue.
>
Without knowing more, it's hard to say on that :)
> This is relevant as many technologies are rushed to market
> "crippled" and later refined ("fixed"?).  Witness the CD/DVD
> writer issue, wear-leveling in MNOS devices, *new* A/V
> drive technology, etc.  I.e., if the upcoming technologies
> fall in with this crowd, their future looks promising...
> if not, <shrug>
>
Ok

>> This has nothing to do with a 24/7 i/o stream, or broadcast
>> level A/V or anything to that effect.
>>
>> It was more of a marketing ploy to get IDE drives in where
>> enterprise class SCSI was the only option.
>
> Understood.  As with the technologies I mentioned (above),
> "get your foot in the door" (even if the technology isn't
> "quite right", yet) and then fix it once/if it gains
> traction in the marketplace.
>
> Moral:  if the technology *can* be fixed, you (I) just
> have to make a wager on how *likely* it is to take hold...
The current fix for the A/V t-cal issues is larger cache.  With the
price of memory, can you really justify not using have a large cache?

Current drives are shipping with 32MB on board, with the cost of memory
though the floor, I can see drive makers jumping to 64MB or even 128MB.

The IBM storage array I spoke of has 120GB of memory, of which quite a
bit is used as cache.

             Harry

> Thx,
> --don
>
>
>       
>
> _______________________________________________
> Tucson Free Unix Group - tfug at tfug.org
> Subscription Options:
> http://www.tfug.org/mailman/listinfo/tfug_tfug.org