iglide

Вопрос не понял. 5 гбит пережевывает текущее железо. На какое-то время его еще хватит. Но пределы не за горами. Вопрос в этот форум преследует одну задачу - свести к минимуму количество подобных "экспериментов". Чтоб бить уже наверняка. Технологии процессоростроения меняются каждый месяц. ядра, модули, частоты, кэши всевозможных уровней, всякие гипертрейдинги и прочая... все это появляется и исчезает. Простая формула - "брать что подороже" здесь не работает! Брать нужно со знанием дела. И вот за этим знанием на форум люди и идут. Они, форумы, для того и созданы, чтобы люди допускали меньше ошибок и меньше наступали на грабли. Самый актуальный вопрос - чему отдать предпочтение - частоте или ядрам? Есть ощущение, что упор надо делать на частоту. Я повторюсь, два 4-х-ядерных ксеона сдались перед бюджетным феномом. Ксеоны были по 2.3ГГц. Феном 3.4ГГц. Почему-то оказалось, что 2х2.3<3.4. Вот такая арифметика. Вот, к примеру, новейший интел: http://hard.rozetka.com.ua/intel_xeon_e5_2660_2.2ghz_2mb_8gts_bx80621e52660_S2011_box/p231656/ Стоит почти 1500 у.е. Но что-то мне подсказывает - даже с ним если и будет прирост в производительности, то не на много. И почему-то, к вот этому решению http://hard.rozetka.com.ua/amd_fx_8150_fd8150frgubox/p185637/ доверия больше. Хоть и стоит оно почти на порядок меньше.

Не дешевые эксперименты получатся. Попробовать и5, не получится - переехать на и7? А если и и7 себя не в лучшем свете покажет? Опять же, и5ятые разные бывают. У кого-то ядер больше, у кого-то частоты. куда смотреть? Хотелось бы реальных данных. У кого какая нагрузка на каком железе? Был печальный опыт. Поставили 2-х процессорный Ксеон. в каждом по 4-ре ядра. Так бюджетный феном его просто на лопатки уложил. Вот вам и интел.

Замер 128нс. Как вообще это понять? Что означает прямая начиная от 200м? И как увидеть то единственное соединение (сварку), которая есть на этом участке? rfg_1310нм_2.0км_00035_PC_128ns.sor.txt

Добрый день, уважаемые господа. Приобрели рефлектометр (Гамма лайт от Связьприбор). До этого опыта работы с подобными устройствами не имели. Решили потренироваться "на кошечках". Имеем рабочий участок. Кабель 800м. В нем несколько "серых" волокон. На участке есть одна сварка. Пытаемся сделать замер. Ожидаемый результат - длина участка порядка 800м и одно событие на линии. Однако, получаем вот такую картину (см. аттач) Как интерпретировать полученные результаты? Что делаем не так? PS. Замеры производились на двух разных волокнах и обоих частотах (1310, 1550). Результат везде одинаков. PS2. SOR-файл в аттаче (убрать расширение .txt) Спасибо. green-blue_1550.sor.txt

Украина. Не могу не отметить великолепную работу ребят из isp-servis.ru Получили блок /21 IPv4 + AS примерно за неделю. Заполнили заявку, собрали сканы необходимых документов (минимум), подписали договор и через неделю получили все что нужно. Все быстро и оперативно. По началу немного смущала мысль об оплате (я так понимаю, фирма зарегестрированна в Чехии, поэтому, пугали возможные проблемы с переводом). Но ребята предложили оплатить на карту Приватбанка, что меня вполне устроило. Очень удобно. Что еще стоит отметить - ребята работают по очень редкому в наше время принципу "вечером стулья, - утром деньги". Т.е., мы уже получили блок адресов, получили АС и только потом стал вопрос об оплате. Это просто невероятно! Также, подтверждаю, что при упоминании сайта nag.ru стоимость услуг сразу же снизилась на 15%. За что спасибо отдельное Очень приятно работать с такими организациями. Спасибо!

