-1

I'm trying to communicate with a commercial power supply device via TCP/IP using python sockets.

I tried using both a virtual linux(centos8stream) and virtual windows10, both running at the same physical computer, on the same network interface. Both have python3.9.

I imagined the tcp/ip sockets would work same in both OS, but I got some communication issues ONLY in linux:

  • The delay between send and receive becomes much longer(2 sec instead of 0.14 sec) after few tries
  • Sometimes I hit the timeout and can't communicate with the device at all.

I got Wireshark running in both OS:

  • In windows there are no unusual messages (very rarely there is a TCP Retransmission)
  • In linux, after a while (or sometimes immediately) wireshark is flooded with TCP Dup Ack, TCP Fast Retransmission and TCP Spurious Retransmissions.

My question:

  1. What could be the source of the difference? Are there any socket options I can experiment with?
  2. Is there a way to compare network parameters in linux and windows10?

A sample program to continuously read device identification:

import socket
from time import sleep,time
HOST = '10.27.4.50'
PORT = 4444

#Create object and open the connection
client = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
client.connect((HOST, PORT))

client.settimeout(5)

# Read identification
message=(b'*IDN?\r\n')

for i in range(5):
    start_time = time()
    client.sendall(message)
    rep=client.recv(1024)
    print("Trial {}, delay: {} seconds ".format(i,time() - start_time))
    sleep(1)

client.close()

windows:

Trial 0, delay: 0.17121100425720215 seconds
Trial 1, delay: 0.10957813262939453 seconds
Trial 2, delay: 0.17148327827453613 seconds
Trial 3, delay: 0.13976049423217773 seconds
Trial 4, delay: 0.14109373092651367 seconds

linux(See that last message took longer to receive response, this corresponds to start of TCP errors)

Trial 0, delay: 0.15080499649 seconds
Trial 1, delay: 0.143104076385 seconds
Trial 2, delay: 0.170531988144 seconds
Trial 3, delay: 0.183187961578 seconds
Trial 4, delay: 2.0480530262 seconds

Note: I also tried a physical linux machine, with same issues.

Cenkoloji
  • 21
  • 3
  • I don't think virtualization is the issue, the result is same if I use a physical computer to communicate the device. What bothers me is the difference between linux and windows. – Cenkoloji Apr 28 '21 at 07:32

1 Answers1

1

I figured the problem was related to tcp timestamps. In linux, by default tcp_timestamp is enabled, in windows it's disabled.

Disabling tcp timestamps on linux, solves the problem:

sysctl -w net.ipv4.tcp_timestamps=0

Conversely, enabling timestamps on windows reproduces the same problem I observed on linux.

netsh int tcp set global timestamps=enabled

Digging a bit further, I saw that the tcp errors such as Dup Ack started occurring when device sends a packet, with a timestamp lower then of the previous packet. Probably there is a bug in the hardware/firmware of device and it creates faulty timestamps.

Cenkoloji
  • 21
  • 3