Рекламный блок.

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

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

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

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

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

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

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

то есть или проблема локализовалась до самой Фри

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

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

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

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

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

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

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

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

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

в ядре

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)

Eugene

options KVA_PAGES=256
options DEVICE_POLLING
options HZ=1000

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

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

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

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

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

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

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

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

Отредактировал exn - 16 Май, 2008, 4:35