[Freedos-user] For Eric - NWCACHE write caching test results; and a new problem
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 secno 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
[Freedos-user] Results of SMARTDRV directory corruption tests
Here is what I've found: 1) The error is repeatable. I used UKA17X2.EXE to produce this error over and over again. UKA17X2 creates ~300 files. Other pgms that create a lot of files could probably be used just as well. Here is the sequence that I used to reproduce the error: a) Copy UKA17X2.EXE to the root directory of C: b) create a new subdir in c:\ c) cd to that new subdir d) execute \UKA17X2 The corrupted directory sector appears in either the new subdir or in NOS\HELP under it. One other curious thing: If you move UKA17X2.EXE into the new subdir and then execute it without the leading \, i.e. UKA17X2, the corruption does *not* occur. I don't know why. 2) Disabling SMARTDRV's write caching *prevents* the corruption from occurring. The downside of this (i.e. disabling write caching) is that UKA17X2 takes ~3 times longer to run without write caching enabled. 3) The directory corruption may *not* be related to LFNs. a) The LFNs that I saw in previous corrupted directory sectors were probably already in those sectors b) I've also seen source code snippets, sections of doc files, and other inappropriate data in corrupted directory sectors. c) Sometimes one or more *correct* directory entries are scattered within all the garbage in a corrupted directory sector. d) BTW I have yet to see a corrupted sector that was the also the first sector in a cluster. But that might just be the result of randomness. 4) Per Eric's request I tried substituting NWCACHE for SMARTDRV. I used DELAY=667 as the only operand. The results were: a) no corruption b) run time was very close to SMARTDRV (with its write caching on) HTH -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=lnkkid=120709bid=263057dat=121642 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Results of testing fdbasecd.iso dated...
Arkady V.Belousov writes: 21-???-2006 14:07 [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote to snI will ask this question: If FreeDOS is released as is, and users sn start seeing these msgs on their PCs, will they know that the problem sn is *not* caused by FreeDOS? So, you think, current menu tree is worse? I think, then you should try to draft own tree, which (you think) is better, and offer it for review for Blair. Sorry, I can't give further advices and help in this case, because all other depends from Blair. I have made some suggestions. And Blair has showed remarkable grace in responding to them (given my abrupt entrance here). But I doubt that I could do a fraction of the work he's doing, let alone do it well. My small contribution is testing some of this stuff on real machines (as opposed to emulators). -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=lnkkid=120709bid=263057dat=121642 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] corrupted directory sector from using SMARTDRV 6.22 with FreeDOS?
Michael Devore wrote: At 02:50 PM 8/21/2006 -0600, Eddie wrote: I was really hoping that this problem had been silently fixed by all of the other work that has been done recently. Doesn't look VDS-related, the executable only uses a couple of common calls there. Not much more I can tell you. Maybe the original LFN conjecture of a problem. If you can duplicate a problem at will, you could try without EMM386 loaded to make VM86 isn't getting in the way along the way, but doesn't sound like it. Thanks for checking this out. I suspect that I *will* be able to find a test case that gives a repeatable failure - but it may be a few days before I get back to it. Also Eric confirmed that this is *not* a new problem; he said that there is a report in Bugzilla about it. -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=lnkkid=120709bid=263057dat=121642 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Results of testing fdbasecd.iso dated...
Blair Campbell wrote: Those are more likely ISOLinux issues, and most users will probably not be using PART (which seems to interpret ISOLinux somehow as a virus, which would somewhat seem like a PART bug to me at least). I figured that ISOLinux might be the culprit since PART was detecting that something was different while the BIOS's detection code wasn't. And you may be right about it being a PART bug. I don't even know how widely used PART was; it may be rare. The reason that I included it in my report is that it seemed like a good example of the kind of messy interactions (with other pgms) that FreeDOS is likely to encounter once 1.0 is released. Who knows what kind of software is out there that FreeDOS will conflict with - bad BIOSs, anti-virus scanners, boot managers, compression schemes, etc.? I'm hoping to *help* eliminate some potential problems by providing examples of some of the risks of asking FreeDOS to do things which the BIOS can do for itself (e.g. reboot, detect hdds, etc.). Maybe by reducing some of the risky tasks FreeDOS does, we can reduce the number of times that FreeDOS will be blamed for things which are not its fault. -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=lnkkid=120709bid=263057dat=121642 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] corrupted directory sector from using SMARTDRV 6.22 with FreeDOS?
This problem occurs when using SMARTDRV.EXE (with write caching enabled) from MSDOS 6.22 with FreeDOS. Replacing either avoids the problem. I haven't pinned it down yet but the problem seems to occur with more than just one pgm. I've seen it when installing UKA17X2 (i.e. UKA_PPP), A189GPLL (Arachne 1.89), and when extracting ARJ archives containing several dozen files (particularly if they contain subdirectories). The common thread seems to be that these pgms all create multiple sectors worth of subdirectory entries relatively quickly. At some point when all those directory entries are being written, one of the subdirectory sectors (never the first sector of the directory) gets garbage written to it. Yet the sectors before and after that one contain normal directory entries. I'd seen this symptom with B9SR2 too but didn't bother tracking it down. This time I was using the 2037 kernel that Blair uploaded yesterday and the 2.25/3.25 EMM386/HIMEM that Michael uploaded yesterday. Removing SMARTDRV prevents the problem. Maybe disabling write-caching would too but I haven't tested that. But in looking at the garbage directory sectors today, I get the feeling that this has something to do with LFN support. But that's only a guess and it may be completely wrong. Sorry I can't pin it down better than that right now. If I do later, I'll post more. -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=lnkkid=120709bid=263057dat=121642 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Results of testing fdbasecd.iso dated...
Arkady V.Belousov wrote to freedos-user@lists.sourceforge.net: sn h) Boot from first harddisk (0x80) sn I fell into this because of the timeout. The next two lines on the sn screen are: sn Booting from local disk... sn Virus!!! This may be message from BIOS (if there is turned on option Check BOOT Viruses, then it monitors writing to MBR). The BIOS's warning msg is different. I saw the BIOS's msg too - later when using Fdisk. IIRC, the exact text Virus!!! is in the PART 2.37 MBR code (in its compact boot manager). As I reported, it doesn't seem to hurt anything; it just looks bad. sn q) Skip CD-Rom boot (try next boot device) sn NO ROM BASIC sn SYSTEM HALTED This is not FreeDOS. I know. sn Obviously this isn't an IBM PC. FWIW SBM's Quit to BIOS option sn gets this result too. Of course. This is original IBM BIOS architecture - when there are no bootable media, BIOS pass control to INT19, where in original BIOSes was reside built-in BASIC interpreter. But this BASIC very long ago not included into BIOSes, and message says about this. I know. sn Editorial comment: snObviously, some of these results are not ideal. What you want from FreeDOS in given case? What do *I* want? Nothing. I'm just testing the release CD and reporting the results. I will ask this question: If FreeDOS is released as is, and users start seeing these msgs on their PCs, will they know that the problem is *not* caused by FreeDOS? -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=lnkkid=120709bid=263057dat=121642 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Results of testing fdbasecd.iso dated 08/19/2006, pt.2
Continuing on the escape menu This menu is apparently inevitable. The installation process shows this menu regardless of what you choose on the preceding menu. E.g. after the previous tests, I created and formatted a new ~120MB partition just for FreeDOS. Then I rebooted from the FreeDOS CD. When the choose a drive menu came up I chose C:. That took me to the *same* menu that I got to when I pressed Esc on the choose a drive menu (during the earlier tests). Oh well. I've already reported on options 3, 5, and 9. So now I'll report on what happened when I tried some of the other options on that menu. 2) Create boot floppy Doesn't work. At least it doesn't write any files to the floppy. The only error msg that I noticed was can't create COMMAND.COM. But apparently it fails to write *any* files to the 1.4MB diskette in drive a:. The diskette was still completely empty afterwards. 1) Configure install This seems like a better place to ask the user which drive to install FreeDOS to. Is it possible to do that here (instead of before)? More on this submenu later. 7) MS style Fdisk Is this pgm necessary? IOW is it likely that a person, who was only familiar with MS Fdisk, would be unable to figure out how to use either XFdisk or SPFdisk? 8) Command prompt Works 4) Format disk Works, but... The problem is that the FORMAT cmd's safeguard (of requiring the user to type Y, E, and S) may mislead the user. AIUI, if the user enters *anything* else, the pgm's response does *not* indicate that anything is wrong. E.g. if the user just types Y and presses enter, then the pgm accepts that response (as a *refusal* to allow the format to proceed) and ends. Then the menu is redisplayed. But to the user, that may look like a successful format. Consequently, the user may have no idea that the FORMAT pgm has not done *any* formatting. There's more that I want to say about this menu besides these reports about the individual options on it. I think that this menu can be improved in several ways. They are: a) Make the option to continue installation obvious. IMO the words configure installation don't make that obvious. But at least that is the *first* choice on the menu. That part is good. b) Reduce the number of items on the menu. It is my firm belief that, in general, users are afraid of reading. When you present them with a long menu, their eyes start to glaze over. Worse, rather than reading through all those options, they will read maybe one or two of them, skim the rest, and then guess. Not good. IMO nine menu choices is *way* too many. I try to shoot for three items on a menu. Four or five is sometimes OK (if the associated text looks short). Anything over five is risky. Further, I believe that, for each extra menu item over two, you lose another segment of your audience to guessing. And time limits don't help the situation. c) Put several of these items on a contingency menu. The Fdisks and FORMAT (and maybe the command prompt) should not be needed if the user chooses one of the target drives on the menu. So put those menu items on a separate menu that is only invoked if the user balks at the choice of drives offered. d) Break out the configure installation menu into a series of menus that the user is forced to go through. Most of these choices are easy choices (e.g. what language do you want, color or monochrome, etc.). Answering them will help raise the user's comfort level with the installation process (by asking him (or her) questions that he *knows* the answer to). Also, I didn't test it but, I get the impression that there are two separate language settings - one for the language to use during the installation process and another for the language that FreeDOS is supposed to use after installation. Is this true? If so, then the menus should probably make that distinction obvious. e) If possible, avoid asking the user about disk sets, base install vs. full install, source or no source, etc. E.g. AIUI for the base cd (without source), there isn't any choice to be made, is there? If so, then asking the user may needlessly confuse them by making them think that they have a choice when they don't. I'm assuming that the installation pgm can determine what's available (to be installed) based on the contents of the CD. Or is that not feasible? I'm going to stop testing the install process now because I'm getting impatient to actually install the software. ... time passes ... I got through the rest of the installation process and it seemed to work. Afterwards I did a sys a: to the same floppy disk that Create a boot floppy failed to write to earlier. Then I booted the PC from that diskette. That worked too. That's all for now. HTH. -Eddie
[Freedos-user] Results of testing fdbasecd.iso dated 08/19/2006
Test environment .486DX4-100 w/32MB RAM .ATAPI cdrom drive .500MB hdd (with ~120MB of unused (no partition defined there) space) .The hdd also contains 2 ~60MB primary partitions and a ~250MB extended partition (which contains a few more (logical) partitions). All partitions are FAT16; some are hidden. .Smart Boot Manager 3.71 (SBM) on a floppy is used to boot from the cdrom (because this PC's BIOS doesn't offer the option of booting from the cdrom drive) .PART 2.37's compact boot manager is installed in the hdd's MBR Beginning the test -- .Powered on the PC. It boots from the hdd. PART 2.37 gets control. .I select A (while PART 2.37 counts down) to boot from the SBM floppy. .I select CD-ROM from SBM's menu. .The cdrom drive reads the FreeDOS CD and the CD presents its first menu. So far, so good. The first menu (these are all text menus, BTW) -- The choices listed are: 1) Boot FreeDOS from CD Works. h) Boot from first harddisk (0x80) I fell into this because of the timeout. The next two lines on the screen are: Booting from local disk... Virus!!! Later I tried this same option manually (by typing h and pressing enter) and got the same result. I believe that the Virus!!! msg is coming from PART 2.37. Fortunately, pressing enter at that point allows PART to continue booting (with no apparent ill effects). a) Boot from first floppy drive (0x00) Works. SBM boots again and it lets me choose to boot from the cdrom again. q) Skip CD-Rom boot (try next boot device) NO ROM BASIC SYSTEM HALTED Obviously this isn't an IBM PC. FWIW SBM's Quit to BIOS option gets this result too. Alt-Ctrl-Del will reboot from here. Editorial comment: Obviously, some of these results are not ideal. Even the first option (though it works) may confuse users. When they see 1) Boot FreeDOS from CD, some users may ask, Isn't that what I just did?. Perhaps this option should read, Continue with FreeDOS installation. And if so, then perhaps there should be an alternative option called abort FreeDOS installation and reboot - for those times when this CD gets booted accidentally. Or should this menu just be dropped completely? Second menu --- After I press 1 on the first menu, I briefly saw a msg that said something about data, memdisk, loading, etc. Unfortunately, I didn't have chance to read it before the screen cleared and the second menu appeared. I hope those msgs weren't important. Another countdown menu. Hurry, hurry, hurry! The 5 choices vs. 2 choices discrepancy has already been explained. Moving on. Pressing 1 leads to the screen clearing and about 7 lines of text appearing. But before I have time to read them all, the screen clears again and presents me with another menu. Third menu -- I press enter to confirm the English (US) selection. Fourth menu -- Please select the drive you want to install FreeDOS on. Only two choices are offered - both wrong. The choices are C: and D:. But I want to install FreeDOS into a new partition in the 120MB of unpartitioned space available on the drive. Apparently, I have to do some prep work for that to happen. Fortunately, there is an escape option. So I press Esc. Escape menu --- 9 choices here. I tried three of them - 3, 5, and 9 (IIRC). .Read instructions on how to use this CD Is it possible to add this option to the first menu that the user sees after booting? Also it might be helpful to add this option to some of the other menus too. .XFdisk see the next section .reboot Option 9, reboot, gave me a brief flash of the screen and then redisplayed the same menu. I tried it several times. I soon noticed that there was a short line of text being displayed (ever so briefly) on the screen each time I pressed 9. Eventually I was able to read that short line of text. The text read No fixed disks present. :-( XFdisk -- I successfully created a new ~120MB primary partition in the empty space using XFdisk. After I created that partition I selected it. There I saw the Install Bootmanager on XFdisk's Options menu. I was curious about it. So I pressed F1 (hoping to get more info about it). Instead I got a dialog box entitled File error. It read, WARNING / Error opening XFDISK.XFH. I found that pressing F1 for each option listed produced the same msg. That's all for now. HTH. -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=lnkkid=120709bid=263057dat=121642 ___ Freedos-user mailing list
