kamd

У меня уже есть PA сейчас, хочу второй канал и чтобы юзеров с постоянным ипом мог переключать с одного канала на другой. Я хочу свободно менять операторов, у которых я беру трафик, а не каждый раз менять тысячам юзеров внешние IP-адреса. Хоть и автоматом. Юзеры от этого не становятся более счастливыми.

Пытаюсь получить PI блок через netup. Переписываюсь уже с 25 августа (АВГУСТА), бабло заслали в сентябре. После моих очередных, причём повторных запросов, у них возникают очередные уточняющие вопросы. Что-то даже сомневаюсь, что запрос в RIPE уходил. Устал и надоело, мне нужно работать. Посему жду от них очередного ответа, потом буду хотеть обратно денег, а потом готов заплатить тому, кто сделает это быстро и чётко. LIR не хочу, потому что нужно ежеквартально блатить бабло.

В догонку, я бы не стал брать оптероны, взял бы феномы. У них общий кэш до 4х мегов.

На днях мне кто-то говорил, что iptables на больших трафиках лажает. Не хочу разводить флейм и религиозные войны, но долой линукс, даёшь фрибздю. А какая версия фри стоит, что она не знает что это за проц? А проц наверное 64 X2 6400+ ? Или что? Даже одноядерный athlon 64?

