Subj : Binkley problems with 1:300/3
To : Mvan Le
From : mark lewis
Date : Sat Sep 01 2012 02:20 pm
MvanLe> I can reproduce one-sided-only handshake problems between
MvanLe> FrontDoor and Binkleyterm (where FrontDoor->BinkleyTerm is
MvanLe> problematic but BinkleyTerm->FrontDoor is successful).
[trim]
MvanLe> This is between two Virtual Modems on the same computer.
what OS? and is this also in a Virtual Machine?
MvanLe> There is no problem when BinkleyTerm initiates a call to
MvanLe> FrontDoor. The handshake is fast and smooth to observe and
MvanLe> completes successfully.
MvanLe> I have found that this problem is determined by which window
MvanLe> is in the foreground while the handshake is in progress. CPU
MvanLe> is 100% if FrontDoor is in the foreground while a handshake
MvanLe> with BinkleyTerm is in progress, and I suspect that this
MvanLe> causes a delay with sending data during the handshake to
MvanLe> BinkleyTerm.
this is possible... it is one of the reasons why i ask what OS and if this is
in a VM... you haven't stated what version of FD you're testing with... if you
did then i missed it... sorry...
[EDIT]
i went back and looked at your post again... i see that the log snippet does
show FD v2.02 being used... that version is extremely ancient and i can easily
see it having the problem you describe... i don't even have that one in my
historical archives (/me frowns about that) but i do have the DOS and OS/2
versions of FD v2.26 and i've the patches to update FD v2.30 to v2.31 then to
2.32 and finally to 2.33... i'd try your tests again with a newer version of FD
;)
/me goes off to figure out why those missing files are missing and to replace
them...
[/EDIT]
MvanLe> FrontDoor is 16-bit DOS and probably not giving enough
MvanLe> timeslices. I am using BinkleyTerm 16-bit DOS but I suspect
MvanLe> that even the 16-bit DOS version of BinkleyTerm handles
MvanLe> timeslices better than FrontDoor.
back in the day, programs did need to give up timeslices but that shouldn't be
all that necessary any more... i see some problems when a program is in a tight
polling loop, though... but this also depends on the program... my 16bit stuff
still contains slicing code but my newer stuff doesn't and doesn't seem to need
it...