8-ми ядерный ксеон медленее бюджетного Core2Duo? Зачем тогда вообще нужны все эти ксеоны???Выходит что, в данном контексте никакие современные технологии никому не нужны? Бери что угодно только с максимальной частотой и будет счастье?

Поменяли длинк на Edge-core ES4626. Ситуация не изменилась. Сомнений практически больше нет - проблема на сервере доступа. Но где копать? Процессор не загружен! last pid: 19864; load averages: 1.36, 1.28, 1.22 up 14+15:19:29 13:39:09 362 processes: 4 running, 346 sleeping, 12 waiting CPU states: 5.6% user, 0.0% nice, 9.9% system, 22.5% interrupt, 61.9% idle Mem: 515M Active, 113M Inact, 253M Wired, 44M Cache, 111M Buf, 55M Free Swap: 1983M Total, 433M Used, 1551M Free, 21% Inuse PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 1 171 ki31 0K 16K RUN 1 283.6H 78.42% idle: cpu1 12 root 1 171 ki31 0K 16K RUN 0 177.6H 46.19% idle: cpu0 15 root 1 -44 - 0K 16K WAIT 0 153.9H 41.89% swi1: net 28 root 1 -68 - 0K 16K - 0 39.6H 11.96% dummynet 19590 root 3 8 0 171M 44340K wait 1 364:59 1.76% mpd4 13 root 1 -32 - 0K 16K WAIT 0 212:28 0.20% swi4: clock пинг с сервера на эджкор (интерфейс em0) ужасный: # ping 10.100.110.2 PING 10.100.110.2 (10.100.110.2): 56 data bytes 64 bytes from 10.100.110.2: icmp_seq=0 ttl=64 time=12.419 ms 64 bytes from 10.100.110.2: icmp_seq=1 ttl=64 time=8.583 ms 64 bytes from 10.100.110.2: icmp_seq=3 ttl=64 time=9.039 ms 64 bytes from 10.100.110.2: icmp_seq=4 ttl=64 time=10.990 ms 64 bytes from 10.100.110.2: icmp_seq=5 ttl=64 time=7.383 ms 64 bytes from 10.100.110.2: icmp_seq=6 ttl=64 time=12.115 ms 64 bytes from 10.100.110.2: icmp_seq=7 ttl=64 time=15.866 ms ^C --- 10.100.110.2 ping statistics --- 8 packets transmitted, 7 packets received, 12.5% packet loss round-trip min/avg/max/stddev = 7.383/10.914/15.866/2.663 ms Т.е., даже наблюдаются потери. Пинг же в другую сторону (em1) вполне себе в норме: # ping 10.100.100.1 PING 10.100.100.1 (10.100.100.1): 56 data bytes 64 bytes from 10.100.100.1: icmp_seq=0 ttl=64 time=1.061 ms 64 bytes from 10.100.100.1: icmp_seq=1 ttl=64 time=1.940 ms 64 bytes from 10.100.100.1: icmp_seq=2 ttl=64 time=0.815 ms 64 bytes from 10.100.100.1: icmp_seq=3 ttl=64 time=0.219 ms 64 bytes from 10.100.100.1: icmp_seq=4 ttl=64 time=1.340 ms 64 bytes from 10.100.100.1: icmp_seq=5 ttl=64 time=0.209 ms 64 bytes from 10.100.100.1: icmp_seq=6 ttl=64 time=0.315 ms ^C --- 10.100.100.1 ping statistics --- 7 packets transmitted, 7 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.209/0.843/1.940/0.606 ms Каковы будут рекомендации? Где же, все-таки, копать? Тонкий тюнинг драйвера em0?

Каков же выход? Таки, пропускать ВЕСЬ внутренний трафик через одну (пусть даже серверную) сетевую карту? Но ведь это же абсолютно не оптимально! Или ставить что-то, вроде АТ-9924, который, по словам разработчиков умеет терминировать PPPoE на портах (правда, не более 1024 сессий)?

Тогда как Вы разруливаете локальный трафик, когда поднимается PPPoE-сессия? опять-таки, через сервер? Или батниками, как предлагает народ?

