Re: [NTLK] compact flash card with adaptor size

From: Paul Guyot (pguyot_at_kallisys.net)
Date: Fri May 14 2004 - 11:25:56 PDT


Aux environs du 14/05/04 à 12:42 -0500, sous le titre "Re: [NTLK]
compact flash card with adaptor size", George Bingham prit sa plus
belle plume pour écrire les mots suivants:
>On Fri, 14 May 2004 18:19:35 +0200, Jon Glass <jonglass_at_usa.net> wrote:
>> Just so you know, I had this same problem off a 32 meg linear card. I
>> always froze trying to play MP3s so I ended up just deleting the whole
>> shebang. I don't think your problem is the ATA driver.
>
>Hi Jon,
>
> Thanks for that! I had thought it was the ATA card because I'd
>often use Mad Max to play streaming MP3s, and although it would run
>out of memory eventually, it would generate an error for that, and I
>could still stop it and recover from it. The way it freezes when
>playing MP3s from a card soup is it's totally frozen, and only a hard
>reset (i.e. removing power) seems to work... so thought maybe it was
>the ATA causing it. I am glad to know it's just Mad Max, I may end up
>using my ATA card more....

Actually, ATA Support is slower than linear cards for some very
particular operations. Reading MP3s is not one of these.

Specifically, Newton stores are transactional, i.e. modifications are
made in batch and committed atomically. It's like databases. It's a
little bit like journaling file systems, except that on the Newton,
both data and metadata are transactional.

When I realized this, I thought that the very operation of aborting a
transaction, i.e. to undo all the changes done so far, was a rare
operation. It's not, and ATA Support is very bad at it.

Additionally, I understood rather late how separate transactions
actually worked and ATA Support's original design is also quite about
at handling them.

The two of them actually are linked. When you install a package
(something that typically *is* slow on ATA cards), the system starts
separate transactions and then aborts them. The same thing happens
with Virtual Binary Objects aka VBOs.

The thing with the current format is that I think I can say it's
stable. The only data losses reported so far with RC6.1 were actually
hardware based (i.e. the cards had some defected sectors).

However, this implementation and this format is poor
performance-related and also I wanted to do it too smart with as
little redundant information as possible. This was a big design
mistake, I now realize it, for plenty of reasons from software
engineering to feature implementations.

I will eventually implement a new format, now that I know much more
about what the system does with stores.

Paul

-- 
Philosophie de baignoire - consultations sur rendez-vous.
NPDS/NewtonOS: http://newton.kallisys.net:8080/
Apache/FreeBSD: http://www.kallisys.com/
-- 
This is the NewtonTalk list - http://www.newtontalk.net/ for all inquiries
Official Newton FAQ: http://www.chuma.org/newton/faq/
WikiWikiNewt for all kinds of articles: http://tools.unna.org/wikiwikinewt/


This archive was generated by hypermail 2.1.5 : Fri May 14 2004 - 12:00:02 PDT