Hi again! Sorry to react in two mails, but flash disks are a nice topic :-)
> Thanks Michael for the heads-up on DOM technology - it had completely > missed my radar and after a bit of research I agree with your advise > entirely to go with that rather than SDcard/CFcard+IDE adapter... In general, the performance of CF is better (fast PIO, some even UDMA) compared to SD (fast serial communication). But then, IDE is vanishing slowly while SD market is still growing, so that will change. You can use SDs card with a simple USB cardreader or full SD-IDE controllers. >> ...you should "test" UIDE on your systems using SSD disks... Yes, for example I encountered some CF which would just hang a while from time to time, really annoying when using them as disk on a PC. >> If not, only a minor loss, as SSD disks are so fast that they really >> should not need caching. You can then run UIDE with its /N1 switch >> which causes it to ignore hard-disks but continue to cache diskettes >> and CD/DVD drives. They need caching, for they are otherwise SLOW! Caching CD/DVD is a really good idea yes. However, CF and SD cannot be compared with dedicated SSD for PC: A modern SSD contains cache and a lot of clever firmware to load-balance and wear-balance to have a fast disk which lives for a long time. A low-end version of CF / SD may not have any caching / balancing at all, but your mileage may vary. In any case, flash based storage (CF, SD, USB sticks, SSD, DOM and so on) has often very fast read access time and nice BULK write speeds. Their bad side is that doing many small writes can be very slow, as each actual flash write takes quite some overhead in hardware and only caching and pooling and balancing done by the smart SSD (also, but in lower degree by the smart USB stick / other flash disk) itself hides that from you. So, just in case you happen to have a classic *write* pooling cache a la SMARTDRV or NWCACHE around, I would be happy to hear from you about performance effects of in particular lower "delayed write" settings as "at most 64 kB pending for at most 1/2 second", or "pool writes while inside one block of 16 kB (or even only 4 kB) if possible". Thanks :-) My theory is that, in particular for disks not tuned towards DOS use, pooling things a bit will make a difference. While DOS may update the FAT word by word, other filesystems and operating systems may pool all writes in units of 4 kB or much larger. Modern SSD and even harddisks may even be tuned towards having all I/O in aligned multiples of 4 kB. Of course this is also something that your software can work on a bit, without help from DOS and caches: Access data in larger chunks, try to change file properties less often in larger steps (e.g. file size) etc. Regards, Eric ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