Господа, дайте, плз, ответ, Эта схема работать будет? Никаких подводных камней не появится? А с учетом использования рекомендованного здесь Edge-Core ES4626?

Согласен. Но это уже второй вопрос. Пока у меня стоит задача - либо обеспечить нормальную работу 2-м тысячам нормальных пользователей, либо закрутить гайки против "таких" умников. И, честно говоря, я пока отдаю предпочтение первому. На счет борьбы с умниками - реально ли динамически прописывать мак-и на портах? Т.е., если пользователь валидный - его мак пропускается свитчем. Если же нет, то, "ой"... Вообще, мне кажется, задача достаточно тривиальная. Неужели никто не сталкивался с подобным? Как мне кажется - классическая домашняя сеть. И проблема классическая...

А нельзя при установке PPPoE дефолтовым маршрутом назначить L3 свитч? А он уже будет локалку заруливать в свои порты, а все остальное далее по маршруту (PPPoE-сервер, и т.д...)? В смысле, кому "зя", кому "нельзя"?

Тогда, уточню. Берем любой L3. Отказываемся от виланов. Настраиваем на каждом порту L3 DHCP (своя подсеть на каждый порт). На том же L3 делаем маршрутизацию между портами (соответственно, подсетями). Так? А маршрутом по умолчанию (для всего остального (внешнего) трафика) будет PPPoE-сервер.? В итоге, межсегментный трафик не будет идти далее L3, а весь интернетный трафик будет идти на PPPoE-сервер и далее в интернет. Эта схема работать будет? Никаких подводных камней не появится?

Поставить другой процессор - не проблема. Вопрос в том - мы на 100% убедились что проблема именно в PPPoE-сервере? Мало того, как я сейчас понимаю, дело-то вовсе не в процессоре, если советуют тонкий тюнинг драйверов сетевой карты и обновление ОС. И еще вопрос №2. Неужели у всех провайдеров, использующих vpn (а таки, как мне кажется, большинство) локалка гоняется через PPPoE-сервер??? Неужели нет более элегантного решения не нагружать ответственный сервер огромным (но бесплатным) трафиком?

Вот тут и вот тут пишут что проблемные они. Правда, постинги годичные. - Полагаете, поправил производитель ситуацию? (хотя последняя прошивка на оф.сайте датируется концом прошлого месяца. Стало быть, до сих пор идет обкатка на покупателях...)

Время пинга колеблется от 1 до 4 мс. На фре поднят шейпер исходящего трафика. Для безлимитчиков. # uname -a FreeBSD 7.0-RELEASE #1: Wed Jul 30 22:43:24 UTC 2008 /usr/obj/usr/src/sys/MYKERNEL amd64 2Latik: # netstat -dw1I em0 input (Total) output packets errs bytes packets errs bytes colls drops 72562 204 45279843 77075 0 71420604 0 0 77316 148 49255337 81186 0 74372712 0 0 77305 0 50918070 80838 0 74270246 0 0 75701 225 48339907 79552 0 73049187 0 0 71419 180 44630358 75628 0 69877104 0 0 74110 189 47012379 78187 0 72472249 0 0 77243 173 48957080 81733 0 75245352 0 0 68562 0 42224922 71775 0 64491301 0 0 75260 84 48270375 79271 0 72797672 0 0 systat -vm 1: 1 users Load 1.30 1.28 1.30 7 фев 21:57 Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER Tot Share Tot Share Free in out in out Act 558544 9356 850164 18712 120220 count All 584696 10484 5102856 23400 pages Proc: Interrupts r p d s w Csw Trp Sys Int Sof Flt cow 4060 total 1 315 5858 24 1166 68 5740 22 22 zfod atkbd0 1 ozfod em1 irq18 8.5%Sys 25.9%Intr 0.4%User 0.0%Nice 65.2%Idle %ozfod 68 atapci1 22 | | | | | | | | | | | daefr 1996 cpu0: time ====+++++++++++++ prcfr em0 irq256 8 dtbuf 8 totfr 1996 cpu1: time Namei Name-cache Dir-cache 69146 desvn react Calls hits % hits % 38924 numvn pdwak 6 6 100 17279 frevn pdpgs intrn Disks ad4 282768 wire KB/t 16.00 507992 act tps 68 91924 inact MB/s 1.06 32520 cache %busy 4 87700 free 113792 buf 22:00. 680 PPPoE-сессий. Собственно, именно это я и хотел узнать изначально - какой L3-коммутатор посоветует народ? Длинк не хочется. Хочется именно на перспективу. В большей степени интересует ATI AT -9448T/SP. Главный вопрос - справится ли он с задачей? Не возникнет ли каких либо подводных камней в настройке маршрутизации виланов? В данный момент каждый вилан не видим для другого, т.е., абонент включенный, скажем в vlan2 (10.100.10.123), не видит абонента из vlan3 (10.100.12.123). Друг друга они начинают видеть только после поднятия PPPoE! Т.е, при этом, каждому из них назначается определенный IP (скажем, 10.10.20.11 и 10.10.40.12) и уже сама фря разрешает трафик в этих подсетях. Не совсем понятно каким образом эта маршрутизация будет подниматься на Л3! Какие есть на Л3-коммутаторах механизмы для решения этой задачи? Может есть литература какая полезная (желательно, доходчивая)? Я повторюсь, опыта работы с L3-оборудованием - нет. А экспериментировать на 3-х тысячах у.е. большого желания тоже нет (тем более, во времена кризиса).

