Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

RDRVSX32: FAT32 RAM drive for HimemSX (Announce)

posted by Richard, 21.05.2022, 13:23

> well. Any conclusions about your efforts?


Preliminary discussion and conclusions.


The original aim of the exercise was to test out RDRVSX32 in the creation of FAT32 RAM drives - a required aspect was the creation of RAM drives larger than 4 GByte (which automatically meant to be created in SuperXtendedMemorySpace (Abbreviated to SMS in my notes).

Previously, before March, DOS users only had access to RAM drives no larger than 4 GByte due to FAT 16 limitation.


Initially, in the development process there were problems that the FAT32 RAM drive could be created on AMD machines but not my INTEL machine - which resulted in this thread being on BTTR in the first place. Eventually I overcame this INTEL/AMD difference by simply reconfiguring FDconfig.sys (I used FreeDOS RC5 at the time, now known as v1.3). Apparently non-FreeDOS systems, both INTEL and AMD, were never affected.

At present I can only do testing in FreeDOS on a bare metal setup - I have not been successful to obtain MS DOS 7.1 to install beside FreeDOS. At this stage I did not do any Virtual Machine setup testing.


From a limited number of tests, I successfully achieved RAM drives of about 28 GByte and worked with file sizes up to 4 GByte(minus 1 byte) on all trials. My hardware is limited to 32 GByte RAM and since the first 4 GByte is reserved for (XMS + 1 MByte conventional memory) - at this stage I cannot confirm/deny on whether it is possible to have RAM drives > 32 GByte.

The speed of the FAT32 RAM drive is impressive - without using timer routines to measure - to copy from say a 1 GByte file in XMS and transform, by way of binary DOS file addition, to a 4 GByte file (in SMS) took only about 1 second. On the contrary, to copy a 4 GByte file to/from RAM to/from my USB stick takes over 2 hours (using FreeDOS).

So from a very limited set of testing conditions it appeared that RDRVSX32 is highly efficient and accurate in the creation of FAT32 RAM drives (in SMS).



Early on in this thread, Japheth indicated problems when working with LFN (my tests were only with 8.3 format) - and a number of RDRVSX32 iterations were written by the author (Jadoxa).

At this point I went off in a slight "tangent" - so instead of aiming for further RDRVSX32 testing in a variety of situations, I was involved in independent testing of LFN in FAT32 RAM drive, which led me into LFN testing of FAT32 RAM drive in XMS, FAT16 (XMS/SMS) and FAT12 (XMS/SMS) and USB stick equivalents of FAT 12/16/32. No tests were done on a Hard Drive or SATA SSD and similarly no tests for my 3.5 inch USB floppy drive (which seems to be broken).

A further "tangent" occurred with using a more reliable timing method (Jadoxa's RT program) than examining time differences via DOS prompt time stamps. Also another tangent resulted from Jadoxa supplying two versons for LFN - namely doslfn and doslfnMS.

So, to try to maintain "fairness" in various testing "environments", I attempted to automate measurements via ".bat files" for all possibilities for an extremely small sample set (10 files + 4 directories). The sole intention was to determine if the two doslfn{MS} were significantly different is speed. The timing resolution I adopted was milli-seconds ( RT program can offer micro-seconds resolution). It was inconclusive with only 10 files+ - so lastly bumped up to 100+ files. Apart from the problem (mentioned below):-

Conclusion To a resolution of 0.02 seconds there appears to be no timing differences between doslfn and doslfnMS for a sample size of 100+ files - however a more realistic (for me) size
set should be a minimum of 500 files + 500 1st level sub-directories AND NOT YET TESTED at a very deep level (say 10 levels down) also. This last addition may be interesting since my experience with Windows 10 is that serious problems (in Windows) occurs when working with >6 levels down, e.g. in searches.

Problems I have observed...

SHSURdrv cannot support 100+ files in the ROOT directory of FAT12 and FAT16 - so cannot test doslfn{MS} for larger file sets.

It appears that doslfn{MS} cannot support LONG FOLDER NAMES (whereas Windows can).

When using the TIME STAMP as part of the DOS Prompt - strange timing errors occur (as if time going backwards on occassions) - the best explanation I can give for this is that my machine is INTEL (i7) with 4 cores and each core acts as 2 logical processors. Even though, as I understand, DOS in bare metal mode only is working on one core at any one time, it may not be working on only one logical processor - so, any (exe/com/sys/bat) may be simultaneously processed by two logical processors (but by the one physical core). Two important factors are involved - pipelining (which came with the advent of 486 processors) and the way instruction codes are presented (c/f 8-byte boundaries for 64 bit machines). So, with "look ahead" techniques, a code stream split over two logical processors may get "unsynchronized" slightly - so the DOS prompt executed by logical processor #1 is finished AFTER RT.exe has finished on logical processor #2. However, under otherwise identical conditions, with an AMD quad core processor - there are only as many logical processors as physical cores (hence no pipelining I think) and there is only one process execution code stream running in DOS.

Hopefully, issues with SHSURDRV ROOT tables limit and Long FOLDER Names (once verified independently to see if the problem still exists) will be fixed in the near future. However, if I am the only one to be using FAT12 and Long FOLDER Names, I can imagine it will be a very long time, if ever, before being fixed.

Another "tangent" occurred with the using of SMARTDRV (to help speed things up).

Conclusion using SMARTDRV has no observed significant speed gains when doing DIR on various media/formats.

By using SMARTDRV many things were "broken" with RAM drives - resolved by re-arranging setup sequence of all combinations of RAM drive for FAT12/16/32 + XMS/SMS.



Summary

From limited testing on a 32 Gbyte INTEL computer, it is possible to achieve a 28 GByte FAT32 RAM drive. Speed is very good - > ~1 GByte per second for file transfers (RAM to RAM). Cannot confirm/deny if >32 GByte RAM drive is possible.

doslfn and doslfnMS appear to be the same speed for up to 100+ files (restricting to 0.02 second timing resolution).

No apparent advantage in using SMARTdrv for DIR on any media/format - and consideration when simultaneously having RAM drives as FAT 12/16/32 + XMS/SMS (i.e. 6 different kinds of RAM drives).

Apparent limitations with SHSURDRV for FAT 12/16 ROOT directories (only) (literature mentions can be as low as 64 entries - USB stick (via Windows allows 100+))

doslfn{MS} does not appear to work with long FOLDER Names (need independent confirmation)

My testing limited to FreeDOS 1.3 platform - not able to test via other platform (e.g. MS DOS 7.1)

RDRVSX32 does work with both INTEL and AMD - need consideration when using FreeDOS FDconfig.sys/FDauto.bat

There appears to be timing "racing" conflicts with Time Stamps as part of DOS Prompt comparing running programs (such as RT.exe) - attributed to on only INTEL > 486 processors with more than one logical processor for each physical core (so does not exist maybe for AMD).

"Screen Thief" and "RT.exe" and "Trace.com" utilities very useful for recording of events.

Further, more rigorous testing needed, but RDRVSX32 may be good enough "as-is" for over 99.99% of applications (my guess).

Post reply
 

Complete thread:

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