TID: PX/Win v7.0 PX98-1008M   
   MSGID: 1:342/200 f3ef8d96   
   TZUTC: -0600   
   Path: eternal-september.org!news.eternal-september.org!feeder3.e   
   ernal-september.org!usenet.blueworldhosting.com!diablo1.usenet.b   
   ueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.h   
   ghwinds-media.com!fx48.iad.POSTED!not-for-mail   
   From: "Fzf"    
   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.   
    DM> I'll be committing a change here to address that - basically send the   
    DM> Telnet commands to re-negotiate those operating parameters (the same   
    DM> 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.   
      
    DM> I added 2 new .ini settings for you to play with:   
    DM> - MainLoopDelay (default: 0, set to 1+ to add CPU yield)   
    DM> - 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)   
   SEEN-BY: 15/0 90/1 105/81 106/201 128/260 129/305 135/220 225 153/7715   
   SEEN-BY: 218/700 226/30 227/114 229/110 112 113 206 317 426 428 470   
   SEEN-BY: 229/550 664 700 266/512 282/1038 291/111 292/854 320/219   
   SEEN-BY: 322/757 342/200 201 396/45 460/58 633/280 712/848 5075/35   
   PATH: 342/200 229/426