Как дополнительную информацию, привожу график загрузки общего порта на коммутаторе:

Многоуважаемый Jab - молвите слово? Где же копать? ...Хм... только что еще раз замерил пинг на соседний хост во внутренней сетке: # ping 10.100.100.77 PING 10.100.100.77 (10.100.100.77): 56 data bytes 64 bytes from 10.100.100.77: icmp_seq=0 ttl=64 time=10.782 ms 64 bytes from 10.100.100.77: icmp_seq=1 ttl=64 time=13.895 ms 64 bytes from 10.100.100.77: icmp_seq=2 ttl=64 time=3.876 ms 64 bytes from 10.100.100.77: icmp_seq=3 ttl=64 time=12.523 ms 64 bytes from 10.100.100.77: icmp_seq=4 ttl=64 time=10.565 ms 64 bytes from 10.100.100.77: icmp_seq=5 ttl=64 time=12.756 ms 64 bytes from 10.100.100.77: icmp_seq=6 ttl=64 time=11.757 ms 64 bytes from 10.100.100.77: icmp_seq=7 ttl=64 time=10.934 ms 64 bytes from 10.100.100.77: icmp_seq=8 ttl=64 time=9.801 ms 64 bytes from 10.100.100.77: icmp_seq=9 ttl=64 time=10.025 ms 64 bytes from 10.100.100.77: icmp_seq=10 ttl=64 time=16.667 ms При этом пинг на все тот же длинк: # ping 10.100.110.10 PING 10.100.110.10 (10.100.110.10): 56 data bytes 64 bytes from 10.100.110.10: icmp_seq=0 ttl=64 time=15.013 ms 64 bytes from 10.100.110.10: icmp_seq=1 ttl=64 time=18.048 ms 64 bytes from 10.100.110.10: icmp_seq=2 ttl=64 time=17.856 ms 64 bytes from 10.100.110.10: icmp_seq=3 ttl=64 time=14.052 ms 64 bytes from 10.100.110.10: icmp_seq=4 ttl=64 time=15.815 ms 64 bytes from 10.100.110.10: icmp_seq=5 ttl=64 time=11.356 ms 64 bytes from 10.100.110.10: icmp_seq=6 ttl=64 time=15.327 ms Все-таки, что-то здесь не то. Как убедиться на 100% в том, что поллинг включен? В чем кроме него может быть еще проблема?

