Sorry for the delay. The main news in this message is that patch for 354208 doesn't seem to have much to do with this problem.
On Mon, May 08, 2006 at 10:02:29AM +0200, Bart Martens wrote: > Hi Ross, > > Thanks for the good info. It seems that setting $_hogthreshold to (2) > in dosemu.conf is a quick workaround for you. > > I did some reading about $_hogthreshold. My interpretation of the > documentation is that (1) should be a sensible default, good for most > DOS applications. Shipping dosemu in Debian with (1) feels like the > right thing to do. Absent a strong reason to do otherwise, sticking with upstream's default seems like a good idea. I think Debian does this at the moment: with no explicit setting of hogthreshold it goes to the default value of 1. My concern was more with how (x)dosemu behaved at that setting. > > I want to leave this bug open for a while so that other dosemu users can > report their experiences with $_hogthreshold with other DOS > applications. Maybe there's a problem with how $_hogthreshold is > implemented. > > To verify whether this bug is related to 354208, you may want to try > reproducing the problem with debian/patches/07toofast.dpatch removed. > To help you with that, I have created this temporary dosemu package > version 1.2.2-3.0.1. It is version 1.2.2-3 without > debian/patches/07toofast.dpatch. Use at your own risk. :) > http://knars.be/bartm/debian/dosemu_1.2.2-3.0.1_i386.deb Thanks very much. My test with that version shows that patch is *not* the cause of the problem; I get the same behavior with and without it. For what it's worth, using your 1.2.2-3.0.1 version I found a more gradual response to hogthreshold. For my test operation, the values were default (1): much longer than I could stand, 10-15 minutes 2: 90 seconds 3: 50 seconds 5: 30 seconds Even with 5 the other program (GrandView) that used to use up all the CPU used hardly any. I think that with the patch the response was a bit faster to increases in hogthreshold, but my memory could be off. The new code permits better tuning and performance than the old (1.2.1) code, but seems to require more manual customization to get this result. I don't know if there's anything that can be done about the extremely slow performance with the default settings. Some of the other messages in this bug mention that additional sleep or sleep-like hooks got added between 1.2.1 and 1.2.2. I guess they were sufficient to really slow down MYM (the program that inspired this bug report), and finally permitted some control over GrandView (the one that was using all the CPU). Given the information that the throttling is being done by hooks in the DOS level, it sounds as if I might get different behavior with freedos. I'll try to get to that. It sounds as if the throttling of hogthreshold is pretty simple, e.g., sleep x every time certain calls are made. Perhaps a more sophisticated strategy could reduce sleeping if a lot of calls are being made. But I'm speculating here, and at any rate the benefit of such a tweak might not justify the effort. P.S. I didn't discover some of the comments til I looked on the web. As the bug submitter, shouldn't I get copies of all the mail to the bug? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
