У меня вся претензия именно к TCP( у Валенок предполагаю тоже).
В лабораторных условиях/на стенде/на столе все идет хорошо, но в реальном мире есть такое явление как потеря пакета, порождающая задержку и последующий автоматический ретрансмит( но сдается мне с достаточно приличными и покрутить мы их, вроде, не можем).
А так как у нас мастер в канале работает по принципу запрос/ответ, на fast retransmit можно не рассчитывать( который сглаживает проблему на больших/непрерывных потоках данных).
P.S. По моим сведениям большинство( если не все) real time протоколы не работают через TCP(наверное разработчики о чем то таком знали).
"Протокол TCP, хотя и стандартизирован для передачи RTP,[3] как правило не используется в RTP-приложениях, так как надежность передачи в TCP формирует временные задержки"( отсюда: https://ru.wikipedia.org/wiki/Real-t...sport_Protocol)
https://stackoverflow.com/questions/...stems/49471444
Последний раз редактировалось Алексеев Савр; 13.12.2021 в 08:38.
Ну хоть десяток последних постов прочитайте. Какой реальный мир, о чем Вы ?
Один от Ростова до Архангельска мериет видимо по экрану прикладывая дедушкин портновский метр (а как еще можно получить длину меньше упомянутой раза три ?)
Другой не может прочитать выше на несколько постов и начинает бла-бла как с чистого листа, и Вы туда же ?
TCP чем вас не устраивает? Подтверждением передачи? Уберите CRC в сообщении, TCP сам для пакета рассчитывает.
ЗЫ. Потери пакетов (если вы не только в лаборатории работаете) возникают при отказе промежуточных узлов, и при перемаршрутизации линка (что возникает при тех же условиях). Изредка, такое наблюдается при превышении нагрузки (но вы же выбираете устройства с коммутационной матрицей, удовлетворяющих условиям ТЗ?). Попробуйте такое провернуть с 485.
Последний раз редактировалось keysansa; 10.12.2021 в 22:32.
Если поместить промоборудование в ту же сеть где и офис, смотрят нетфликс, работает 1C и пр - то потери пакетов есть неизбежная ситуация, никак просто не исправляемая. А если промоборудование в выделенной сети и там нет много широковещательных UDP - то всё очень быстро и качественно.
Последний раз редактировалось Алексеев Савр; 13.12.2021 в 10:27.
Тролль-наседка, добрый, нежный и ласковый
Я правильно "услышал", что если изолированную(от офиса) пром сеть собрать исключительно из компонентов ОВЕН и при этом всю силу оставить "под боком"(а не в отдельном подземном бункере на удалении в километр), то потери пакетов ГАРАНТИРОВАНО исключены?
P.S. Предполагаю изобрели новый "медный" тип связи которому по боку эти всякие EMI?
P.S.2 Что то в памяти всплывает история, про то, как аж целая релюшка клала сетевой интерфейс модуля на лопатки.
промышленный Ethernet (тот же EtherCat) не работает по TCP и требует соответствующего оборудования сети. О чем вы вообще? EtherCat не будет работать на линии между двумя городами.