Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

about to fix the "final" doslfn bug (Announce)

posted by Richard, 15.04.2022, 06:47
(edited by Richard on 15.04.2022, 06:59)

> Okay, those times are a bit more reasonable (although 18s is still a lot,
> but a cache would help with that). Of course, that's assuming RT is right
> and the prompt is wrong. Or if they're both right, where's the extra time
> coming from? Accessing the programs from the slow USB? If you're not going
> to use a cache, perhaps create a small RAM drive (SHSURDRV), copy the
> programs to that and run from there.
>

I "on purpose" did not have a cache installed (SMARTDRV) or utilize RAMdrive for programs to get the "worst case " timings for comparisons.

Yes, all programs still running from USB FAT32 sub-sub-directory (C:\freedos\bin\). It is a fairly cheap 16GB verbatim (C:\,D:\ and E:\) bought from "K-mart" (10 or so years ago) and may be USB2 or even USB1 speed (on the USB2 port of the computer). I have noticed that "more expensive", "recent", "USB3" sticks from Verbatim seem to be much better, especially when multi-level sub-directories are involved (I suppose you get what you paid for).

With DOS tests, I always seem to notice that working off a sub-directory from (C:\ ROOT) seems to be noticeably slower than ROOT. C:\, my main working drive is FAT32 - and C:\ is only ~512 MB and was automatically created by (RUFUS + FreeBASIC RC5 full USB version), I had no control no control over that it had to be FAT32. Meanwhile, FreeDOS allowed me to have additional partitions (D:\ and E:\) on my USB stick (16 GB) and I allocated 12 GB to D:\ (as FAT32) and the remaining 2 GB to E:\ (as FAT16 just for fun). It is only very recently that I really did any testing etc with E:\. When I have "worn-out" my cheap USB stick, I plan to install on a brand new, higher quality (perhaps still verbatum) USB3 stick and plug into USB3 port.


The long term goal is to work "off memory" (either CACHE or most likely a RAMdrive - for all programs - where is best (assuming RAM drive) - XMSFAT16, XMSFAT32, SXMSFAT16, SXMSFAT32 - or doesn't it matter? I think I could spare some bytes off a RAMdrive for the whole DOS operating system + programs! :)

So, on reboot, probably xcopy the whole C:\ drive ( > NUL), then setup smartdrive, and make sure all paths refer only to RAMdrives.


Talking about xCOPY, on all possibilities of xCOPY C:\ --> RAMdrive, ie XMSFAT16 (~740 MB), XMSFAT32 (~740 MB), SXMSFAT16 (4 GB), SXMSFAT32 (~26 G) - the computer locks up (~~ half way through). According to Windows, C:\ drive contains 6986 items (6602 files + 385 folders) size 463 MB (size on disk 471 MB). There may be an upper limit for xCOPY which I don't know. My work around is to do it in say 5 stages (C:\ROOT then individually the four 1st sub-level-directories). Of course, over 99% on C:\ I do not really need to be there at all.







>
> > Is RT giving me the blank line before "Elapsed time: ...) - if so,
> option
> > to not have blank line?
>
> It is, to separate its output from the program it runs. I noticed that
> myself after doing the release. Removing the blank automatically is
> probably too much trouble, but adding another option would be simple
> enough.

For the next rerun of doslfn(MS) possibilities - I plan to simultaneously on screen captures, show timings w/o SMARTdrv installed, then on same capture, install SMARTdrv (won't be optimal element/buffer size values just yet), and run comparisons. Hence why I was so interested in removing the blank line before "Elapsed time:..."


EDIT each .bat run is to be with its own reboot per .bat






One thing I suppose I should really do, is to rerun exactly the same BUT change the order - eg c.bat, b.bat, a.bat, 9.bat ... 1.bat. And see if 1.bat still gives me the 18 seconds timings.

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22632 Postings in 2109 Threads, 402 registered users, 306 users online (0 registered, 306 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum