agent2011

совершенно верно. не нужно дезинформировать и пугать людей.

поддерживаю, так же ощущаем это

Это мы знали, может они такие и были уже прошитые, но на момент покупки модулей, у нас еще такой карты не было :-)

у нас на одном из серверов стоит x520, изначально с гигабитными модулями стояла, перешли на SFP+ модули, сервер с установленным линуксом не захотел их принимать, так как модули не оригинальные, естественно запустили с командой ixgbe.allow_unsupported_sfp=1 и он стал их принимать, но на одном из порту мы раз в 20-30 минут хаотично фиксировали линк ап и линк давн. Всякие ковыряние не смогли преодолеть эту беду. DAC прошитый под Интел решил эту проблему. Вопрос только, почему гигабитные без проблем принял, они так же были не оригинальные, от SNR.

iptables -A FORWARD -i ppp+ -s ваш ип -j ACCEPT - разрешаем доступ абоненту к Интернету iptables -A INPUT -i ppp+ -s ваш ип -j ACCEPT - для белого ИП если используете ipset создаем списки: iptables -A FORWARD -i ppp+ -m set --match-set ppp src -j ACCEPT iptables -A FORWARD -m set --match-set white dst -j ACCEPT добавляем в списки правила: ipset -A ppp ваш ип - разрешаем доступ ipset -A white ваш ип - белый ип возможно пригодится включить proxyarp на интерфейс вышестоящего: sudo echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp

в нормальную погоду и 900 прокчивает на 1400. в плохую раза в два снижается производительность. но падения линков конкретно из за атмосферы самой еще не видели, только единственный случай когда замело саму антенну снегом. и то почистили по простону рукой и все завелось. поэтому и решили защитить козырьками. да, как написал коллега - скоро эта фраза будет мемом :-) что там изобретать то? :-) много мозгов не нужно :-) козырек 70 в глубину, 50 в высоту и 100 в длинну :-) 5 брусков 40х40х200, саморезы по дереву и лист ондулина) сегодня смонтировали каркас, на днях набьем ондулин, фото приложу)

Недавно был сильный снег, была плохая видимость, линк пропал, работала на частоте 58000, очистили от снега, замело всю. линк не поднялся из за плохой видимости, решили поэксперементировать с частотами, поставили 64000 - линк поднялся, прокачивало 400-500 мегабит, энергетика в районе 50%. Снег прошел, энергетика поднялась до 80-90. Расстояние 1400 м стоят дополнительно купленный крепления для точной юстировки. Будем делать козырьки на днях :-) брус + ондулин :-)

в общем проблему со спидтест нодой утресли, оказалось, что лучше вообще не делать autorps. у кого какие идеи будут по поводу того, что скорость в два раза меньше у PPPoE клиентов? Имею ввиду максимальную скорость. Те кто заказал сотню по медному порту - сотню и получат. А вот те кто например 500 метров хочет по PPPoE - не смогут. Делаем замеры на одной проверочной машине, разница в два раза PPPoE и статика. Может быть это можно считать нормальным?

да, вы правы. делается это командами: sudo autorps eth0 --cpus 0 1 2 3 4 5 --force sudo autorps eth1 --cpus 0 1 2 3 4 5 --force и все же. выполняя команду: sudo autorps eth0 -с 6 --force мы нагружаем какое-то одно ядро процессора, в этом случае к наша спидтест нода показывает нужный результат. но из за этого естественно страдает вся сеть. но все же если раскидать rps по правильному: sudo autorps eth0 --cpus 0 1 2 3 4 5 --force sudo autorps eth1 --cpus 0 1 2 3 4 5 --force то снова скорость к спидтест ноде падает. Зато сеть начинает работать так как нужно. Будем пробовать перезагружать сервер, и не выполнять вообще autorps. посмотрим как будет работать просто раскидав прерывания. возможно выход еще один будет, перенос спидтест ноды на другой сервер)

