There's good news and there's bad news. The good news is that, as you expected, there's only a small difference between a big write
cache with a long delay and a small write cache with a short delay. The bad news is that I found some big performance problems (in reading and deleting files) that exist in FreeDOS but not in DRDOS 7.03. Caching (particularly write-caching) helps both OSs but it helps DRDOS a lot more. E.g. FreeDOS takes 50 seconds to read and delete ~300 files. DRDOS does the same task in 6 seconds. I don't know why. Here are the details: First the cache test results. I ran UKA17X2 with NWCACHE configured four different ways. I rebooted between tests. Also I used newly created subdirectories for each test. Running UKA17X2 (end time - start time) on FreeDOS ca. 2006/08/20 ----------------------------------------------------------------- with write caching ------------------ 14 sec "nwcache 6144 6144 /lend=off /bl=16 /delay=333 /w=64" 11 sec "nwcache 6144 6144 /lend=off /bl=16 /delay=333 /w=6144" 14 sec "nwcache 6144 6144 /lend=off /bl=16 /delay=5000 /w=64" 11 sec "nwcache 6144 6144 /lend=off /bl=16 /delay=5000 /w=6144" 14 sec "smartdrv" (no operands - default is write caching for hdds) without write caching --------------------- 40 sec "smartdrv c" (read caching on but write caching off for c:) 9 sec no cache - target directory was on a ramdisk In the "with write caching" results, the difference between 11 seconds and 14 seconds is less significant than it appears. That measurement is based on the difference between the time on the DOS prompt when the cmd is executed and the time on the DOS prompt when the cmd ends. (I allowed for the time required to type the cmd too. I typed an invalid form of the cmd first and entered it. Then I recalled that cmd, corrected the one char that made it invalid, and then pressed enter. I allowed one second for that recall and correction process.) The problem is the ending time on the DOS prompt. The DOS prompt returns before the cache finishes writing. I know this because the hdd LED is still flashing for about 3 seconds or so after the DOS prompt appears. That DOS prompt is useless until the cache finishes writing; but its premature arrival distorts the time readings in these tests. I haven't tested LBACACHE yet. I had planned to but I found another problem that seemed more important. FWIW, I would expect that LBACACHE's lack of write caching capability will put its performance in the same ballpark as SMARTDRV or NWCACHE when they have write caching disabled. From the tests that I *did* complete, the numbers suggest that the size of the write cache is more significant than the delay. But the difference is not big and, as I pointed out with the premature return of the DOS prompt, that difference may really be even smaller than these numbers indicate. The biggest difference is between *any* write caching and *no* write caching at all. Now for the bad news: When I started deleting the files created in the above tests, the performance was awful. It took longer to delete the files than it took to create them. Of course I was doing a little more than just deleting those files (the pgm that I used also read each file before deleting it). But AFAIK that was nothing that should have caused the performance to deteriorate that badly. Here are some of the timing numbers for deleting a single tree: 50 seconds With smartdrv write caching on 80 seconds With nwcache read caching on 100 seconds With no cache at all Remember that most of these trees were created in under 15 seconds. The idea that it would take > 3x longer to read and delete a file than it took to create and write that file seems wrong. In addition, while each tree was being read and deleted, FreeDOS abused the disk (with constant, drive-chattering, seeks) during the entire deletion process. I suspect that the disk was seeking so much because, for each file, it was doing the following: 1) Reading from one subdirectory cluster a) maybe reading another non-contiguous, subdirectory cluster b) maybe reading a third non-contiguous, subdirectory cluster 2) reading the FAT to find out which secondary clusters that file occupied 3) reading all the file's clusters 4) Writing in one of the subdirectory's (non-contiguous) clusters again (to the delete the directory entry) 5) Writing to the first FAT (to mark the file's clusters as free); 6) Writing to the second FAT (to mark the file's clusters as free); Multiply that process by ~300 files. This process seems like it *should* benefit greatly from write caching. Yet, even when write caching *is* enabled, it doesn't seem to help as much as it should. I figured that something was wrong. So I decided to do similar tests with DRDOS 7.03. I already had another boot partition on that same hdd with DRDOS 7.03 installed. So I changed the partitions' flags in the MBR and rebooted. I ran many of the same tests under DRDOS that I'd run under FreeDOS. The results for creating the trees of files were essentially the same as those under FreeDOS. But the results for deleting the trees were hugely different. Here are some of the timing numbers for deleting a single tree: 6 seconds With smartdrv write caching on 27 seconds With smartdrv read caching on 90 seconds With no cache at all (same disk abuse as under FreeDOS) 6 seconds vs. 50 seconds? 27 seconds vs. 80 seconds? This is not good. Why are DRDOS 7.03's times so much smaller? I don't know. -Eddie ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user