# grep polling /etc/sysctl.conf kern.polling.enable=1 kern.polling.user_frac=0 options DEVICE_POLLING options HZ=1000 Сейчас 18:38. Онлайн 617. Задержки на длинке: DGS-3100# ping 10.100.110.1 Pinging (10.100.110.1) with 56 bytes of data: 56 bytes from 10.100.110.1: icmp_seq=1. time=20 ms 56 bytes from 10.100.110.1: icmp_seq=2. time=20 ms 56 bytes from 10.100.110.1: icmp_seq=3. time=0 ms 56 bytes from 10.100.110.1: icmp_seq=4. time=0 ms ----10.100.110.1 PING Statistics---- 4 packets transmitted, 4 packets received, 0% packet loss round-trip (ms) min/avg/max = 0/10/20 Загрузка фри: #top -SI last pid: 56889; load averages: 1.17, 1.37, 1.37 up 6+20:19:52 18:39:32 365 processes: 6 running, 348 sleeping, 11 waiting CPU states: 0.9% user, 0.0% nice, 8.6% system, 22.5% interrupt, 67.9% idle Mem: 440M Active, 95M Inact, 290M Wired, 7256K Cache, 111M Buf, 146M Free Swap: 1983M Total, 61M Used, 1923M Free, 3% Inuse PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 1 171 ki31 0K 16K RUN 1 132.7H 79.49% idle: cpu1 15 root 1 -44 - 0K 16K WAIT 0 70.6H 48.29% swi1: net 12 root 1 171 ki31 0K 16K RUN 0 84.9H 42.97% idle: cpu0 28 root 1 -68 - 0K 16K CPU0 1 17.7H 12.74% dummynet 56884 www 1 96 0 68572K 6468K select 0 0:00 3.00% httpd 19590 root 2 96 0 143M 29708K select 1 110:29 1.61% mpd4 23571 www 1 4 0 71772K 10128K sbwait 1 4:34 0.34% httpd PPS: # bwm-ng -I em0 -u packets bwm-ng v0.6 (probing every 0.500s), press 'h' for help input: getifaddrs type: rate | iface Rx Tx Total =========================================================================== === em0: 25130.08 P/s 30814.63 P/s 55944.72 P/s ------------------------------------------------------------------------------ total: 25294.60 P/s 31016.37 P/s 56310.96 P/s Пайпы: # ipfw list | grep pipe | wc -l 998 Что еще? Железо - процик Intel Core2Duo 6750 1333MHz мать Asus 5PK Сетевая, как уже писал PCI-E Intel® PRO/1000 PT Server Adapter 2 GB памяти... пинг на длинк (em0): # ping 10.100.110.10 PING 10.100.110.10 (10.100.110.10): 56 data bytes 64 bytes from 10.100.110.10: icmp_seq=0 ttl=64 time=8.858 ms 64 bytes from 10.100.110.10: icmp_seq=1 ttl=64 time=15.684 ms 64 bytes from 10.100.110.10: icmp_seq=2 ttl=64 time=21.606 ms 64 bytes from 10.100.110.10: icmp_seq=3 ttl=64 time=14.211 ms Пинг на соседнюю машинку из внутренней локалки (em1) # ping 10.100.100.5 PING 10.100.100.5 (10.100.100.5): 56 data bytes 64 bytes from 10.100.100.5: icmp_seq=0 ttl=64 time=1.755 ms 64 bytes from 10.100.100.5: icmp_seq=1 ttl=64 time=0.585 ms 64 bytes from 10.100.100.5: icmp_seq=2 ttl=64 time=1.647 ms 64 bytes from 10.100.100.5: icmp_seq=3 ttl=64 time=0.588 ms Т.е., вполне адекватный пинг. Как может не тянуть фря??

Да это, как бы, очевидно - не парень с улицы - разбираетесь в сути, однако... ну, может, ближе к народу нужно быть, что ли... Сорри за оффтоп. Понимаете ли, поскольку системным администратором я не являюсь, сужу, возможно, не так как принято в узких кругах. Но все же, логическое мышление свойственно не только мастодонтам от системного администрирования. И именно оно мне подсказывает, что если бы не справлялся сам сервер, то задержки должны были быть и на втором интерфейсе! Но их нет! Безусловно, могут быть какие-то тонкости и нюансы в настройках интерфейсов и работе такой сложной ОС как FreeBSD, невидимые простым смертным. Но эти тонкости и нюансы знает только человек, посвятивший предмету большую часть сознательной жизни, за что и ценится он как специалист... Я же позволю себе быть ценным в другой области. Однако разговор о ценностях не решит саму проблему. Если вы, как спецы, склонны грешить именно на серверную часть, значит, будем пытаться выдавать данные по серверу. Вот только, проштудирую еще за ночь OpenNet.ru, да, даст Бог, разберусь как замерить эти PPS...

