Hallo Tom,
>> As FreeDOS has the reputation of having slow disk I/O, > 'reputation' meaning that Jack told you so... Jack is indeed one pronounced critic of our I/O speed. > indeed the FreeDOS kernel is about 2* slower then necessary > *on rotating rust disks* ; the reason is known (1) Because I/O is split to avoid 64 kB DMA boundaries, into 2, at most 3 transfers, even when only floppy would need it, according to your footnote (1). Which means needing 2 to 3 revolutions instead of one (a lot slower!) when doing I/O with rotating harddisks: If your diagnosis is correct, then a read-ahead cache with suitable settings would reduce the performance problem a lot. Given that caches with read-ahead are available now, the outcome of an experiment might be that FreeDOS is not bad after all :-) If there are other reasons for slow I/O in FreeDOS, the experiment would show that this is not the only problem. I admit "benchmark" is a too bold term for the experiments I have in mind. So if your diagnosis is correct, I guess it would not be hard to suppress the DMA boundary avoidance logics on harddisks by changing the kernel source: https://github.com/FDOS/kernel https://github.com/FDOS/kernel/tree/master/kernel https://github.com/FDOS/kernel/blob/master/kernel/dsk.c A minimal patch would change line 1025 along the lines of "count = DMA_max_transfer(...) if floppy, or at most 64 kB if harddisk": > diff -u freedos-kernel-dsk.c.old freedos-kernel-dsk.c.new > --- freedos-kernel-dsk.c.old 2020-07-13 17:18:38.851356496 +0200 > +++ freedos-kernel-dsk.c.new 2020-07-13 17:32:04.737383666 +0200 > @@ -1021,8 +1021,15 @@ > buffer = adjust_far(buffer); > for (; totaltodo != 0;) > { > - /* avoid overflowing 64K DMA boundary */ > - count = DMA_max_transfer(buffer, totaltodo); > + /* avoid overflowing 64K DMA boundary, but only for floppy disks */ > + if (!hd(pddt->ddt_descflags)) > + { > + count = DMA_max_transfer(buffer, totaltodo); > + } > + else /* transfer at most 64k per call for harddisks */ > + { > + count = min(totaltodo, 0x4000 / (pddt->ddt_bpb.bpb_nbyte / 4));; > + } > > if (FP_SEG(buffer) >= 0xa000 || count == 0) > { That does not sound like something which would have been too complicated for FreeDOS developers to do for years? So I expect FreeDOS to have other I/O bottlenecks instead. AT THE MOMENT, FreeDOS does I/O from or to HMA or UMB one sector at a time, which I expect to be REALLY SLOW. This is due to copying all data through a tiny low memory buffer to completely avoid all I/O involving possibly DMA-unsafe RAM: The code for this starts immediately at the end of my patch. If would be conceivable to have a config sys option which enables (only for harddisk) direct I/O to and from UMB and HMA at the own risk of the users, then see whether users know when they can enjoy the improved UMB / HMA speed :-) >> I would like to get that quantified a bit... > a) why ? To get an impression of the size of the problem and of which areas are affected: For example I wonder if there is an issue with large directories and whether the MS DOS FASTOPEN cache makes sense even when general disk caches are used next to it anyway. Also, I wonder if FreeDOS updates the FAT more often than other DOS when a file is growing a lot while open: I can imagine other DOS would "pool" the updates until closing the file and only update the FAT on disk then, which has the side-effect of more data loss on crash while open. > b) why don't you try to quantify this for yourself I neither have other DOS brands at hand nor a dedicated test system and tests on virtual machines are not very useful for my type of question. > benchmarks should be > > a) well defined > b) easy to understand what they measure > c) reproducable After finding some volunteers, I was of course going to ask them to do exactly the same experiments multiple times on the same hardware with different DOS kernels & caches. I am aware that this is not "well-defined enough" to put it on some website and compare with experiences of other users, but it would give me some clarity about WHETHER FreeDOS is as slow as people like Jack assume, and in which areas it is. Regards, Eric _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
