[andrewkrot 0]

• Ну или так - netstat -s -p udp -t 5

[excly 0]

5 hours ago, RobFPGA said:

Приветствую!

Ethernet не гарантирует  доставку пакетов - потеря может быть как по "электрической" причине (помехи)  так и про причине неготовности приемника - отсутствие свободного места в приемном буфере как в самой карте так и в TCP/IP стеке. 

 

Электрические проблемы видны по  дропу пакетов по ошибке Ethernet frame CRC

 

Ну а бороться с потерями в приемнике  можно путем оптимизации параметров стека в PC. Так же можно попробовать включить для MAC в FPGA и сетевой кары в PC режим packet lossless - что то типа xon|xoff протокола на MAC уровне. В этом режиме приемник тормозить передатчик на время если видит что не может принять пакет.  

 

Но для начала не плохо бы вам проверить всю приемную часть генерируя пакеты с другого компа. 

Удачи! Rob.

Попробовал между 2 компами. Потери примерно такие же. Значит дело в приемной части. Приемный софт писал не я. Сейчас набросал простенький скрипт на Python, который принимает и пишет в файл. Все равно ошибки. Вот код приемного скрипта

import socket
import sys

UDP_PORT = 50016
sock = socket.socket(socket.AF_INET,socket.SOCK_DGRAM)
sock.bind(('', UDP_PORT))

with open(sys.path[0] + '\\data.bin', 'wb') as file:
    while True:
        data = sock.recv(2048)
        file.write(data)
        if not data:
            break

    sock.close()

Изменено 28 января, 2019 пользователем excly

[new123 0]

я про питон не совсем в курсе, но на Си такой код легко отработает плохо, писать на жесткий диск дороговато по времени, я с таким столкнулся уже как раз с udp. Я бы переделал под запись в память, потом сброс в файл.

плюс у вас правильно спросили, какого размера приемный буфер, он может быстро заполняться и не успевать принимать.
для уверенности запустили бы лучше wireshark (tcpdump под Linux), там хоть приемная часть точно отработает

Изменено 28 января, 2019 пользователем new123

[RobFPGA 27]

Приветствую!

8 minutes ago, excly said:

UDP_PORT = 50016
sock = socket.socket(socket.AF_INET,socket.SOCK_DGRAM)

Я бы добавил  sock.setsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF, RX_BUF_SIZE)

а для  sock.recv(2048)  поставил бы размер чуть более чем макс. размер пакета. На сколько я понимаю размер в recv(..) ограничивает размер данных из пакеты передаваемых за вызов фукнкции,  а SO_RCVBUF задает размер приемного буфера сокета.

Но игра с буферами может ничего не дать если проблемы сидят в тормозах на уровне драйвера карточки. Опять же надо видеть картину  - есть ли дроп пакетов на сетевой карте и по какой причине. 

Ну и надеюсь у вас  соединение точка-точка а не через общую сетку со всякими свичами

Удачи! Rob.

[Maverick_ 15]

как альтернатива, применить другой ввод данных

[_4afc_ 24]

8 hours ago, excly said:

Данные идут потоком без остановки. Нужно эти данные выводить на PC.

Чипсет Ethernet на PC надеюсь Intel?

[excly 0]

16 hours ago, RobFPGA said:

Приветствую!

Я бы добавил  sock.setsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF, RX_BUF_SIZE)

а для  sock.recv(2048)  поставил бы размер чуть более чем макс. размер пакета. На сколько я понимаю размер в recv(..) ограничивает размер данных из пакеты передаваемых за вызов фукнкции,  а SO_RCVBUF задает размер приемного буфера сокета.

Но игра с буферами может ничего не дать если проблемы сидят в тормозах на уровне драйвера карточки. Опять же надо видеть картину  - есть ли дроп пакетов на сетевой карте и по какой причине. 

Ну и надеюсь у вас  соединение точка-точка а не через общую сетку со всякими свичами

Удачи! Rob.

Спасибо огромное. Проблема оказалась именно в размере буфера, который я не указал. На 350Мбит все летит без единой ошибки