Re: [Freedos-kernel] FreeDOS disk I/O is much slower then MSDOS
On at 2018-11-05 15:51 +0100, Tom Ehlert wrote: >> the FreeDOS kernel is seriously slower then MSDOS when doing >> larger copy/xcopy operations. > >> the cause: the disk I/O code avoids transfers that cross a 64K >> boundary, and splits these transfers into 3 (smaller) transfers. > >> this was needed for floppy controllers in the 1980's, but is certainly >> not necessary for harddisks after the IBM XT. > > >> just skip > > >> /* avoid overflowing 64K DMA boundary */ >> count = DMA_max_transfer(buffer, totaltodo); > >> for harddisks, and everything should be *much* faster (at least on >> rotating media in a non-emulated machine) > > investigating in this a bit more, the 64K boundary was/is a problem > with ISA DMA, used only for floppies (and sometimes serial/parallel > ports), but is no problem for UDMA. > > skipping this test for drives with 0x80 set should be save, and result > in a significant speedup of large disk transfers. Another possibility is to depend on the error code (ah = 09h, RBIL lists this as "data boundary error (attempted DMA across 64K boundary or >80h sectors)") and retry the calls to avoid 64 KiB boundaries only then. I've had success with that when loading from an actual diskette drive; the error is properly reported and handled this way. Regards, ecm ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] [Freedos-user] FreeDOS Boot Disc
Hi Eric, Kernel on that image uses 386+ instructions... and it seems as if it does that without (properly) checking for the presence of a 386. That is correct, as a kernel cannot be both optimized for 386 and compatible with 8086 at the same time. Well, yes it could (look at FreeDOS DEBUG/X's sources for table-based load-time patch method), but that's not the point. The point is that software requiring a particular instruction set should usually check whether that's available (before using it), and more or less gracefully abort if not. The kernel itself has no reason to not show a little more grace here, especially now that the _check_ for 386+ is already implemented, just the conditional branch out and showing an error message then rebooting not yet. but if 386+ kernels really do not abort with an appropriate message on non-386 CPUs, that's a bug. THOSE can automatically say that they cannot load on incompatible hardware, then return to DOS. Users can still use DOS then and sure it is nice to not crash on old hardware but show some message. But a kernel? It cannot skip itself and jump to a command prompt with only the 8086 part loaded ;-) Yes it could sort of, which is again not the point. Just look at the boot sector loaders, maybe their earlier revisions though (with as far as I remember more descriptive error messages). Nothing prevents the 386+ kernel from appropriately branching out, displaying This is a 386+ build of the FreeDOS kernel, please obtain a different one for this non-386 CPU. Press any key to reboot. (using Int10.0E like all other messages from the loaders), then calling Int16.00 and Int19. Note lines 194 to 196, where precisely in this latest r1705, Kenneth added the comment TODO display error if built for 386 running on 8086 etc. Well if it really makes you happy... Well, if it makes you happy (not really the topic what would make whom happy?), you can of course refrain from writing the code necessary for that or alternatively asking for a patch. Note that also a number of boot loaders only work with 386 anyway now. Including at least some MS-DOS 7+ boot loaders, and FreeDOS's current FAT32 FS boot sector loaders, thankyou I'm aware. That's still no reason to hold onto this user-unfriendly behaviour everywhere. (The FAT32 FS boot sector loader has a restriction as designed which makes it at least somewhat sensible to not emit a nice diagnostic on failure. This is not true of the kernel at the stage we're examining.) And yeah, I do think it could genuinely put a user off. Imagine someone gets that image, maybe extracts the files to put them onto a smaller format floppy. Loading an actual machine with that, or emulated, regardless. This image specifically described as Great for booting FreeDOS on old PCs on the website right now. And the kernel just crashes. What if that person is unable/unwilling to step through the kernel's early load phase (including UPX decompression) to figure out what caused the crash? Maybe they'll ask on the list for help with a mysterious crash, but I wouldn't guess it'd make a particularly good (first) impression. And it's so easily avoidable. So many words. What a waste. I should condense more next time. Regards, Chris -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] [Freedos-user] Virtual floppy change problem and slow VirtualBox UIDE2 init problem
When DOS detects an unreliable floppy change line hardware, it should use the floppy label / serial / similar to detect changes in software ... How does DOS ever detect that any hardware is unreliable?? I do not know, but earlier in this thread, somebody said that the numbering of FAT filesystem exists, among other reasons, to help DOS detect floppy changes even if there is no change line available. As you know, int 13.15 can even report that a floppy has no change line at all. MS DOS might, on top of that, have a list of BIOS versions with weak change lines? I think this excerpt might be relevant; from Geoff Chappell's DOS Internals, chapter 16 (Low-Level Disk Support), after the section heading Floppy Disk Drives, on page 605: As a normal part of its initialization, IO.SYS categorizes the available floppy disk drives. For this purpose, it relies on the BIOS to report the drive's capabilities. Int 13h function 08h (Get Drive Parameters) returns the maximum supported values for the cylinder, head and sector parameters. In the context of assigning drive types, it is sometimes helpful to know whether or not the BIOS supports change-line detection (i.e., the drive can detect whether the drive door is open) for the drive in question. One indirect inference is available since the low-capacity 5 1/4 drives are unable to provide a change-line facility. It doesn't go into more details regarding the change-line detection support detection right there, but I'll report in another reply (to this message) if I find more elsewhere. Regards, Chris -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Regarding commit 1702 (large sector sizes)
Note that the 1702 changes were effectively reversed by 1704. The 1705 changes are unrelated. Wrong From -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Commit 1705
Hi, Commit 1705 renames a particular LoL field CPULevel and adds a comment correctly claiming that MS-DOS sets this field to 1 on 386+ CPUs and to 0 otherwise. The commit however makes the boot loader store the detected CPU level (0, 1, 2, or 3) there instead. I don't think it's necessary to use the field in an incompatible manner, and neither is the new 21.33 subfunction that the commit adds, because no one uses it yet. Even so, the subfunction does not require using that particular field to store the detected CPU level. Regards, C. Masloch -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Regarding commit 1702 (large sector sizes)
Hello devs, especially Jeremy, I reviewed your recent commit 1702 to build 2041 regarding sector sizes larger than 512. Here are my thoughts and suggestions. - First, dsk.h defines the maximum sector size (MAX_SEC_SIZE) as 2048 (as the commit comment says) while the relevant LoL entry (maxsecsize) in kernel.asm is initialised to 4096. - Second, maxsecsize is erroneously used once in dsk.c while everything else uses the value from the dsk.h definition. - Third, if I'm not entirely mistaken, the patch makes all buffers grow to 2048 bytes, even in the absence of any block devices with large sectors. This will unnecessarily waste memory on most systems. MS-DOS initializes its 'maxsecsize' to 512 and will increase it (along with each buffer's size) during CONFIG processing whenever a block device with larger sectors is registered. (As far as I know/deduced, this works up to a sector size of 8192 bytes.) This way, if the need for large buffers wasn't apparent during CONFIG, they will stay smaller. This scheme could obviously be extended by additional tools/interfaces to increase the buffer size later on, and a CONFIG option to artificially increase it in anticipation of a post-CONFIG requirement. - Fourth, apart from the other points, I fail to see why you should not be able to simply increase MAX_SEC_SIZE to 8192. 4096 is definitely in need as evidenced by the list's requests for precisely that size. - Fifth, I think MS-DOS supports sector sizes below 512 too. If you were to look into that, I believe it wouldn't be too hard to implement. Due to the filesystem (size of directory entries), 32 bytes is the absolute minimum. I believe all sizes below 512 will require a slight change to the BPB loading (What to do about the sector end signature location?) while you might have to get creative for the very small sizes, because a full BPB would not fit. I'd suggest just expecting the BPB to stretch several sectors then; the filesystem already allows reserved sectors to be properly implemented using the BPB. Regards, C. Masloch -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Regarding commit 1702 (large sector sizes)
- First, dsk.h defines the maximum sector size (MAX_SEC_SIZE) as 2048 (as the commit comment says) while the relevant LoL entry (maxsecsize) in kernel.asm is initialised to 4096. Yes - this is simply for testing purposes; I plan to default both to 512. I would prefer both set from the same define to ensure they stay in sync - I am aware they are different, I am tracking down how to fix support for larger than 2KB sectors and MAX_SEC_SIZE will be set to 4096 to test or possibly eliminated in favor of using only maxsecsize. Ah, yes, Eric speculated that this might be a proof of concept for now, lacking an unstable branch. I happen to keep track of kernel commits recently. Sorry that I already reviewed this premature implementation! Values should definitely be tied later, either by consistently using MAX_SEC_SIZE, or (preferably) by initialising maxsecsize and the init buffer's size with MAX_SEC_SIZE and then always referring to maxsecsize afterwards. - Third, if I'm not entirely mistaken, the patch makes all buffers grow to 2048 bytes, even in the absence of any block devices with large sectors. This will unnecessarily waste memory on most systems. yes, buffers are allocated using size of max sector size so will waste lots of memory if 512 byte sectors are used. I will be committing updates to ensure max sector size defaults to 512 so as to avoid waste of space. Regarding that, I once considered that unused buffer space could be used to load multiple smaller sectors. Say, if you use 4096-byte buffers but a particular drive has 512-byte sectors, you can load eight sectors at once whenever reading. Would have to align sector reads to those boundaries though, plus a special check for the end of the file system. Additionally, the written bit would either have to be expanded to a bitmap, or you'd have to write eight sectors together all the time too. This would probably abandon any MS-DOS compatibility of the buffer layout, if the kernel currently does have any (not sure). This scheme could obviously be extended by additional tools/interfaces to increase the buffer size later on, and a CONFIG option to artificially increase it in anticipation of a post-CONFIG requirement. agreed, a config option to allow manually specifying a larger value than needed at boot time - should buffers be extended to BUFFERS=COUNT#,READAHEAD#,SECTORSIZE# or would it be better to add a whole new command MAXSECSIZE=SECTORSIZE# ? (the latter seems simpler so the one I will plan on for now). Yes, Eric suggested that one too. Plus, I think it's preferable because then a user can specify MAXSEXSIZE without having to specify the first two values for BUFFERS. I don't see us using max sector size 512, but using tdsk with smaller than 512 sector size does seem to work - though at this time I don't see me researching if it correctly works or merely happens to work on my test setup. I think you need to review at least dsk.c around line 388, where it says pbpbarray-bpb_nbyte % 512 now. I didn't look into what that check actually does, but it sure seems like it would have to be adjusted. While you're at it, you can make it the proper check for powers of two between 32 (or 64,128, regarding (E)(N)BPB size) and 8192 (or 2048 for now). currently any value 3KB causes memory corruption if too many buffers are specified (I have successfully gotten 4KB sectors to finish booting by changing buffers=2). I currently have tracked down part of my issue to allocation problems if buffers is too large, but still working on relearning the init time segment relocations and order to determine a proper fix for buffer allocations. It would help if printf worked correctly in all the init code... The virtues of high-level language kernel development ;) Regards, C. Masloch -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
