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