FidoNet Echomail Archive

<<< Previous Index Next >>>

From: mark lewis
To: Mvan Le
Date: 2012-09-01 14:20:34
Subject: Binkley problems with 1:300/3

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


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

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

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


 * Origin:  (1:3634/12)
SEEN-BY: 3/0 633/267 640/954 712/0 101 313 550 620 848 953
@PATH: 3634/12 123/500 261/38 712/848 633/267

<<< Previous Index Next >>>