Realtek NIC спамит прерываниями

Что находится «внутри»? Есть какие-то умные принтеры или что-то такое? Как насчёт tcpdump?

Внутри локалка из сотни компов. Умные принтеры? Пожалуй нет, да и в инет они не лезут. Да, как раз догадался сделать дамп. Вот такая нездоровая хрень:

11	0.000179	192.168.10.63	192.168.10.5	TCP	60	[TCP ZeroWindow] [TCP ACKed unseen segment] 3160 → 3128 [ACK] Seq=1 Ack=1 Win=0 Len=0
12	0.000182	192.168.10.5	192.168.10.63	TCP	54	[TCP Dup ACK 8#1] 3128 → 3160 [ACK] Seq=0 Ack=0 Win=65535 Len=0
13	0.000218	192.168.10.63	192.168.10.5	TCP	60	[TCP ZeroWindow] [TCP ACKed unseen segment] 3157 → 3128 [ACK] Seq=1 Ack=1 Win=0 Len=0
14	0.000221	192.168.10.5	192.168.10.63	TCP	54	[TCP Dup ACK 2#3] 3128 → 3157 [ACK] Seq=0 Ack=0 Win=65535 Len=0

За 20 секунд tcpdump набежал лог в 200мб такой вот повторяющейся херни. Это клиент и squid(192.168.10.5). Если честно первый раз с таким сталкиваюсь. Даже загуглить не успел пока.

1. да. поменяй карту. если нет карты то может помочь поллинг но только если правильно настроить иначе будут потери пакетов с ретрансмитом и обратный эффект вместо пользы. посмотри ещё мануал по драйверу на этот realtek в системе на предмет тюнига через sysctl
2. мистика это непонимание
Судя по второму логу у тебя таки теряются пакеты но причину наверное находить тебе т.к. неясно что там с конфигурацией твоей сети

Кажется, твой сквид задыхается, проверяй его настройки, а вообще, топология сети неясна-так что это всё пальцем в небо.

реалтек такое гавно

Да.

если да, то почему

Всех глюков даже и не перечислить, настолько они разнообразные. Плюс «разнообразия» у этих реалтеков просто море, включая с одной ревизией.
Если вам для академического интереса, предлагаю погуглить, ну или просто здесь поискать, тем достаточно.

и насколько лучше станет с intel?

Не конкретно про ваш случай, но если есть возможность однозначно меняйте. Тем более у вас роутер.

Я так понимаю вы имели дело с ними. А можно подробнее, мне очень интересна тема, поиск выдаёт какие-то неоднозначные и СТАРЫЕ результаты.

У меня опыт не на freebsd, а на linux. Но не думаю что ситуация в корне различается.

поиск выдаёт какие-то неоднозначные и СТАРЫЕ результаты

Эти «старые» результаты по факту уже не меньше десятилетия актуальны.

Из простого, подбор драйвера к конкретной rev. Но есть нюанс что разные версии к одной и тойже rev могут работать или не работать, вот это самая большая попа.
Что значит могут работать или нет:
Хорошо когда просто не работает (карта определилась дрова загрузились, но не работаем, сообщений в логах ноль).
Хуже когда это всплывает в процессе работы под нагрузкой.
Еще хуже когда рандомно. Пример: объект удаленный, но ответственный в части связи, диспетчерская просто сообщает что связи нет местные работяги ребутают. Никто не даст время что бы дождаться тебя для разбора что же было.
Так же нехилая просадка под нагрузкой.
Это тезисно что вспоминается за многолетний опыт «попадания» на эти карты, может что-то еще и забыл.
Но во всех случаях замена на «человеческий» серверный intel снимает все выше указанные проблемы.

В общем я пока плавно перетек из одной проблемы в другую. Из всего этого я пока только понял что что-то мешает сквиду и клиентам нормально общаться. Этим «что-то» похоже является stateful ipfw. Вот то что может касаться сквида:

${fwcmd} add check-state
${fwcmd} add deny tcp from any to any established
${fwcmd} add allow tcp from ${lan} to me 3128 in via ${iif} keep-state
${fwcmd} add allow tcp from me to any 80,8080,8088,443 out via ${oif} keep-state

Добавил во второе правило логгирование и тут же словил кучу отлупов вида:

Jul 28 18:53:04 mail kernel: ipfw: 300 Deny TCP 192.168.10.166:53393 192.168.10.5:3128 in via re1

и

Jul 28 19:13:08 mail kernel: ipfw: 300 Deny TCP 192.168.10.5:3128 192.168.10.166:53402 out via re1

То есть получается что либо ipfw неправильно обрабатывает правила, либо клиент/сервер шлют unrelated ACK'и которые отбрасываются на втором правиле. Увы еще раз воспроизвести проблему до понедельника не получится и посмотреть как будет если убрать блокировку established пакетов. Попытался воспроизвести по rdp с win7 машины - в логах чисто. Однако winxp машина неплохо так генерила отлупы в логах пару часов назад.

P.S. Что интересно, несмотря на такие непонятки с ipfw и прочими сложностями клиенты ни разу не жаловались на то что сайты не открываются или тормозят. Со стороны сквида и его логов тоже все тихо и спокойно.

Что то не найду где редактировать сообщения. Извините. Хотел добавить что я может быть поторопился выводом про ipfw так так те отлупы скорее всего были из за того что я рестартил ipfw и старые tcp сессии оказались unrelated. Но с другой стороны отлупы сыпались ну очень долго, 10 минут точно а потом еще один всплыл через полчаса. Жду понедельника в общем) Всех с праздником!

Что то не найду где редактировать сообщения.

И не найдете, надо нафлудить до первой звезды, тогда станет возможно :)

В общем свою проблему решил. Пусть и косвенно. Вполне возможно я бы вообще не обратил на нее внимание, если б были нормальные сетевухи:) IPFW избирательно резал обратный трафик от сквида к клиенту, если не прописать явный allow на него. То есть правила с keep-state от клиента не канают. Либо IPFW плохо умеет в states, либо у сквида какое то свое понятие о том как общаться с клиентами пересылая unrelated пакеты.

Интересно вообще понять механизм возникновения такого спама zerowindow пакетами от клиента, но пока нет времени до конца разобраться. В идеале нужно снимать дампы на сервере и клиенте, сопоставлять логи ipfw.