Critcal=1
Raise the priority of the outgoing thread from High to Critcal.
NoShotrSleep=2
Busy-wait if the time until the next transmission is less than 100us.
NoSleep4Code=4
Busy-wait when the number of CPU cores is 4 or more (do not sleep when CPU 4 or more)
SocketNoBlock=8
Do not send blocked sockets (do not wait for transmission to complete before proceeding)
OccupiedCPU=16
Occupied CPU core number 3 or 2
FEEDBACK=32,64,128 (moving average)
Use a moving average to calculate the feedback that determines the transmission cycle (1 to 7)
NOFASTFEEDBACK=256
Stops the process of temporarily sending more packets for retransmissions, etc.
IDLEONE=512
Turn busy wait (no sleep) into IDLE processing (sleep 0), limited to once between transmissions.
IDLEALL=1024
IDLE processing (Sleep0) with Busy Weighting (not Sleep)
NOSLEEPFORCE=2048
Force Busy Weighting
I'm not confident that everything will work correctly in the parts I don't change much.
I'm not even sure it will behave the same if the OS changes.
Case Windows:
When not running as a service, the thread priority is not maximized.
Therefore, if you have a CPU with more than 4 cores, you can use Critcal and Busy Weight at the same time.
Case Linux:
Simultaneous use of Critcal and Busy Weight often leads to bad results
It can interfere with the operation of other applications
They depend on the kernel's configuration and CPUarchitecture implementation.
If it is CONFIG_PREEMPT (preemption kernel)
If you have a CONFIG_PREEMPT (preemption kernel), it is recommended to use Critcal and not use busyweight.
Please note that RTKernel has a different approach to thread
I don't know of any stable behavior when changing thread priority, except in the commercial version
Some environments will work, but they will not be supported.
Translated with www.DeepL.com/Translator (free version)