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
