Проводим испытание на устойчивость технического средства (ТС) к наносекундным помехам.
Требования к испытаниям: Х класс жесткости (4кВ) - 5кГц. Ввод помехи через емкостные вещи. На другом конце линии находится такое ТС.
У ТС есть как RS485, так и проводной Fast Ethernet.
В обоих случаях ни процессор, ни драйвер RS485, ни PHY Fast Ethernet не зависает.
По каналу RS485 нет ошибочных пакетов во время действии помехи, но даже если и будет то не должно превышать:
15мс (время действии помехи) / 300мс (период действия помехи) = 5% ошибочных пакетов.
Скорость 115200 бод. Отсутствие ошибочных пакетов RS485 скорее всего вызвано достаточно большой емкостью между дифф.сигналами по сравнению с Fast Ethernet.
При испытаниях порта Fast Ethernet (протокол TCP/IP) наблюдаем существенное уменьшение передаваемых пакетов (в 10 раз). При этом соединение не рвется.
Поставили на другом конце линии (на том конце, которое имеет существенную длину провода, выходящего с клещей) узел защиты от перенапряжений и затем ноут. На ноуте стоит снифер. На ТС стоит сервер ,а на ноуте клиент
Видим следующее

1) клиент обращается к серверу, сервер подтверждает запрос (делает ack через 1мс), но ответ на запрос приходит примерно через секунду.
Вот если бы уменьшить эту секунду, то увеличим объем передаваемых данных за единицу времени
Вот и вопрос: если при декодировании PHY увидит нарушение в символе, что он делает?

2) иногда происходят retransmission от клиента, что создает паузу в обмене на 300мс
Может здесь надо какой-нибудь параметр в стеке подправить?

3) иногда возникает rst без обрыва соединения, что создает паузу в обмене на 1с

Используемый стек: какая-то сборка m_i_c_r_i_u_m TCP/IP v1.92 собранная собственоручно.

Какую порекомендуете литературу:
1) разобраться с физическим уровнем обмена - т.е. какие здесь возможны ошибки и как софт д. реагировать на это;
2) взаимоотношения между PHY и MAC при возникновении ошибок;
3) реакцию TCP/IP стека при возникновении ошибок

Если при декодировании PHY увидит неожидаемый символ то скорее всего весь кадр Ethernet отбрасывается

Пусть кадр отбрасывается, но как MAC про это ведь д.узнать - так вот он как узнает по таймауту или опрашивая регистры PHY?

В интерфейсе MII есть сигнал RX_ERROR. По нему приемный пакет МАС должен выбросить. Есть CRC по приему, такие пакеты тоже выбрасываются...
В регистрах PHY об этом есть информация.

по литературе и не совсем(не последние года. возможно ситуация поменялась. копал лет 5 назад тему)
1, 2) с физического уровня (как сказано выше) приходят состояния принятых данных. по идеи при отсутствии заданной фильтрации для нижнего аппаратного уровня по MAC уровню - пакеты должны приходить все, которые есть в данной линии. как выставить фильтр, статус принятых данных - всю инфу смотреть даташит от производителя железа Ethernet контроллера.
3) сам по себе стэк(протокол TCP/IP имеется ввиду) можно разделить на два слоя: IP уровень и TCP. IP должен уметь обрабатывать сборку пакетов(в имеющихся в инете открытых протоколов этого функционала не наблюдал) при их фрагментации. по умолчанию максимальная длина 1500 (обычно нарезает любой роутер по пути маршрутиризации, либо передающий хост - если форточки например). более высокий уровень TCP обеспечивает обработку таких вещей как размер окна, затор, потери пакетов(медленные-быстрые старты и т.п.). основное чтиво - RFC по протоколам. там всё есть. по таймингам - сильно зависит от операционки где это всё живёт. в форточках, например, некоторыми задержками и параметрами можно управлять из пользователькосго слоя. сам по себе TCP/IP протокол предназначен именно для устойчивой канальной связи в не зависимости куда исчезают пакеты.


удачи вам
(круглый)