Subj : Binkley problems with 1:300/3
To   : Mark Lewis
From : Mvan Le
Date : Mon Sep 03 2012 04:39 am

ml> MvanLe> I can reproduce one-sided-only handshake problems between
ml> MvanLe> FrontDoor  and Binkleyterm (where FrontDoor->BinkleyTerm is
ml> MvanLe> problematic but BinkleyTerm->FrontDoor is successful).

ml> [trim]

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

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

Windows XP. No, this is happening on a physical machine. The problem is
workable by simply minimising all open windows. This problem was just an
observation after many hours of frustration (and reluctance to give up on
FrontDoor).

ml> MvanLe> There is no problem when BinkleyTerm initiates a call to
ml> MvanLe> FrontDoor.  The handshake is fast and smooth to observe and
ml> MvanLe> completes successfully.

ml> MvanLe> I have found that this problem is determined by which window
ml> MvanLe> is in the foreground while the handshake is in progress. CPU
ml> MvanLe> is 100% if FrontDoor is in the foreground while a handshake
ml> MvanLe> with BinkleyTerm is in progress, and I suspect that this
ml> MvanLe> causes a delay with sending data during the handshake to
ml> MvanLe> BinkleyTerm.

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...

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

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 ;)

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

I don't think the version of FD matters. The problem will still exist because I
can see the CPU at 100% when navigating the FD 2.12/2.26 menus in an open
(non-full screen) window. The solution would be a 32-bit version of FD but I
don't think there are any.

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

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

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
ml> timeslices but that shouldn't be all that necessary any
ml> more... i see some problems when a program is in a
ml> tight polling loop, though... but this also depends on
ml> the program... my 16bit stuff still contains slicing
ml> code but my newer stuff doesn't and doesn't seem to
ml> need it...

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


--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)