• Binkley problems with 1:300/3

    From Janis Kracht@1:261/38 to All on Friday, April 13, 2012 13:59:18
    Has anyone run into something like this?

    | 13:53 Trying to handshake | CONNECT 16800/ARQ/V34/LAPM/V4
    | 13:53 Trying to handshake | ATZ
    |
    | 13:53 Trying to handshake | OK
    |
    | 13:53 Trying to handshake | CONNECT 16800/ARQ/V34/LAPM/V4
    |


    Passwords are correct.. 1:300/3 can dial here and deliver no problem. Password
    protected sessions constantly fail on session-level though if I dial him.

    Bob writes to me:

    I see you're getting a connect, but no session. As I noted, in dumb
    terminal
    there's stuff from the modem - I did see 'Prism BBS' there. But the
    log/activity > window of Binkley shows nothing. When I dial out,
    Binkley's log/activity window shows all the steps of the connect
    and traffic passing. But not incoming.
    I can connect with you, and all that
    shows up in the activity/log window, but nobody can connect with me - and when
    they try nothing shows up in the activity/log window..
    The flags in binkley.evt are B M R - BBS, Mail >>> Receive.

    Thanks!
    Janis

    --- BBBS/Li6 v4.10 Dada-1
    * Origin: Prism bbs (1:261/38)
  • From Richard Webb@1:116/901 to Janis Kracht on Friday, April 13, 2012 19:07:59
    Hello Janis,

    On Fri 2012-Apr-13 13:59, Janis Kracht (1:261/38) wrote to All:

    Has anyone run into something like this?

    No, but what I'm getting on him is:
    # 13 Apr 18:38:24 BINK Connect 19200

    * 13 Apr 18:38:59 BINK Remote didn't respond

    Double spaced between lines so that word wrap would leave
    them alone. That's what i get when polling him, we've same
    passwords in place as we did have.

    INteresting.

    I was thinking he had his modem in auto answer instead of
    letting bink do it. Wondering what he may have changed
    about his setup from before.

    I'm recalling when he had to move all the Fido stuff to
    anotehr machine we had to do some wrestling with that
    internal modem to get it to let the software handle
    answering.

    iT's a puzzler. Hopefully we can find some help for him.

    Regards,
    Richard
    ---
    * Origin: (1:116/901)
  • From Janis Kracht@1:261/38 to Richard Webb on Friday, April 13, 2012 21:44:10
    Hi Richard,

    Has anyone run into something like this?

    No, but what I'm getting on him is:
    # 13 Apr 18:38:24 BINK Connect 19200

    * 13 Apr 18:38:59 BINK Remote didn't respond

    Double spaced between lines so that word wrap would leave
    them alone. That's what i get when polling him, we've same
    passwords in place as we did have.

    Incoming from Bob works great:

    120413 16:35 Incoming call
    120413 16:44 Incoming call
    120413 16:44 CONNECT 19200/ARQ/V34/LAPM/V42BIS
    120413 16:44 EMSI mail session
    120413 16:44 Bob's Boneyard, 1:300/3.0
    120413 16:44 SysOp: Bob Ackley
    120413 16:44 From: Somewhere
    120413 16:44 Using: BinkleyTerm 2.60/(UNREGISTERED)
    120413 16:44 Flags:
    120413 16:44 Phone: -Unpublished-
    120413 16:44 Speed:
    120413 16:44 Password protected mail session
    120413 16:44 Received: 0027ffdd.fr3 (Zmodem, 5kB, 1474cps)
    120413 16:44 Mail session completed
    120413 16:44 --------------------------

    From me to him though is the problem, as you mention:

    120413 14:03 Calling Bob's BoneYard, 1-712-624-8471
    120413 14:04 CONNECT 19200/ARQ/V34/LAPM/V42BIS
    120413 14:05 Session handshake failed!
    120413 14:07 Calling Bob's BoneYard, 1-712-624-8471
    120413 14:07 CONNECT 19200/ARQ/V34/LAPM/V42BIS
    120413 14:08 Session handshake failed!
    120413 14:10 Calling Bob's BoneYard, 1-712-624-8471
    120413 14:10 CONNECT 16800/ARQ/V34/LAPM/V42BIS
    120413 14:11 Warning: Bad poll count exceeded for 1:300/3.0

    It's been years since I ran binkley.. maybe it's a corrupted file in something like fastlst or whatever nodelist compiler he's got running.. you know, where the passwords are entered for the node, that kind of thing.

    INteresting.

    I was thinking he had his modem in auto answer instead of
    letting bink do it. Wondering what he may have changed
    about his setup from before.

    Nothing that he recalls..

    I'm recalling when he had to move all the Fido stuff to
    anotehr machine we had to do some wrestling with that
    internal modem to get it to let the software handle
    answering.

    This is an external Zoom external 56kb . I sent him the docs for that modem today.. it was online.

    iT's a puzzler. Hopefully we can find some help for him.

    Yep..


    Take care,
    Janis

    --- BBBS/Li6 v4.10 Dada-1
    * Origin: Prism bbs (1:261/38)
  • From Richard Webb@1:116/901 to Janis Kracht on Saturday, April 14, 2012 11:24:33
    Hello Janis,

    On Fri 2012-Apr-13 21:44, Janis Kracht (1:261/38) wrote to Richard Webb:

    Incoming from Bob works great:

    <snip>
    From me to him though is the problem, as you mention:

    YEp, think we're both seeing the same thing, our software
    just logs it differently.

    <snip again>
    I'm recalling when he had to move all the Fido stuff to
    anotehr machine we had to do some wrestling with that
    internal modem to get it to let the software handle
    answering.

    This is an external Zoom external 56kb . I sent him the docs for
    that modem today.. it was online.

    Cool! That'll probably help him because I think this is a
    modem issue more than a binkley issue. ASk him if he's
    changed any of his event flags though, because if he's put
    an s in any event as a flag then he'll call out, but if the
    modem was still in auto answer it would of course answer,
    but I'm doubting he's changed them. But just for grins I'd
    check that.

    I'll bet you he'll find it in the init string he decides on
    for that zoom.

    Will be out of pocket most of today. Will try to connect
    with him this evening.

    iT's a puzzler. Hopefully we can find some help for him.

    Yep..

    Know you saw my note on that the other day. sInce I'm
    non-cm I'd prefer to deliver, otherwise I'll probably steer
    him to you or my friend Mark for a feed. I think this one
    is soluble though, especially now with the modem docs in his hand.


    Regards,
    Richard
    ---
    * Origin: (1:116/901)
  • From Mvan Le@1:343/41 to Janis Kracht on Saturday, September 01, 2012 04:56:56
    120413 14:03 Calling Bob's BoneYard, 1-712-624-8471
    120413 14:04 CONNECT 19200/ARQ/V34/LAPM/V42BIS
    120413 14:05 Session handshake failed!
    120413 14:07 Calling Bob's BoneYard, 1-712-624-8471
    120413 14:07 CONNECT 19200/ARQ/V34/LAPM/V42BIS
    120413 14:08 Session handshake failed!
    120413 14:10 Calling Bob's BoneYard, 1-712-624-8471
    120413 14:10 CONNECT 16800/ARQ/V34/LAPM/V42BIS
    120413 14:11 Warning: Bad poll count exceeded for 1:300/3.0

    It's been years since I ran binkley.. maybe it's a
    corrupted file in something like fastlst or whatever
    nodelist compiler he's got running.. you know, where
    the passwords are entered for the node, that kind of
    thing.

    That looks like a modem problem to me. It looks like there is noise during the EMSI/YooHoo handshake. The corruption is happening during the handshake. There's nothing wrong with the nodelist or session password.

    Maybe you can fix the problem by just sending a normal "CONNECT 19200" without the extended modem status string (or get Bob's modem/system to understand extended strings).

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

    FrontDoor initiating call: ======================================================================= ---------- Sat 01 Sep 12, FD 2.02
    + 22:53:19 Event 0-@
    - 22:53:19 Preparing outbound mail
    22:53:19 No messages to send in this event
    + 22:54:20 Calling ypan.dyndns.org, 3:712/104, 12700000000100024
    = 22:54:24 CONNECT 38400
    ? 22:55:04 No response from remote system
    22:55:04 Terminating call =======================================================================

    BinkleyTerm receiving call: =======================================================================
    + 01 Sep 22:53:30 BINK begin, BinkleyTerm Version 2.60 -uSoft8.0
    : 01 Sep 22:53:30 BINK Starting Event 9
    # 01 Sep 22:54:22 BINK Ring
    # 01 Sep 22:54:23 BINK Connect 38400
    * 01 Sep 22:54:33 BINK Seconds: 13 Tariff: 0 Fee: 0 System: Unknown =======================================================================

    This is between two Virtual Modems on the same computer.

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

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

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

    --- Maximus/2 3.01
    * Origin: Top Hat 2 BBS (1:343/41)
  • From mark lewis@1:3634/12 to Mvan Le on Saturday, September 01, 2012 14:20:35

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

    )\/(ark


    * Origin: (1:3634/12)
  • From Mvan Le@1:343/41 to Mark Lewis on Monday, September 03, 2012 04:39:00
    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?

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

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

    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.

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

    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.

    /me goes off to figure out why those missing files are
    missing and to replace them...
    [/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).

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

    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)
  • From mark lewis@1:3634/12 to Mvan Le on Monday, September 03, 2012 12:40:23

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

    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]

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

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

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

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

    /me goes off to figure out why those missing files are
    missing and to replace them...
    [/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...

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

    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)
  • From Benny Pedersen@2:230/0 to Janis Kracht on Tuesday, February 19, 2013 18:37:44
    Hello Janis!

    13 Apr 2012 13:59, Janis Kracht wrote to All:

    Has anyone run into something like this?

    | 13:53 Trying to handshake | CONNECT 16800/ARQ/V34/LAPM/V4

    that was the days here :)

    Passwords are correct.. 1:300/3 can dial here and deliver no problem. Password protected sessions constantly fail on session-level though if
    I dial him.

    try connect on 2400 baud ?

    Bob writes to me:

    I see you're getting a connect, but no session. As I noted, in dumb
    terminal
    there's stuff from the modem - I did see 'Prism BBS' there. But the
    log/activity > window of Binkley shows nothing. When I dial out,
    Binkley's log/activity window shows all the steps of the connect
    and traffic passing. But not incoming.
    I can connect with you, and all that
    shows up in the activity/log window, but nobody can connect with me - and
    when they try nothing shows up in the activity/log window..
    The flags in binkley.evt are B M R - BBS, Mail >>> Receive.

    is the modem setup with 7 wire ?, or just 3 ?

    is hardware dte ok ?

    i had lots of fun with dte on 930260 with my zyxel ta 128, and isdn :)

    with the old amiga 2000 and cpu just as slow as 7.14 mhz :)


    Regards Benny

    ... there can only be one way of life, and it works :)

    --- Msged/LNX 6.2.0 (Linux/3.5.7-gentoo (i686))
    * Origin: duggi.junc.org where qico is waiting (2:230/0)
  • From Janis Kracht@1:261/38 to Benny Pedersen on Tuesday, February 19, 2013 14:25:04
    Hi Benny!

    is the modem setup with 7 wire ?, or just 3 ?

    is hardware dte ok ?

    i had lots of fun with dte on 930260 with my zyxel ta 128, and isdn :)

    Well this fellow has disconnected from fidonet when his problems couldn't be solved.

    with the old amiga 2000 and cpu just as slow as 7.14 mhz :)

    Bob Atkins not my amiga downlink, I'm not sure what he was running, but it could have been DOS or one of the versions of Windows, I don't remember now..

    Richard Webb probably could answer your questions better than I could since Richard talked with Bob a lot regarding his problems back then.

    Take care,
    Janis

    --- BBBS/Li6 v4.10 Dada-1
    * Origin: Prism bbs (1:261/38)