jabБезусловно, уважаемый, jab, Вы пользователь с авторитетом. Однако, не в обиду, судя по Вашим постингам, Вы юноша весьма самовлюбленный. И наверное на то есть причины. Но, не об этом. Знаете, многие из-за собственной важности, собственного носа не замечают. Ну, наверное, такова плата за "славу". Посмотрите, пожалуйста, внимательнее, несколькими постингами назад, была дана конфигурация интерфейсов: Хотя, в одном Вы, безусловно правы! Не специалист я. Но, выбора у меня, к сожалению, на сегодняшний день нет, знаете-ли. А вот проблема присутствует. И есть огромная необходимость эту проблему решить. Есть хорошая фраза - можешь помочь - помоги. Не можешь - лучше промолчи. Кажется так. А лишний раз показывать здесь свою индивидуальность и уникальность - зачем? Аборигены форума итак в курсе ху из ху. А обычным прохожим это и даром не надо. Не правда ли?

Да, кстати по поводу PCI. К сожалению (или к радости), карта стоит PCI-E. Повторюсь, Intel® PRO/1000 PT Server Adapter...

Простите, на основании чего подобный вывод? И что, если не секрет, конкретно мы не удосужились настроить?FreeBSD занимается исключительно терминированием PPPoE. На ней поднят MPD и RADIUS. Все. Даже база с юзверями крутится на отдельной машине. Спасибо, так и поступим. Осталось выяснить - какую?Признаюсь честно, Длинк больше не хочется. Какой бы вкусный он ни был. Пока остановил свой выбор на AT-9448. Вытянет? Покритикуйте выбор?Судя по попугаям (матрица, скорость и пр.) - наиболее адекватная из всех вариантов. Ну, конечно, за исключением 9942. Но этот вариант наш бюджет пока не вытягивает. Хм. Билет на это метро сильно дорогим выйдет. Полагаю, как раз стоимостью в подобный девайс. Примерно, километров тысячу только в одну сторону...

17:53 онлайн 636 Пинг длинка с сервера: # ping 10.100.110.10 PING 10.100.110.10 (10.100.110.10): 56 data bytes 64 bytes from 10.100.110.10: icmp_seq=0 ttl=64 time=13.719 ms 64 bytes from 10.100.110.10: icmp_seq=1 ttl=64 time=10.368 ms 64 bytes from 10.100.110.10: icmp_seq=2 ttl=64 time=13.782 ms 64 bytes from 10.100.110.10: icmp_seq=3 ttl=64 time=13.650 ms 64 bytes from 10.100.110.10: icmp_seq=4 ttl=64 time=8.995 ms 64 bytes from 10.100.110.10: icmp_seq=5 ttl=64 time=12.385 ms 64 bytes from 10.100.110.10: icmp_seq=6 ttl=64 time=13.544 ms ^C --- 10.100.110.10 ping statistics --- 7 packets transmitted, 7 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 8.995/12.349/13.782/1.782 ms Пинг с длинка: DGS-3100# ping 10.100.110.1 Pinging (10.100.110.1) with 56 bytes of data: 56 bytes from 10.100.110.1: icmp_seq=1. time=20 ms 56 bytes from 10.100.110.1: icmp_seq=2. time=20 ms 56 bytes from 10.100.110.1: icmp_seq=3. time=20 ms 56 bytes from 10.100.110.1: icmp_seq=4. time=20 ms ----10.100.110.1 PING Statistics---- 4 packets transmitted, 4 packets received, 0% packet loss round-trip (ms) min/avg/max = 20/20/20 Иногда даже наблюдается потеря пакетов. И это на устройство, включенное через 50 см патчкорд. Вот загрузка сервера: # top -SI last pid: 35356; load averages: 1.68, 1.63, 1.54 up 5+19:33:47 17:53:27 359 processes: 6 running, 343 sleeping, 10 waiting CPU states: 2.6% user, 0.0% nice, 10.3% system, 30.8% interrupt, 56.2% idle Mem: 525M Active, 91M Inact, 290M Wired, 35M Cache, 111M Buf, 39M Free Swap: 1983M Total, 44K Used, 1983M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 1 171 ki31 0K 16K RUN 1 112.7H 67.43% idle: cpu1 15 root 1 -44 - 0K 16K CPU0 0 59.6H 58.25% swi1: net 12 root 1 171 ki31 0K 16K RUN 0 72.5H 35.99% idle: cpu0 28 root 1 -68 - 0K 16K - 1 879:13 14.06% dummynet 19590 root 4 96 0 143M 72032K select 1 79:39 2.15% mpd4 13 root 1 -32 - 0K 16K RUN 1 87:28 0.98% swi4: clock 21578 root 3 81 -15 21716K 16488K RUN 1 62:22 0.20% ipcad

