Проводим испытание на устойчивость технического средства (ТС) к наносекундным помехам. Требования к испытаниям: Х класс жесткости (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 стека при возникновении ошибок
|