Ломаю голову второй день

[ratibor]

Дело в следующем:
Роутер FreeBSD4.9 ipfw (AthlonXP1900/512) две realtek 8139D

два дня назад стали волшебным образом улетучиваться от 40 до 60% пакетов на внешнем интерфейсе и пинг по кабелю в 50 метров до магистральной точки доступа вместо обычных своих менее 1мс плавает в пределах 20-50 мс.

-Ага! кабель или точка доступа!
-Нифига! Втыкаем этот кабель в ноутбук и получаем 0% потерь и пинг меньше 1 мс

-Ага! внешняя сетевуха или PCI на котором она стоит!
-Нифига! Перепробовали ещё сетевух и другой системник во всех комбинациях.

то есть или проблема локализовалась до самой Фри или я что-то из выше упомянутого сделал не правильно. на РЛ0 интерфейсе Фри никаких доп. приблуд не висит, статистика на РЛ1 и там всё шоколадно.

Вчера поздно вечером на всё плюнул и поехал домой - как назло заработало часа на 2-3 0% потерь. С утра - опять 48%.

У кого какие мысли есть?

 

[alexk]

Цитата(ratibor @ 15 Май, 2008, 9:19)
то есть или проблема локализовалась до самой Фри


Противоречит тому, что "на внешнем интерфейсе".
На роутере NAT есть? Может быть проблема аналогичная вот этой:
Cтранная проблема с пингом в UBUNTU

 

[ratibor]

alexk
NAT есть. ipfw+natd
не могу найти в sysctl -a | grep net.inet аналог Линуксовского net.ipv4.ip_conntrack_max

 

[alexk]

ratibor
Не похоже, чтобы это регулировалось sysctl, natd насколько я знаю это user-space демон. Но если виноват он, то в теории для соединений, которые не проходят через NAT (к примеру с самого роутера) потерь быть не должно, этим можно и проверить.

 

[ratibor]

Цитата
tcp:
1566 packets sent
1144 data packets (246272 bytes)
216 data packets (126092 bytes) retransmitted
0 resends initiated by MTU discovery
179 ack-only packets (35 delayed)
0 URG only packets
0 window probe packets
0 window update packets
27 control packets
3484 packets received
687 acks (for 239779 bytes)
309 duplicate acks
0 acks for unsent data
877 packets (25518 bytes) received in-sequence
59 completely duplicate packets (2328 bytes)
0 old duplicate packets
0 packets with some dup. data (0 bytes duped)
31 out-of-order packets (844 bytes)
0 packets (0 bytes) of data after window
0 window probes
3 window update packets
0 packets received after close
0 discarded for bad checksums
0 discarded for bad header offset fields
0 discarded because packet too short
5 connection requests
22 connection accepts
7 bad connection attempts
0 listen queue overflows
27 connections established (including accepts)
26 connections closed (including 5 drops)
5 connections updated cached RTT on close
5 connections updated cached RTT variance on close
4 connections updated cached ssthresh on close
0 embryonic connections dropped
523 segments updated rtt (of 650 attempts)
194 retransmit timeouts
4 connections dropped by rexmit timeout
0 persist timeouts
0 connections dropped by persist timeout
0 keepalive timeouts
0 keepalive probes sent
0 connections dropped by keepalive
0 correct ACK header predictions
721 correct data packet header predictions
24 syncache entries added
6 retransmitted
3 dupsyn
0 dropped
22 completed
0 bucket overflow
0 cache overflow
1 reset
1 stale
0 aborted
0 badack
0 unreach
0 zone failures
0 cookies sent
0 cookies received


нет ли здесь какого криминала?

 

[alexk]

Цитата

1144 data packets (246272 bytes)
216 data packets (126092 bytes) retransmitted

(если я правильно понимаю, то более половины объема отсылаемых данных пришлось передать заново).

Может быть нужно увеличить размеры буферов для TCP/UDP. Честно говоря не знаю, как это делается во FreeBSD, но это иногда бывает причиной потерь пакетов.

 

[ratibor]

alexk
увеличил буферы. но нет прямого действия, иногда по часу 0-3% потерь, сейчас 10-13%. самое фиговое когда нащупать изменения не можешь, но всё равно спасибо, хоть пользователей далеко от максимала попробую ядро пересобрать, с увеличением буферов ОЗУ и т.д.

 

[Eugene]

в ядре

options KVA_PAGES=256
options DEVICE_POLLING
options HZ=1000

/boot/loader.conf

kern.ipc.nmbclusters="16384" # Set the number of mbuf clusters
kern.maxusers="256" # Set size of various static tables
kern.ipc.maxpipekva="90308608" # 8M
kern.ipc.maxsockets="8096" # Set the maximum number of sockets avaliable

/etc/sysctl.conf

kern.polling.enable=1
kern.polling.user_frac=50
kern.ipc.somaxconn=512
net.inet.ip.fastforwarding=1
kern.maxfilesperproc=16384
kern.maxfiles=16384

возможно в 4.9 некторых переменных нет
(приведены из 5.4)

 

[ratibor]

Eugene
Цитата
options KVA_PAGES=256
options DEVICE_POLLING
options HZ=1000

жень у меня их всего то за натом 20, неужели такие активные?

 

[Пэтро]

ratibor
А Самба стоит?

Добавлено в [mergetime]1210885088[/mergetime]
Вообще этот вопрос эффективней на Наге было задать.. Там все-таки людей в этой теме побольше крутиццо..

 

[ratibor]

Пэтро
самбы нет, мэйла нет, фтп только внутрь. всё-же таблицы попереполнялись похоже, я женины рекомендации применю, гляну.
Цитата
Вообще этот вопрос эффективней на Наге было задать.. Там все-таки людей в этой теме побольше крутиццо..

дык нага не надо - гугл наг индексирует, реалтек 8139 херня, циску купи 8) есть ещё две ветки по ACPI и PCI Busmaser, но я это сразу в первый вечер проверил, давно плаваем, ага

 

[exn]

А если поменять местами rl0 с rl1 что покажет ?

Фотку кофейного осадка в студию ! ну или dmesg syslog какой а лучше кусочек tcpdump'a в файлике отдельном, и то идругое лишним не будет. Бывало даже такое что мак на встроеной сетевухе почемуто становился вида 00:00:00... тоже долго думал