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 



   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 



   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 



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. 



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
Freedos-user mailing list

Reply via email to