Re: [NTLK] Looking for ATA/Compact Flash advice.

From: Paul Guyot (pguyot_at_kallisys.net)
Date: Thu Aug 04 2005 - 14:57:08 PDT


Le 5 ao=FBt 05 =E0 05:14, okto a =E9crit :

> The issue with the transfer speeds is not size, but how fast the
> controller in each card can spit data back and forth. All cards are
> not created equal: I have an oooold (1996) SimpleTech 16MB CF, a
> newer Lexar 16MB 4x speed USB enabled ultra super duper CF, and a new
> SanDisk 64MB plain vanilla CF.
> The ancient SimpleTech card is the fastest of the bunch. No reason
> for it to be, but it is. And ironically, the Lexar "high speed" card
> is the slowest: 200kBps read, __64kBps__ write. That's like floppy
> drive speed, and it's COMPLETELY ridiculous. For reference, the
> SimpleTech card can handle about 600kBps both ways.
> Use the read/write tests available in the Card slip and figure out
> which of your cards is the fastest, and use that one.

That's true. The speed really depends on the card, some ATA cards are =20=

so slow that they are a pain to use in cameras or notebooks. And I =20
suspect the marketing hype on cards such as the Lexar to be either =20
camera-optimized accesses (totally inefficient with the Newton) or =20
pure marketing lies.

However, there are other differences with linear cards. The way data =20
is stored on ATA cards and linear cards is very different. The reason =20=

is that both kinds of cards behave differently. Linear cards can be =20
accessed randomly anywhere for reading but writing consists in =20
setting bits to 0 or erasing large blocks, resetting all bits to 1. =20
ATA cards cannot be accessed randomly but individual 512 bytes pages =20
can be changed.

For many daily accesses, I think that ATA Support can prove to be as =20
much or even more efficient than linear cards.

What most users noticed, and what Greg mentioned in this thread, is =20
that transfers from NCU can take a huge time on ATA cards. This is a =20
known problem because the kind of transactions the system is doing =20
when NCU installs a package isn't regular and ATA Support wasn't =20
designed with this very protocol in mind, as I didn't realize the =20
system could be such a perve there. Users often install packages on =20
internal memory or linear cards and then file them to the ATA card =20
where it just works.

Concerning data reliability, ATA cards may be a little bit less =20
reliable than linear cards indeed. I mean, I didn't prove my code was =20=

correct, and it's so huge that I intrinsically know there are bugs.

Problems with linear cards have been reported including a bug where, =20
if the card is filled up too much, you can lose all data on it (I =20
actually saw this three times, including once on my own linear card).
I got four or five reports of data losses on ATA cards, and that's =20
not a pleasant experience. Still, it's difficult to say if the loss =20
is caused by the software or the hardware as we also got probably a =20
dozen of reports of loss of data on linear cards that can be toasted =20
in few seconds (it starts with random errors and finally the Newton =20
says: Newton cannot read this card) which are believed to be hardware =20=

problems.

The truth is that the Newton has an exceptional data storage system =20
where all data is saved within transactions. It's completely =20
journaled (not partially as journaled filesystems are on todays =20
systems). So we get way less data corruption problems than with =20
regular (or meta-data journaled) storage methods. However, this means =20=

much slower access and this should not be a reason for not doing =20
frequent backups, should you use ATA or linear cards (or not card at =20
all).

Paul
--=20
Ministre ultrapl=E9nipotentiaire en disponibilit=E9.
Mobile. Sans baignoire fixe.
http://www.kallisys.com/
http://www-poleia.lip6.fr/~guyot/

-- 
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 : Thu Aug 04 2005 - 16:00:02 PDT