Проблему по спидтесту с беспроводными решили :-) проблему с общей производительностью PPPoE - нет. Все оказалось куда банальнее, дело было в: сделали с флагом sudo autorps eth0 -с 6 --force sudo autorps eth1 -с 6 --force все стало на свои места в плане беспроводного спидтеста, стало выжимать по максимому. Но, что касаемо общей производительность PPPoE, даже по кабелю, видим двойное различие. Не хочу всех запутывать, но различие по скорости есть и на проводе все же: На том же 2ip или спидтесте - мы не можем поднятья выше 500 мегабит по входящему, по исходящему 900 можно увидеть. Интересно, что на торрентах выше 30 мегабайт я не видел никогда, и то с натяжкой, в основном скорость колеблется в районе 20-25. Еще один момент, запуская speedtest-cli на сервере доступа, я вижу тоже разрыв в два раза (проверка до нашей ноды, которая на этом же сервере): Testing download speed................................................................................ Download: 2959.72 Mbit/s Testing upload speed................................................................................................ Upload: 1485.37 Mbit/s Сегодня еще попробуем напрямую к аплинку подсоединится, без сервера доступа и посмотреть, что будет. Может по входящему аплинк что-то подрезает. Вопрос по autorps. в man про ключ -c - пишут про CPUs, за что отвечает этот ключ? за ядра или процессоры? :-) у нас двухпроцессорный сервер доступа, два процессора по 6 ядер. и каким образом для нашей конфигурации нужно прописывать данную команду? просто: sudo autorps eth0 -с 6 --force sudo autorps eth1 -с 6 --force или например: sudo autorps eth0 -с 0 --force sudo autorps eth1 -с 0 --force sudo autorps eth0 -с 1 --force sudo autorps eth1 -с 1 --force sudo autorps eth0 -с 2 --force sudo autorps eth1 -с 2 --force sudo autorps eth0 -с 3 --force sudo autorps eth1 -с 3 --force sudo autorps eth0 -с 4 --force sudo autorps eth1 -с 4 --force sudo autorps eth0 -с 5 --force sudo autorps eth1 -с 5 --force

Да, действительно, проблема касается только тех, кто подключен по PPPoE. У нас работает accel-ppp. и все же, как раз проверяя спидтестом даже на кабеля чувствуется снижение производительности по PPPoE, как раз таки в два раза. По статике все в порядке. как-то несколько месяцев назад я писал в теме accel-ppp о данной проблеме, но ответа так и не последовало. Теперь ясно, что проблема как-то связанна с туннелями или accel-ppp. Пните меня дальше пожалуйста :-) UPD: Прикрепляю скрин трацерта (PPPoE). Первый ip самого accel-ppp. Второй - ip шлюза вышестоящего на аплинк интерфейсе. Второй скрин уже без PPPoE, тоже самое, меняется только адрес шлюза нашего. Разница лишь в том, что eth1 интерфейс у нас имеет адрес 10.20.0.1 а accel-ppp создает для себя отдельный 10.30.254.254 Что касаемо маршрутизации, при тестировании спидтестом (до своей ноды) и в том и другом случае трафик не идет через аплинк интерфейс. Во всяком случае смотря в реальном режиме vnstat ом этого не видно. То есть трафик остается внутри своей сети.

об этом я думал, но дело в том, что шейпер на конкретном абоненте мы отключили вообще. и все равно такое поведение. используем полисер ipt-ratelimit не посоветуете что нибудь? такое впечатление, что входящий как буд-то по второму кругу где-то проходит :-)

Всем привет. Имеем сервер доступа на Дебиане. Интересная ситуация получилась. Запустили свою спидтест ноду на этом же сервере доступа, по проводам работает замечательно, выжимает гигабит. Все по стандарту, ничего не меняли в конфигах. У беспроводных клиентов, входящий зарезается в два раза почему-то при проверке к своему серверу. При проверке на другие сервера - показывает нужный результат. В чем может быть проблема?! Мосты на на микротике LHG 5 XL. Про настройку микротика можно не писать, работают в полосе 40 мгц, прокачивают в неполном дуплексе по 180 мегабит. из за ограничений портов в 100 мегабит - максимум естественно и видим эти 100 мегабит, они прилетают без проблем. Мне хотелось бы подчеркнуть, что скорость режется только до своего сервера. До других проблем нет.

Ответили строго по требованиям, как видите они не сложные. Сочинять так было нечего.

Говорят что всем отправляли. У нас же все грамотно было расписано в письме. Трудностей по смыслу требований не возникло. Прислали вечером 20 числа, не позднее 22 попросили дать ответ.