SYNCHRONET--------------- < Пред. | След. > -- < @ > -- < Сообщ. > -- < Эхи > --
 Nп/п : 69 из 100
 От   : Digital Man                         1:103/705         10 апр 24 23:24:33
 К    : Fzf                                                   10 апр 24 09:25:02
 Тема : SVDM - Which SBBSEXEC.DLL and DOSXTRN.EXE version?
----------------------------------------------------------------------------------
                                                                                 
@MSGID: 51586.sync@1:103/705 2a7d81a3
@REPLY: 51585.sync@1:103/705 2a7d5eb8
@TZUTC: -0700
@PID: Synchronet 3.20a-Linux master/252b1dc3b Apr 09
202 GCC 12.2.0
@TID: SBBSecho 3.20-Linux master/252b1dc3b Apr 09
2024 18:02 GCC 12.2.0
@COLS: 80
@BBSID: VERT
@CHRS: CP437 2
@NOTE: FSEditor.js v1.105
  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.
 >  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.

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

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

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
--- SBBSecho 3.20-Linux
 * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
SEEN-BY: 50/109 103/705 154/10 218/700 221/1
240/1120 280/464 301/1 113
SEEN-BY: 341/66 463/68 467/888 712/848 3634/12
5000/111 5005/49 5019/40
SEEN-BY: 5020/715 848 1042 4441 12000 5030/49 1081
5054/8 5060/900 5061/133
SEEN-BY: 5075/128 5083/444
@PATH: 103/705 301/1 5020/1042 4441



   GoldED+ VK   │                                                 │   09:55:30    
                                                                                
В этой области больше нет сообщений.

Остаться здесь
Перейти к списку сообщений
Перейти к списку эх