Subj : Binkley problems with 1:300/3
To   : Mvan Le
From : mark lewis
Date : Mon Sep 03 2012 12:40 pm


ml> MvanLe> This is between two Virtual Modems on the same computer.

ml> what OS? and is this also in a Virtual Machine?

MvanL> Windows XP. No, this is happening on a physical machine.

ahhh... ok... what virtual modem software?

MvanL> The problem is workable by simply minimising all open windows.
MvanL> This problem was just an observation after many hours of
MvanL> frustration (and reluctance to give up on FrontDoor).

i can understand that... i still run FD on my POTS and telnet/vmodem system ;)

[trim]

ml> this is possible... it is one of the reasons why i ask
ml> what OS and if this is in a VM... you haven't stated
ml> what version of FD you're testing with... if you did
ml> then i missed it... sorry...

MvanL> Even on a VM the CPU would still be hit by real-mode DOS apps. I
MvanL> haven't found any good workaround for these problems. It's the
MvanL> nature of DOS apps.

possibly... have you tried TAME to tame them down and force timeslices to be
released more often? especially in tight loops...

ml> [EDIT]
ml> i went back and looked at your post again... i see that
ml> the log snippet does show FD v2.02 being used... that
ml> version is extremely ancient and i can easily see it
ml> having the problem you describe... i don't even have
ml> that one in my historical archives (/me frowns about
ml> that) but i do have the DOS and OS/2 versions of FD
ml> v2.26 and i've the patches to update FD v2.30 to v2.31
ml> then to 2.32 and finally to 2.33... i'd try your tests
ml> again with a newer version of FD ;)

MvanL> FD 2.02 was released in 1991. That is why it is cool to use. It is
MvanL> also freeware (the only freeware version of FD). The most popular
MvanL> was FrontDoor 2.12.

yes, i definitely remember :)

MvanL> I don't think the version of FD matters.

yes, it does matter... newer versions when thru some heavy rewrites...
partially for timeslicing problems and partially for comms problems on
multitasking systems... but new and more efficient code was also desired and so
the work was done...

MvanL> The problem will still exist because I can see the CPU at 100%
MvanL> when navigating the FD 2.12/2.26 menus in an open (non-full
MvanL> screen) window.

still not new enough... i don't know if that one took any rewrites in those
areas or not... i wasn't invited to join the FD Beta Team until May '95... all
the real good stuff came after that... especially one huge and major rewrite...

MvanL> The solution would be a 32-bit version of FD but I don't think
MvanL> there are any.

i'm not sure, TBH, but i definitely do not see the problems you are reporting
on my OS/2 setup... not with the DOS flavor nor the native OS/2 flavor...
besides, bitness doesn't really have anything to do with tight code loops
eating 100% CPU... i have a native 32bit windows app that chews up several
dozen txt files and merges them together keeping the most recent duplicate
entries, flushing expired old entries and sorting everything as needed before
emitting the final output file... it chews 100% CPU for the little bit of time
it takes to run... it does in 15 seconds what the app it replaces takes 30 to
45 minutes to do... that old app has the 64k memory allocation limitation...
the final output of my 32bit program is 36000+ lines whereas the final output
of the old app is only 6000 lines... this all due to memory constraints but i
diverged... sorry...

anyway, in my 32bit app, i've not done anything to handle timeslicing... i'm
using everyday, well used, tested and vetted library routines... i haven't even
inquired of the compiler and library folks if i can give up slices like i do in
my 16bit DOS apps... most of those (16bit DOS apps) run bursty to about 10% CPU
usage but if i remove the timeslicing, they complete their task in seconds
compared with a minute or two to when slicing to stay friendly with other
apps... so back to the native 32bit code stuff... it gobbles the CPU but is
done and complete in seconds... that with some several hundred MEG of RAM
allocated during execution... where the CPU usage comes from in this particular
app i'm not sure but the point of this was that bitness doesn't have anything
to do with timeslicing... but now i've gotta go make those inquiries and find
out if i can reduce the CPU usage during my apps execution...

ml> /me goes off to figure out why those missing files are
ml> missing and to replace them...
ml> [/EDIT]

MvanL> Do you have your system in Escrow ? - Just in case you die of a
MvanL> heart attack or aneurism or something, then somebody can takeover
MvanL> your BBS (and files).

hahaha... no... i'm sure that someone could figure it out, though... however,
when i have to go in to make changes and i haven't done so in a while, even i
have to study its flow and locate exactly where to make the changes...
especially since things can run on either the DOS or OS/2 side, at any time,
and either side can fire up a task to run on the other side at any time...

ml> MvanLe> FrontDoor is 16-bit DOS and probably not giving enough
ml> MvanLe> timeslices. I am using BinkleyTerm 16-bit DOS but I suspect
ml> MvanLe> that even the 16-bit DOS version of BinkleyTerm handles
ml> MvanLe> timeslices better than FrontDoor.

ml> back in the day, programs did need to give up timeslices but that
ml> shouldn't be all that necessary any more... i see some problems
ml> when a program is in a tight polling loop, though... but this also
ml> depends on the program... my 16bit stuff still contains slicing
ml> code but my newer stuff doesn't and doesn't seem to need it...

MvanL> The problem is that a lot of 16-bit DOS apps don't timeslice at
MvanL> all, causing the NTVDM to struggle badly. In the end the best
MvanL> way to beat laggy DOS apps is to buy an i7.

hahaha! yeah but they're still laggy... they just lag faster and are done
lagging before the humans notice it ;)

but seriously, the system i speak of above is only a PIII 800mhz with only
384Meg of RAM... while it is faster than the PII 300mhz 112Meg RAM it just
replaced, neither has been laggy or slow for the work they do and the new one
still does the same work as before... new OS on the boot drive but everything
else on the other drives is still the same as it ever was...

but i still think you might find some benefit from TAME... maybe... possibly...

)\/(ark


* Origin:  (1:3634/12)