Hi Bret, >>> The advantage of a write-delay cache is that that the writing can be >>> done when the system is "idle" (a simple form of multi-tasking). >> >> That counts as "advanced cache with a lot of code" and can go as far as a >> sort of ramdisk which syncs >> back to the harddisk slowly but steadily when the harddisk has time, in >> big cache. And it is not what I >> would suggest for DOS... > > That's basically what SMARTDRV and its equivalents do, though in a limited > sense (they don't use oodles of memory and cache/RAMDisk the entire hard > drive). Are you saying that you don't think programs like SMARTDRV "belong" > in DOS?
I am saying that for gaining speed on modern disks, in particular flash disk ands large sector disks, you should already make a big difference with a small pooling cache and a short delay, which is both simpler and less risky than large, long delay caches where a lot of hooks try to find out when a good moment to write is and a "last safe moment to write", e.g. before reboot, before crash? or before you return to the prompt, as many users assume it is safe to switch off a DOS PC while it is "idle" at the prompt. My suggestion would be similar to the DR DOS / NWCACHE write pool function, with a maximum write delay of for example 1/4 to 1/2 of a second. The maximum allowed in NWCACHE is 5000 msec, granularity are timer ticks of 55 msec and a document about NWCACHE says that delayed writes are off by default because they have compatibility risks :-p The same NWCACHE document also explains an effect called deferred writes with write combining: If you write the same sector several times in a short time, or quickly write consecutive sectors, the writes result in only one, in the consecutive case larger, write instead of multiple small ones or multiple same-sector writes :-) This document also implies that write-combining of consecutive or same-sector writes happens inside the same buffer which is also used for read-ahead, called the lookahead buffer which can be max 16 kB and defaults to 9 kB. Probably for reading a whole diskette track whenever you read any sector from that track. The size 9 kB does not ring a bell for me in harddisk terms. This thing differs from another option where you can use the WHOLE cache memory of a few megabytes for writes that are delayed up to at most 5 seconds. So... If anybody has NWCACHE (ask me if needed) they could try if NWCACHE with 555 msec delay and 16 kb lookahead / write-combining buffer and delayed/deferred/combined/pooled/whatever writes on is already making a quite nice difference in write speed, eg. on USB and when working with many small files :-) Regards, Eric ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