"1.6 Core 2 Duo" Имеется в виду 1.6Ghz? Не вижу такого в продаже. :( Интел я как-то стремаюсь пользовать - был негативный опыт. Занимался "удовольствиями" пару суток. Дело было в необходимости обновить биос под новый проц, но так как других интелов у меня не было, то было это нелегко. А так интел конечно завлекает своими объёмами кеша у процов. Остаётся вопрос, так ли реально важен кэш?!

Где-то на этом форуме читал, что шейпер не может работать на двух процессорах. Он типа работает только на одном. На другом, например, работает нат, который тоже как будто не может работать более чем на одном проце. Насколько это правда не знаю. Отсюда напрашивается вывод, что предпочтительнее выбрать бОльшую частоту. Сейчас лично у меня на pf (nat), ipfw (shape) с максимальным потоком в 16МБ/с справляется Athlon X2 5200+. Это на pci сетевухах(!!). Сильно сомневаюсь, что будет какое-то заметное(!) увеличение производительности от бОльшего кеша, ведь по идее контроллер памяти находится в самом проце, а вся таблица натинга (шейпа может конечно и влезет) в кеш не влезет по-любому. Хотя это моё мнение голословно, никаких научных данных на сей счёт у меня нет. В ближайшее время ожидаю появления проца Athlon X2 6000+ который 3.1MHz (именно 3.1, а не старый 3.0), хочу на нём собрать роутер и туда уже пойдут гигабитные интел сетевухи в pci-e4x (9402). В догонку: когда нат жил на ipnat, то при переносе всего хозяйства на phenom x4 9750 (пару месяцев назад) сильно падала производительность (скорость пропускаемого потока). На pf не проверял ещё.

Пока готовится побеждать 6.3-stable/amd64 и её SCHED_4BSD. Тестовое включение сегодня. Забыл упомянуть, что на этих серваках ещё живёт ng_ipacct в ядерной netgraph-инкарнации. Предполагаю в частности, что он может вносить свою лепту в глюки 7рки, потому как по логике вещей 7рка весьма свежа, а ng_ipacct ажно 2006 года, хоть и декабрь месяц.

Может таки стоит попробовать влить туда 7.0. Всяко, насколько я догадываюсь, в 7.0 есть такие изменения, коих нет в 6.3, а раз 6.3 не грузится, то ничего и не потеряешь, разве что cd болванку. А потом бы ради эксперимента я бы ещё и 8.0-current последнего snapshot'а попробовал туда присунуть.

Пересобрал ядро 7.0-stable с SCHED_4BSD Юзеры прогрузили пока вот так: input (Total) output packets errs bytes packets errs bytes colls 13639 0 11565904 13685 0 11571539 0 9598 0 8074513 9626 0 8078305 0 10590 0 8924368 10616 0 8936845 0 7471 0 5938793 7493 0 5951551 0 6998 0 5316109 7014 0 5309093 0 9917 0 8316299 9930 0 8314639 0 13524 0 11441137 13537 0 11431197 0 9810 0 7824054 9810 0 7819897 0 11001 0 9124711 11010 0 9114193 0 10785 0 9125521 10778 0 9106005 0 17724 0 15283630 17737 0 15256435 0 14489 0 12195505 14512 0 12184468 0 11481 0 9626571 11485 0 9610277 0 9691 0 8132890 9707 0 8129699 0 11058 0 9320301 11080 0 9320101 0 7985 0 6590726 7997 0 6592374 0 6386 0 5083150 6395 0 5081842 0 5507 0 4202503 5480 0 4199481 0 8941 0 7299324 8993 0 7296291 0 9106 0 7537080 9122 0 7539977 0 10322 0 8862684 10323 0 8848024 0 input (Total) output packets errs bytes packets errs bytes colls 12974 0 10775142 12995 0 10784814 0 8582 0 6783896 8602 0 6785202 0 9434 0 7757068 9441 0 7757555 0 8219 0 6800261 8229 0 6798726 0 6317 0 5107211 6341 0 5115138 0 7941 0 6496504 7968 0 6511405 0 7714 0 6212974 7718 0 6203770 0 12176 0 10249689 12190 0 10236749 0 8800 0 7427485 8816 0 7419721 0 15115 0 12816684 15136 0 12811319 0 14662 0 12488114 14717 0 12495346 0 10039 0 8270831 10167 0 8294895 0 11424 0 9548235 11520 0 9555268 0 14130 0 12091890 14129 0 12070238 0 13681 0 11413626 13687 0 11390080 0 10903 0 9212885 10899 0 9190901 0 9095 0 7619354 9095 0 7600869 0 9149 0 7615648 9150 0 7596898 0 7879 0 6428285 7878 0 6412342 0 10301 0 8716622 10302 0 8695324 0 8893 0 7226475 8893 0 7208397 0 однако пока они ходят через allow ip from any to any, то есть без шейпа. Буду включать шейп и смотреть как оно. Сейчас пересобираю ядро без POLLING и без HZ.

Сомневаюсь, ибо у нас в сети скорость инета на всех уже в несколько раз больше скорости локалки для каждого конкретного, а своей феррари под окнами я пока не виду. Чья-то может и стоит, но почему-то не моя.

а как у меня по ходу всё плохо на новых 9402.... ph22# sysctl dev.em dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 6.9.5 dev.em.0.%driver: em dev.em.0.%location: slot=0 function=0 dev.em.0.%pnpinfo: vendor=0x8086 device=0x105e subvendor=0x8086 subdevice=0x115e class=0x020000 dev.em.0.%parent: pci2 dev.em.0.debug: -1 dev.em.0.stats: -1 dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_processing_limit: 100 dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 6.9.5 dev.em.1.%driver: em dev.em.1.%location: slot=0 function=1 dev.em.1.%pnpinfo: vendor=0x8086 device=0x105e subvendor=0x8086 subdevice=0x115e class=0x020000 dev.em.1.%parent: pci2 dev.em.1.debug: -1 dev.em.1.stats: -1 dev.em.1.rx_int_delay: 0 dev.em.1.tx_int_delay: 66 dev.em.1.rx_abs_int_delay: 66 dev.em.1.tx_abs_int_delay: 66 dev.em.1.rx_processing_limit: 100 А в общем и на старых серваках тоже самое. Что даёт увеличение этих параметров? Понятно, что в общих словах "производительность", а подробнее если?! Кстати вопрос, а яндекс драйвера. Это типа яндекс на этих дровах работает на своих серваках?

jab, почему всё-таки Ваш ник так похож на Ваше поведение или наоборот, я ещё не разобрался толком?!?! Разве нельзя взять и открыться душой к человечеству, научать несмышлёнышей как надо, а то Вы таким поведением только карму себе портите!?! Мне конечно всё равно, это Ваша карма, но всё же.....

В другую сторону на графиках вижу 3.7 мегабайта в секунду. На 2х стало быть надо умножить на 2. Размер пакета - это вопрос на красный диплом. Предполагаю, что их дохера разных. Кстати, типа "прикол" про поллинг. Один из обсуждаемых мной серверов на 7.0 (железо: мать gigabyte GA-MA78GM-S2H, проц phenom 9750). Поллинг включен в sysctl.ctl. Выключаем поллинг через sysctl, то бишь в онлайне. Машина пропадает из онлайна и больше не загружается. Мать сдохла и на экран ничего не выдаёт, в спикер не пищит, линки на вставленной в pcie4x сетевухе не горят. Сетевуха жива уже проверил. Проц врядли умер. Остаётся мать по идее. Этот аспект ещё не проверял.

Однако есть мнение, что на современных многоядерных процах таки немного толще и быстрее шина обмена данными с памятью, тот же hyperTransport, через него же проц и с памятью тоже общается или я не прав?! А вообще было бы чуднО, если бы 4хядерник phenom 9750 мог работать с памятью в единицу времени в таком же объёме как скажем одноядерник athlon 64 3200+ или двух ядерник x2 64 5200+. Очень чуднО, но к счастью это не так.

14.8 на все pci сетевухи? т.е. на 2 уе по 7.4?Не слушайте их - у меня такая нагрузка, которую Вы показали, ночью. И сетевухи pci. И ни одного пакета не теряется, даже в ЧНН. 2 уе?! при чём тут уе?! 14.8 мегабайт/с на одной сетевухе в одну сторону.

Я как раз в процессе сборки 7.0 с 4BSD. Есть мнение, что в Вашем случае ключевое слово это 6.3 Насколько я знаю, в 7.0 они там чего-то сильно поменяли в плане оптимизации многозадачности на многоядерниках. Какие-то там семафоры задержек или как-то так, я просто в системном программировании вообще никак. Такие скорости на 9402 мне пока не удавалось наблюдать, но по некоторым сведениям потолок гигабитных сетевух в pci разъём это 14.8 мегабайт в секунду. Выдаётся на других (не обсуждаемых здесь, построенных на вообще одноядерных процах и 6.x-stable) серваках, где нет ipnat'а и там тупо форвардинг идёт. На них, кстати, поллинг меняет картину загрузки системы между interrupt и system/user. Кстати, возможно это (поллинг) будет уже не актуален на 7.0, потому что насколько я помню, что читал в рассылке, что они усиленно работают над оптимизацией дров для работы "быстро и красиво" без поллинга.

По моему опыту поллинг - это зло на серверах, где у меня используется ipnat, где его нет - поллинг великая весчь. Архитектуру этого процесса/зависимости не знаю. SMP используется на обоих серваках и старых и новых, поэтому я думаю в данном контексте это монописуально. Из изменённых на обоих серверах sysctl параметров: kern.ipc.maxsockbuf=262144 net.inet.tcp.sendspace=65536 net.inet.tcp.recvspace=65536 net.inet.tcp.rfc1323=1 kern.ipc.nmbclusters=32768 Всё остальное если менялось между 6.2 и 7.0, то я даже не знаю что. kern.polling.enable стало быть 0, коли он отключен. Что за яндексовский драйвер? Что-то я сильно стремаюсь подобных экспериментов, ибо обновляюсь по cvsup и там всё замечательно приходит обновлённое, по мере готовности оного. Нагрузка в сообщении номер 6.

уууууууу. японский бог, да там ещё и потери на 18.23 ph23# netstat -w1d input (Total) output packets errs bytes packets errs bytes colls 11688 93 6594409 11691 0 6703130 0 12395 77 6884965 12294 0 6837494 0 13281 0 7606106 13204 0 7564631 0 12978 125 7470436 12853 0 7414926 0 12985 0 7423232 12853 0 7326047 0 11488 248 6313780 11472 0 6373532 0 12283 8 6921220 12094 0 6784097 0 13248 0 7933206 13109 0 7849810 0 12659 0 7546944 12584 0 7504513 0 10963 513 6013676 10928 0 6059609 0 11808 24 6573821 11728 0 6531786 0 12586 237 6730994 12419 0 6628138 0 12005 222 6499401 11928 0 6503764 0 13188 0 7814003 12985 0 7595651 0 13448 0 8149092 13267 0 7958515 0 13478 0 8126227 13454 0 8192621 0 13032 0 7822935 12932 0 7762155 0 12959 109 7542381 12896 0 7539812 0 11990 9 6867580 11933 0 6875807 0 11842 198 6671391 11687 0 6546975 0 на 18.23 всё отлично input (Total) output packets errs bytes packets errs bytes colls 16948 0 11584064 16614 0 11396092 0 16402 0 11443956 16166 0 11305375 0 16945 0 11749437 16684 0 11662726 0 17193 0 12326822 16878 0 12060733 0 16542 0 11763075 16367 0 11661302 0 16233 0 11391876 15957 0 11301515 0 16908 0 11525040 16661 0 11343808 0 16618 0 11591970 16428 0 11486749 0 16790 0 12022513 16495 0 11823020 0 16204 0 11752932 15972 0 11626471 0 17006 0 12440988 16716 0 12214340 0 15967 0 11101435 15687 0 11020102 0 16161 0 11644735 15933 0 11503895 0 16086 0 11018437 15718 0 10799456 0 16002 0 11526077 15813 0 11465016 0 17182 0 12091865 16837 0 11739725 0 17573 0 12281784 17339 0 12141434 0 16925 0 11847338 16675 0 11749539 0 17686 0 12296968 17458 0 12183482 0 17705 0 12899477 17329 0 12625959 0 18074 0 12259570 17851 0 12127838 0

Вот трасировки через новый сервак на 7.0-stable c SCHED-ULE, 4x проц, сетевуха интел 9402 172.18.18.23 это как раз этот новый сервак. C:\>tracert ya.ru Трассировка маршрута к ya.ru [213.180.204.8] с максимальным числом прыжков 30: 1 1 ms 1 ms <1 мс 10.10.116.1 2 <1 мс 1 ms <1 мс 172.17.17.76 3 1 ms 1 ms 2 ms 172.18.18.23 4 15 ms 10 ms 7 ms 77.246.x.y 5 12 ms 7 ms 6 ms yaol-uni-lgw.cen.medi-a.ru [77.246.97.9] 6 5 ms 4 ms 3 ms ix1-m10.yandex.net [193.232.246.93] 7 27 ms 28 ms 22 ms ya.ru [213.180.204.8] Трассировка завершена. C:\>tracert ya.ru Трассировка маршрута к ya.ru [213.180.204.8] с максимальным числом прыжков 30: 1 <1 мс <1 мс 1 ms 10.10.116.1 2 <1 мс <1 мс <1 мс 172.17.17.76 3 2 ms 1 ms 1 ms 172.18.18.23 4 30 ms 17 ms 4 ms 77.246.x.y 5 19 ms 35 ms 36 ms yaol-uni-lgw.cen.medi-a.ru [77.246.97.9] 6 23 ms 18 ms 48 ms ix1-m10.yandex.net [193.232.246.93] 7 55 ms 29 ms 27 ms ya.ru [213.180.204.8] Трассировка завершена. C:\>tracert ya.ru Трассировка маршрута к ya.ru [213.180.204.8] с максимальным числом прыжков 30: 1 1 ms <1 мс <1 мс 10.10.116.1 2 <1 мс <1 мс <1 мс 172.17.17.76 3 7 ms 2 ms 2 ms 172.18.18.23 4 28 ms 24 ms 19 ms 77.246.x.y 5 29 ms 34 ms 28 ms yaol-uni-lgw.cen.medi-a.ru [77.246.97.9] 6 19 ms 19 ms 19 ms ix1-m10.yandex.net [193.232.246.93] 7 15 ms 36 ms 28 ms ya.ru [213.180.204.8] Трассировка завершена. C:\>tracert ya.ru Трассировка маршрута к ya.ru [213.180.204.8] с максимальным числом прыжков 30: 1 3 ms 1 ms <1 мс 10.10.116.1 2 <1 мс <1 мс 1 ms 172.17.17.76 3 20 ms 3 ms 4 ms 172.18.18.23 4 44 ms 25 ms 6 ms 77.246.x.y 5 11 ms 9 ms 17 ms yaol-uni-lgw.cen.medi-a.ru [77.246.97.9] 6 6 ms 10 ms 5 ms ix1-m10.yandex.net [193.232.246.93] 7 8 ms 7 ms 7 ms ya.ru [213.180.204.8] Трассировка завершена. C:\>tracert ya.ru Трассировка маршрута к ya.ru [213.180.204.8] с максимальным числом прыжков 30: 1 1 ms <1 мс 2 ms 10.10.116.1 2 <1 мс <1 мс <1 мс 172.17.17.76 3 3 ms 2 ms 2 ms 172.18.18.23 4 37 ms 16 ms 12 ms 77.246.x.y 5 4 ms 2 ms 2 ms yaol-uni-lgw.cen.medi-a.ru [77.246.97.9] 6 11 ms 3 ms 2 ms ix1-m10.yandex.net [193.232.246.93] 7 60 ms 14 ms 5 ms ya.ru [213.180.204.8] Трассировка завершена. ===================== А вот трасировка через старый сервак на 6.2-stable, SCHED_4BSD и обычную intel гигабитную pci-сетевуху. 18.6 это как раз этот сервер. Комментарии как говорится излишни C:\>tracert ya.ru Трассировка маршрута к ya.ru [213.180.204.8] с максимальным числом прыжков 30: 1 <1 мс 1 ms 4 ms 10.10.116.1 2 <1 мс <1 мс <1 мс 172.17.17.76 3 <1 мс <1 мс <1 мс 172.18.18.6 4 1 ms 1 ms 1 ms 77.246.x.y 5 1 ms 1 ms 1 ms yaol-uni-lgw.cen.medi-a.ru [77.246.97.9] 6 1 ms 1 ms 1 ms ix1-m10.yandex.net [193.232.246.93] 7 1 ms 1 ms 1 ms ya.ru [213.180.204.8] Трассировка завершена. C:\>tracert ya.ru Трассировка маршрута к ya.ru [213.180.204.8] с максимальным числом прыжков 30: 1 1 ms <1 мс <1 мс 10.10.116.1 2 <1 мс <1 мс <1 мс 172.17.17.76 3 <1 мс <1 мс 1 ms 172.18.18.6 4 1 ms 1 ms 1 ms 77.246.x.y 5 1 ms 2 ms 1 ms yaol-uni-lgw.cen.medi-a.ru [77.246.97.9] 6 4 ms 2 ms 1 ms ix1-m10.yandex.net [193.232.246.93] 7 2 ms 3 ms 2 ms ya.ru [213.180.204.8] Трассировка завершена. C:\>tracert ya.ru Трассировка маршрута к ya.ru [213.180.204.8] с максимальным числом прыжков 30: 1 <1 мс <1 мс <1 мс 10.10.116.1 2 <1 мс <1 мс <1 мс 172.17.17.76 3 <1 мс <1 мс <1 мс 172.18.18.6 4 1 ms 1 ms 1 ms 77.246.x.y 5 1 ms 1 ms 1 ms yaol-uni-lgw.cen.medi-a.ru [77.246.97.9] 6 1 ms 2 ms 1 ms ix1-m10.yandex.net [193.232.246.93] 7 2 ms 1 ms 1 ms ya.ru [213.180.204.8] Трассировка завершена.

О какая древняя тема. Сейчас как раз закупил сетевухи expi9402pt pcie4x. Имхо на данный момент pci-x уже умер. Да и матери сильно дороже, не говоря уже о процах в их формфакторе.

Если бы некоторые граждане с татуина были бы более разумными, чем, например, неразумные kamdяне, то конкретно бы написали чего нужно более подробно расписать. На данный же момент, впрочем как и всегда, татуяне занимаются банальным флеймом. ядро у меня такое: include GENERIC options IPFIREWALL options IPFIREWALL_FORWARD options IPFIREWALL_VERBOSE options DUMMYNET options IPFILTER options IPDIVERT options DEVICE_POLLING options HZ=1000 options SMP options NETGRAPH options NETGRAPH_ETHER options NETGRAPH_SOCKET options NETGRAPH_TEE

Предполагаю, что когда скорость в локалке на абонента станет сравнимой с общей скорость инета на всех, то придётся всю схему переделывать, так не логичнее ли сразу сделать как надо, чтобы потом не злить абонентов перебоями, хотя это как кому удобнее и приятнее. ;)

