1. Forum
  2. FidoNet
  3. BBBS.ENGLISH

  • SVDM - Which SBBSEXEC.DLL and DOSXTRN.EXE version?

    From fzf@FQBBS.remove-1067-this@1:342/200 to All on Wed Apr 10 21:52:26 2024
    Path: eternal-september.org!news.eternal-september.org!feeder3.eternal-september.org!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx48.iad.POSTED!not-for-mail
    From: "Fzf" <fzf@FQBBS.remove-1067-this>
    Subject: SVDM - Which SBBSEXEC.DLL and DOSXTRN.EXE version?
    Message-ID: <66175E7A.24039.dove-syncdisc@fqbbs.syncho.net>
    X-Comment-To: Digital Man
    Organization: The Fool's Quarter
    Newsgroups: alt.bbs.synchronet
    In-Reply-To: <6602085F.51503.sync@vert.synchro.net>
    References: <6602085F.51503.sync@vert.synchro.net>
    X-FTN-PID: Synchronet 3.19b-Win32 master/a2a9dc027 Jan 2 2022 MSC 1928 X-FTN-MSGID: 51585.sync@1:103/705 2a7d5eb8
    X-FTN-REPLY: 51503.sync@1:103/705 2a68078e
    X-FTN-CHRS: CP437 2
    WhenImported: 20240410205226-0700 c1e0
    WhenExported: 20240410205534-0700 c1e0
    ExportedFrom: FQBBS dove-syncdisc 24039
    Content-Type: text/plain; charset=IBM437
    Content-Transfer-Encoding: 8bit
    X-Gateway: vert.synchro.net [Synchronet 3.20a-Linux NewsLink 1.114]
    Lines: 38
    X-Complaints-To: https://www.astraweb.com/aup
    NNTP-Posting-Date: Thu, 11 Apr 2024 03:55:36 UTC
    Date: Wed, 10 Apr 2024 20:52:26 -0700
    X-Received-Bytes: 3803
    Xref: news.eternal-september.org alt.bbs.synchronet:39206

    To: Digital Man
    Re: SVDM - Which SBBSEXEC.DLL and DOSXTRN.EXE version?
    By: Digital Man to Fzf on Mon Mar 25 2024 04:27 pm

    1. When SVDM uses an inherited socket (the -h option) no telnet
    negotiations are done.
    I'll be committing a change here to address that - basically send the Telnet commands to re-negotiate those operating parameters (the same sequence that happens when answering an incoming Telnet connection).

    It addresses the local configuration but unfortunately it still doesn't set remote options. The remote is usually going to be in binary mode but SVDM has the remote option set to ASCII by default. A CR from the remote then gets held up until a second byte is sent.

    Sending a DO TX_BINARY near the WILL TX_BINARY when in ServerBinary mode and sending a DONT TX_BINARY when not in ServerBinary but using an external socket sets the remote options to appropriately match what SVDM is expecting. Clients might not like having their TX binary mode turned off mid session, but if someone is disabling binary mode on the server side they are already doing something weird.

    It also sets the remote to binary when SVDM answers in listen mode. At the moment it leaves the remote TX in ASCII at all times.

    I added 2 new .ini settings for you to play with:
    - MainLoopDelay (default: 0, set to 1+ to add CPU yield)
    - SocketSelectTimeout (default: 0, set to 1+ to add CPU yield)

    These work perfectly, thanks! Just a simple 1 ms delay in the main loop drops CPU usage to 0% most of the time.

    I also looked into the error 122 in the SBBSEXEC input_thread when SVDM gets pushed hard, such as during a file transfer. A little additional information on the next waiting mailslot message makes it pretty clear. Sorry, these are going to wrap oddly:

    SBBS: !input_thread: ReadFile Error 122 (space=9411, count=0, nextsize=10000, waiting=46)
    SBBS: !input_thread: ReadFile Error 122 (space=1211, count=0, nextsize=5056, waiting=45)
    SBBS: !input_thread: ReadFile Error 122 (space=9635, count=0, nextsize=10000, waiting=26)

    Etc. There's just not enough space in the ring buffer at the time. While these messages are harmless, the sheer number of them can help thrash a CPU pretty good right at a time when the CPU is busy. I changed the logging to log error 122 at a lower priority so it can be squelched out unless debugging is needed. That further drops the CPU usage when the SVDM is processing a lot of data.

    Does your gitlab accept anonymous updates, or can I send you a diff?

    Thanks again for all your work on this!

    ---
    ■ Synchronet ■ The Fool's Quarter - fqbbs.synchro.net
    --- Synchronet 3.20a-Linux NewsLink 1.114
    * Vertrauen - Riverside County, California - telnet://vert.synchro.net
    * Origin: Joe's BBS (1:342/200)
  • From digital.man@vert.synchro.net.remove@1:342/200 to All on Thu Apr 11 00:24:34 2024
    Path: eternal-september.org!news.eternal-september.org!feeder3.eternal-september.org!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx40.iad.POSTED!not-for-mail
    From: "Digital Man" <digital.man@vert.synchro.net.remove-zdo-this>
    Subject: SVDM - Which SBBSEXEC.DLL and DOSXTRN.EXE version?
    Message-ID: <66178221.51586.sync@vert.synchro.net>
    X-Comment-To: Fzf
    Organization: Vertrauen
    Newsgroups: alt.bbs.synchronet
    In-Reply-To: <66175E7A.24039.dove-syncdisc@fqbbs.syncho.net>
    References: <66175E7A.24039.dove-syncdisc@fqbbs.syncho.net>
    X-FTN-PID: Synchronet 3.20a-Linux master/252b1dc3b Apr 09 202 GCC 12.2.0 X-FTN-MSGID: 51586.sync@1:103/705 2a7d81a3
    X-FTN-REPLY: 51585.sync@1:103/705 2a7d5eb8
    Content-Type: text/plain; charset=IBM437
    Content-Transfer-Encoding: 8bit
    X-Gateway: vert.synchro.net [Synchronet 3.20a-Linux NewsLink 1.114]
    Lines: 75
    X-Complaints-To: https://www.astraweb.com/aup
    NNTP-Posting-Date: Thu, 11 Apr 2024 06:24:36 UTC
    Date: Wed, 10 Apr 2024 23:24:33 -0700
    X-Received-Bytes: 5090
    Xref: news.eternal-september.org alt.bbs.synchronet:39207

    To: Fzf
    Re: SVDM - Which SBBSEXEC.DLL and DOSXTRN.EXE version?
    By: Fzf to Digital Man on Wed Apr 10 2024 08:52 pm

    Re: SVDM - Which SBBSEXEC.DLL and DOSXTRN.EXE version?
    By: Digital Man to Fzf on Mon Mar 25 2024 04:27 pm

    1. When SVDM uses an inherited socket (the -h option) no telnet
    negotiations are done.
    I'll be committing a change here to address that - basically send the Telnet commands to re-negotiate those operating parameters (the same sequence that happens when answering an incoming Telnet connection).

    It addresses the local configuration but unfortunately it still doesn't set remote options. The remote is usually going to be in binary mode but SVDM has the remote option set to ASCII by default. A CR from the remote then gets held up until a second byte is sent.

    Sending a DO TX_BINARY near the WILL TX_BINARY when in ServerBinary mode and sending a DONT TX_BINARY when not in ServerBinary but using an external socket sets the remote options to appropriately match what SVDM is expecting. Clients might not like having their TX binary mode turned off mid session, but if someone is disabling binary mode on the server side they are already doing something weird.

    It also sets the remote to binary when SVDM answers in listen mode. At the moment it leaves the remote TX in ASCII at all times.

    That's a good point. I forgot that we need no negotiate send and receive separately. I just committed a change that does the BINARY_TX negotation for both sides, always (disabling, when server_binary option is disabled). Hopefully this doesn't disrupt anyone else's existing use of SVDM (likely not, I don't think it's getting a lot of use yet).

    I added 2 new .ini settings for you to play with:
    - MainLoopDelay (default: 0, set to 1+ to add CPU yield)
    - SocketSelectTimeout (default: 0, set to 1+ to add CPU yield)

    These work perfectly, thanks! Just a simple 1 ms delay in the main loop drops CPU usage to 0% most of the time.

    Good to know. I'll just make the default MainLoopDelay 1 then.

    I also looked into the error 122 in the SBBSEXEC input_thread when SVDM gets pushed hard, such as during a file transfer. A little additional information on the next waiting mailslot message makes it pretty clear. Sorry, these are going to wrap oddly:

    SBBS: !input_thread: ReadFile Error 122 (space=9411, count=0, nextsize=10000, waiting=46)
    SBBS: !input_thread: ReadFile Error 122 (space=1211, count=0, nextsize=5056, waiting=45)
    SBBS: !input_thread: ReadFile Error 122 (space=9635, count=0, nextsize=10000, waiting=26)

    Etc. There's just not enough space in the ring buffer at the time.
    these messages are harmless, the sheer number of them can help thrash a CPU pretty good right at a time when the CPU is busy. I changed the logging to log error 122 at a lower priority so it can be squelched out unless debugging is needed. That further drops the CPU usage when the SVDM is processing a lot of data.

    Are you running DebugView or something similar that's capturing these log messages? That would explain the additional CPU usage.

    Does your gitlab accept anonymous updates, or can I send you a diff?

    No, you need an account on gitlab.synchro.net to submit a merge request. You could send me a diff, but a merge request is preferred. That said, a patch/MR that just lowers the severity of that log message probably wouldn't be accepted without more justification (i.e. running without DebugView or equivalent, should see no CPU impact by those log messages).

    Thanks again for all your work on this!

    Thank you for the test reports and suggestions!
    --
    digital man (rob)

    This Is Spinal Tap quote #18:
    Sustain, listen to it. Don't hear anything. You would though were it playing. Norco, CA WX: 63.5°F, 49.0% humidity, 0 mph ENE wind, 0.00 inches rain/24hrs --- Synchronet 3.20a-Linux NewsLink 1.114
    * Vertrauen - Riverside County, California - telnet://vert.synchro.net
    * Origin: Joe's BBS (1:342/200)