Онлайн 535: пинг на Длинк: # ping 10.100.110.10 PING 10.100.110.10 (10.100.110.10): 56 data bytes 64 bytes from 10.100.110.10: icmp_seq=0 ttl=64 time=3.204 ms 64 bytes from 10.100.110.10: icmp_seq=1 ttl=64 time=2.674 ms 64 bytes from 10.100.110.10: icmp_seq=2 ttl=64 time=2.340 ms 64 bytes from 10.100.110.10: icmp_seq=3 ttl=64 time=2.000 ms 64 bytes from 10.100.110.10: icmp_seq=4 ttl=64 time=2.321 ms 64 bytes from 10.100.110.10: icmp_seq=5 ttl=64 time=2.964 ms 64 bytes from 10.100.110.10: icmp_seq=6 ttl=64 time=3.147 ms 64 bytes from 10.100.110.10: icmp_seq=7 ttl=64 time=2.530 ms ^C --- 10.100.110.10 ping statistics --- 8 packets transmitted, 8 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 2.000/2.647/3.204/0.402 ms Пинг С длинка: DGS-3100# ping 10.100.110.1 Pinging (10.100.110.1) with 56 bytes of data: 56 bytes from 10.100.110.1: icmp_seq=1. time=0 ms 56 bytes from 10.100.110.1: icmp_seq=2. time=0 ms 56 bytes from 10.100.110.1: icmp_seq=3. time=20 ms 56 bytes from 10.100.110.1: icmp_seq=4. time=0 ms ----10.100.110.1 PING Statistics---- 4 packets transmitted, 4 packets received, 0% packet loss round-trip (ms) min/avg/max = 0/5/20 Т.е., пока еще терпимо, но уже начинают проскакивать 20мс. Загрузка сервера: # top -SI last pid: 2250; load averages: 1.52, 1.24, 1.20 up 5+16:26:40 14:46:20 352 processes: 6 running, 336 sleeping, 10 waiting CPU states: 0.2% user, 0.0% nice, 12.8% system, 19.5% interrupt, 67.5% idle Mem: 503M Active, 85M Inact, 289M Wired, 37M Cache, 111M Buf, 66M Free Swap: 1983M Total, 44K Used, 1983M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 1 171 ki31 0K 16K RUN 1 110.4H 78.96% idle: cpu1 12 root 1 171 ki31 0K 16K RUN 0 71.7H 49.41% idle: cpu0 15 root 1 -44 - 0K 16K CPU0 0 57.5H 39.99% swi1: net 28 root 1 -68 - 0K 16K - 1 846:22 12.26% dummynet 19590 root 2 100 0 143M 71988K select 1 73:57 6.54% mpd4 13 root 1 -32 - 0K 16K RUN 1 85:12 0.29% swi4: clock 23571 www 1 4 0 71772K 11488K sbwait 1 3:37 0.29% httpd