sharpbai
目前在长肥管道下如果想达到高带宽利用率，存在以下矛盾 在「发送与接收端的RTT」大于「协议处理周期」(即interval参数)时，不存在同一个发送窗口的尺寸，在发送策略为窗口中有数据就应发尽发的策略下，既满足一次性突发传输的速率不超过预设带宽，又能保持持续传输达到预设带宽。 举例：发送端与接收端固有物理带宽均为200mbps，平均RTT为90ms，kcptun的发送周期为20ms, kcptun的mtu设置为1400 为了达成持续发送时窗口容纳BDP的数据，配置发送窗口为1536。但这会造成在突发传输时，20ms内的峰值带宽达到持续传输的(RTT/发送周期)倍数，即4.5倍，实际峰值带宽会达到约900mbps。 一方面，发送数据超过实际带宽对于数据传输延迟造成不利影响，另一方面，这种行为是不被服务商允许的，实际效果是在突发传输后，AWS与ALI/TX的机器间会出现对应端口传输的数据RTT变为1000ms的惩罚措施，该惩罚持续时长为60s。 目前通过tc在发送端机器与接收端机器把发送速度限制到200mbps，同时做20ms的发送平滑措施，没有出现过一次惩罚问题，也没有因此而产生过断流问题。 但这个措施只是保底解决被惩罚的问题，在突发期被tc丢弃的数据会依赖重传，这部分数据会增大其传输延迟。不如直接从源头上控制发送速率，达成更低的传输延迟。这样也更符合KCP的设计目标——为流速优化 所以建议增加最大发送带宽限制功能，针对底层的单个KCP连接，根据配置的最大发送速率决定一次发送的最大数据量，而不是窗口有空间就全部发出去。 如果在kcptun层面，增加配置单个端上连接的最大发送带宽与接收带宽，并在发送时协商，让对端的发送速率匹配到其发送速率与我方接收速率的最低值，则更为方便。
Fix parsing error when duplicate 00 00 00 01 occurs. For example 00 00 00 01 00 00 00 01 Original code will bypass first startcode but not modify "p"...
It seems that conda torch 1.12 will be overrided by pip torch 2.0 due to peft requires torch 1.13 So I changes the torch version to 1.13.1 and torchvision to...
Jarvis looks interesting. I have to manually build docker since there is no prebuilt official Jarvis docker image. It will be more convenient to have a official prebuilt docker image...
macOS do not support SCTP protocol and SOCK_CLOEXEC flag. So I have changed SCTP to TCP protocol and set SOCK_CLOEXEC to 0 for macOS.
Although the project's name includes "OS" I haven't seen any code related to an operating system. Is it really an operating system project?