Fw: FAT-FS HD write speed

[Peter Mueller]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Leon, Thomas, Eugeny,

I'm a little bit confused now. What I got so far:
There are three different rtems implementations available for  ATA drives.

1) One from Thomas Doerfler
2) One from Eugeny Mint
3) One from  Leon Pollaks

1) and 2) seems to differ mainly in code organization (libchip vs bsp). 3)
is not integrated in
rtems and works like a "user space" ATA driver and provides basic
functionality (i.e. no subdirs etc.) but 
seems to be very fast.

Is this correct?

Because I like to use 1) or 2) what are the real differences regarding
implementation? Are both solutions maintained?

- - the same libblock code?
- - the same fat12/16/32 code?
...

Peter


On Sun, 12 Jan 2003 10:34:24 +0000
Leon Pollak <leonp at plris.com> wrote:

> On Saturday 11 January 2003 09:17, Thomas Doerfler wrote:
> Hello,
> 	Our product is heavily based on ATA Flash cassettes writing and we
> 	also 
> invested a lot of efforts to measure and speed up writing process.
> > today I have run the write data rate test. My system is a
> > MC68040 with a Sandisk PCMCIA Flash Disk attached.
> Our case seems similar - MPC860 running at 25MHz.
> 
> > for the flash disk I got data rates of 78KByte/sec, for the
> > ramdisk I reached 380KByte/sec.
> As you probably remember I have my own FAT16 implementation. Recently I 
> totally rewrote my cassettes HW driver and run performance tests. My
> result for the new, very improved for speed driver on my 25MHz system
> with SanDisk 80MB cassettes is 156KB/s. I underline here that the result
> is concerning PURE driver - one sector by sector writing.
> You can significantly improve the write speed by means of multisector
> writing, but this is totally different story, which we have implemented
> totally different.
> 
> > - The Fats get written too often: It might be sufficent to
> > update them, whenever a file is closed, I think this happens
> > now whenever a new block is allocated, or so.
> I do not know your FAT implementation. Our is kept in RAM (with some
> tricks for unexpected power-down recovery) and still, our results with
> the old driver (which WAS NOT SO BAD WRITTEN!) were very similar -
> 87KB/s.
> 
> 
> > - The write function of our driver migt be somewhat slow. It
> > has been written for "robust" functionality, not speed.
> See above.
> 
> My personal estimation is that using our new driver (with different
> cassette wait ready manner), DMA and zero-copy FAT code we shall be able
> to reach not more then 160-170KB/s - this seems to be the natural
> limitation of flash disks.
> 
> > I hope this information helps you on...
> Me too...:-)))
> 
> -- 
> Dr.Leon M.Pollak
> Director
> PLR Information Systems Ltd.
> leonp at plris dot com
> 


- -- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+IUPGUzCcwYQMTJoRAo/5AJ9TPW4kG5Ebug2vEQN0yXtWcezr3wCgnXo2
x9nETGef107TQVXWXw4BKfw=
=0zwC
-----END PGP SIGNATURE-----