gpt4 book ai didi

python - python应用程序中不可靠的RTT问题

转载 作者:行者123 更新时间:2023-12-03 12:07:45 25 4
gpt4 key购买 nike

我在获取服务器 pc(Windows 10)和 Jetson Nano(生产模块,Ubuntu 18.04)之间的 tcp 通信的可靠响应时间时遇到了大问题。在测试 Python 应用程序中,每 200 毫秒会向 Nano 设备发送一条小消息。 Jetson Nano 应用程序上的应用程序立即将此消息发送回服务器。在使用的端口上没有其他通信发生(除了一些 ssh)。
从发送消息到收到响应的时间是在服务器 pc 上测量的。我期望的是,由于消息大小较小(<=1024byte),RTT 在 0.5-2ms 范围内。

我得到的是消息> = 70字节的不可靠RTT:

#Response time for message sent to Jetson Ubuntu client
#message size is in bytes (payload)
size:16 min: 0.45ms max: 0.84ms median: 0.48ms mean: 0.52ms
size:32 min: 0.54ms max: 0.75ms median: 0.61ms mean: 0.62ms
size:64 min: 0.48ms max: 0.67ms median: 0.56ms mean: 0.56ms
size:128 min: 0.64ms max: 247.83ms median: 40.11ms mean: 58.48ms
size:256 min: 0.63ms max:261.75ms median: 96.22ms mean: 121.33ms
size:512 min: 0.51ms max: 824.84ms median: 203.29ms mean: 244.38ms
size:68 min: 0.44ms max: 0.52ms median: 0.48ms mean: 0.48ms
size:69 min: 0.44ms max: 0.66ms median: 0.51ms mean: 0.53ms
size:70 min: 0.53ms max: 304.98ms median: 155.83ms mean: 160.78ms
size:71 min: 0.49ms max: 602.15ms median: 120.64ms mean: 197.52ms
size:72 min: 0.54ms max: 509.05ms median: 132.59ms mean: 154.70ms


我的代码:
import socket
import time
import numpy as np

class MySocket():
def __init__(self,sock=None):
if sock is None:
self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
self.sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)
else:
self.sock = sock
self.sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)
def connect(self,host,port):
self.sock.connect((host,port))
def listen(self,host,port):
self.sock.bind((host, port))
self.sock.listen(5)
def accept(self):
(clientsocket, address) = self.sock.accept()
return (clientsocket, address)
def send(self,msg):
msglen = len(msg)
sent = self.sock.sendall(msg)
if sent == 0:
raise RuntimeError("socket connection broken")
def recv(self):
# just assume the messages are small for the moment
# and we receive just one chunk
return self.sock.recv(4096)
def ping(self,msg):
self.send(msg)
recv_data = self.recv()
if len(msg) != len(recv_data):
print(f'Package sizes do not match! {len(msg_b)} to {len(recv_data)}')

# Server app will send some messages with different sizes to the connected client
if __name__ == "__main__":
myserver = MySocket()
myserver.listen('',8754)

while True:
(clientsocket, address) = myserver.accept()
myclientSocket = MySocket(clientsocket)

#build up a list of messages with different sizes
msg_list = []
for k in range(4,10):
msg = 'p'*(2**k)
msg_b = msg.encode()
msg_list.append(msg_b)

# add a couple of messages with size in problematic range
for k in range(68,73):
msg = 'p'*(k)
msg_b = msg.encode()
msg_list.append(msg_b)

# in productive environment we will probably send a message each 0.2 to 1.0sec to the client
# to simulate this, sleep a little bit before each send
sleep_time = 0.2
#send each message couple of times and measure response time
for msg_b in msg_list:
timings=[]
for l in range(0,10):
time.sleep(sleep_time)
start_time = time.perf_counter()
myclientSocket.ping(msg_b)
timings.append((time.perf_counter() - start_time)*1000)
print(f'size:{len(msg_b)} min: {min(timings):.2f}ms max: {max(timings):.2f}ms median: {np.median(timings):.2f}ms mean: {np.mean(timings):.2f}ms')

'''
# Client app will receive a message and send it back immediately
if __name__ == "__main__":
myclient = MySocket()
myclient.connect('192.168.2.134',8754)

while True:
msg = myclient.recv()
if msg is None:
continue
myclient.send(msg)
'''

到目前为止我尝试了什么:
  • 将客户端 (Jetson Nano) 替换为另一个 Jetson Nano(相同修订版):结果相同,RTT 不可靠
  • 用不同的基于 Ubuntu 的 PC 替换客户端 (Jetson Nano),结果:每个消息大小的 RTT 在 1-2 毫秒内符合预期
  • 用不同的系统替换服务器(Windows PC),结果:每个消息大小在 1-2 毫秒内按预期进行 RTT
  • 在 Jetson Nano 上使用 USB3.0-以太网适配器而不是内置的 Realtek 以太网 Controller ,结果:每个消息大小的 RTT 在 1-2 毫秒内达到预期

  • 从我有限的角度来看,问题似乎在于 Jetson Nano 设备,特别是以太网 Controller 。

    但我现在没有想法。什么会导致这种行为?它可能与硬件有关吗?
    很高兴听到你的建议:)

    小更新:

    在 Ubuntu PC 上进行了测试以 ping Jetson Nano 设备。基本上从等式中删除 Windows 作为服务器和 Python 应用程序。双方的线路上没有其他流量。
    ping -s 82 -c 100 192.168.2.115

    90 bytes from 192.168.2.115: icmp_seq=1 ttl=64 time=109 ms
    90 bytes from 192.168.2.115: icmp_seq=2 ttl=64 time=305 ms
    90 bytes from 192.168.2.115: icmp_seq=3 ttl=64 time=0.401 ms
    90 bytes from 192.168.2.115: icmp_seq=4 ttl=64 time=295 ms
    90 bytes from 192.168.2.115: icmp_seq=5 ttl=64 time=131 ms
    90 bytes from 192.168.2.115: icmp_seq=6 ttl=64 time=294 ms
    90 bytes from 192.168.2.115: icmp_seq=7 ttl=64 time=0.473 ms
    90 bytes from 192.168.2.115: icmp_seq=8 ttl=64 time=263 ms
    90 bytes from 192.168.2.115: icmp_seq=9 ttl=64 time=130 ms
    90 bytes from 192.168.2.115: icmp_seq=10 ttl=64 time=260 ms
    ...

    > = 90字节数据包的延迟偏差非常大。 eth0 是否有一些设置可能与此行为相关,并且可能会改善小消息的延迟?

    最佳答案

    听起来“Windows 作为服务器 PC”和“Realtek 作为客户端中的以太网适配器”共同导致了这个问题;更换其中之一,问题就消失了。

    因此,您可以监控 TCP/IP 流量,以验证 Windows PC 和客户端之间是否仍有一些额外的流量或速度缓慢,这可能解释了 Windows 导致性能缓慢的原因:在 Windows 中,Wireshark 软件可以窥探以太网流量,在 Linux 客户端中 tcpdump可以分析持续的流量。

    至于 Realtek 以太网部分,您可以检查您的 Realtek 设备驱动程序版本号并验证自您在客户端系统中使用的内核版本以来是否进行了任何更新:lsmod命令列出设备驱动程序,modinfo显示有关设备驱动程序模块的信息。

    关于python - python应用程序中不可靠的RTT问题,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/61776111/

    25 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com