+1 нужно давать чуть больше, чтобы: 1. избежать обращений в тех.поддержку о том, что скорость ниже и никогда по тарифу 2. абонент радуется, когда скорость чуть выше, некоторые из них думают, что натягивают чуть-чуть оператора, типа он лох и даёт больше, сам того не зная 3. положительное сарафанное радио

Однако столкнулся с такой проблемой. http://forum.nag.ru/forum/index.php?showtopic=44096

Столкнулся с такой проблемой: Приобрёл тут гигабитные pci-e4х сетевухи (до этого были/есть pci сетевухи, но предполагаю, что скоро упрусь там в потолок pci-шины), под это дело решил организовать 4х ядерные серваки, до этого шейпера работали на athlon 64 x2 5200+ (стоит фря 6.2-stable/amd64, до 6.3-stable как-то не нашёл время обновиться). Туда решил поставить 7.0, прокачал её до stable, всё настроил, протестил, пустил в работу и при реальной нагрузке.... получил грабли. Грешу на новый шедулер SCHED-ULE, который в 7.0-STABLE используется. На 6.X используется SCHED-4BSD Так вот на новых серверах при той же загрузке, что и на старых, начал расти пинг, вплоть до сотен мс, обычно он -1 или 1, и не больше 2-5 мс. И вообще трасировка через новые серваки какая-то неадекватная, не видно былой стабильности. Вот собственно вопрос, кто в этом виноват? SCHED-ULE? Если собрать 7.0-STABLE/amd64 c SCHED-4BSD, то быстродействие вернётся хотя бы на уровень 6.3? Или всё равно будет меньше? Или станет больше? И не вылезет ли ещё каких-либо интересных граблей при сочетании 7.0 и SCHED-4BSD? Или стоит поставить на 4х процы 6.3-stable/amd64 и не париться? Кто-нибудь сталкивался? Как решили проблему?