kamd Опубликовано 28 июля, 2008 (изменено) · Жалоба Столкнулся с такой проблемой: Приобрёл тут гигабитные 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 и не париться? Кто-нибудь сталкивался? Как решили проблему? Изменено 28 июля, 2008 пользователем kamd Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 28 июля, 2008 · Жалоба "Уважаемые товарищи ученые, у мине в подполе вот уже который год происходит подземный стук, расскажите пожалуйста, отчего и почему он происходит." (С) АБС Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kapa Опубликовано 28 июля, 2008 · Жалоба пока не сталкивался - сейчас тоже использую то, чот и Вы, и тоже тестирую на новом серваке с новыми сетевухами 7.0 ядро какое используете? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kamd Опубликовано 28 июля, 2008 (изменено) · Жалоба Если бы некоторые граждане с татуина были бы более разумными, чем, например, неразумные 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 Изменено 28 июля, 2008 пользователем kamd Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kamd Опубликовано 28 июля, 2008 (изменено) · Жалоба Вот трасировки через новый сервак на 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] Трассировка завершена. Изменено 28 июля, 2008 пользователем kamd Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kamd Опубликовано 28 июля, 2008 · Жалоба уууууууу. японский бог, да там ещё и потери на 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kapa Опубликовано 28 июля, 2008 (изменено) · Жалоба ядро у меня такое: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 Есть мнение, что SMP на нагруженных роутерах - зло.Плюс HZ, думаю, можно до 2000 поднять, это если без фанатизма. Драйвер на сетевую попробовать яндексовский. Параметры sysctl на старом и новом серверах сравните. Если что нестандартное вносили - покажите? Плюс нагрузку в PPS и KBPS примерную, если можно. upd: Ах, да - только не пинайте, но поллинг я бы из ядра тоже выкинул. Изменено 28 июля, 2008 пользователем kapa Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 28 июля, 2008 · Жалоба Есть мнение, что SMP на нагруженных роутерах - зло. Бред. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kapa Опубликовано 28 июля, 2008 · Жалоба Есть мнение, что SMP на нагруженных роутерах - зло. Бред. Возможно, у меня на рабочем SMP, и тестов сравнительных пока не проводил, но тут: https://calomel.org/network_performance.htmlи где-то ещё читал. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kamd Опубликовано 28 июля, 2008 · Жалоба По моему опыту поллинг - это зло на серверах, где у меня используется 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. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 29 июля, 2008 · Жалоба Есть мнение, что kern.polling.enable вообще deprecated. Так же есть мнение, что EXPI9402, как в прочем и EXPI9300, умеют MSI. Что круто. Вы бы для интереса таки с 4BSD шедуллером пересобрались, дабы наглядно подтвердить зло ULE. На 6.3 + EXPI9300 6 + Core2 1.8 ГГц, Ваш диагноз не подтвержден, ни с 4BSD ни с ULE. Более того, машина не затыкалась при нагрузке ~700Мбит/с а точнее ~70 kpps, что для нее удовлетворительно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kamd Опубликовано 29 июля, 2008 (изменено) · Жалоба Я как раз в процессе сборки 7.0 с 4BSD. Есть мнение, что в Вашем случае ключевое слово это 6.3 Насколько я знаю, в 7.0 они там чего-то сильно поменяли в плане оптимизации многозадачности на многоядерниках. Какие-то там семафоры задержек или как-то так, я просто в системном программировании вообще никак. Такие скорости на 9402 мне пока не удавалось наблюдать, но по некоторым сведениям потолок гигабитных сетевух в pci разъём это 14.8 мегабайт в секунду. Выдаётся на других (не обсуждаемых здесь, построенных на вообще одноядерных процах и 6.x-stable) серваках, где нет ipnat'а и там тупо форвардинг идёт. На них, кстати, поллинг меняет картину загрузки системы между interrupt и system/user. Кстати, возможно это (поллинг) будет уже не актуален на 7.0, потому что насколько я помню, что читал в рассылке, что они усиленно работают над оптимизацией дров для работы "быстро и красиво" без поллинга. Изменено 29 июля, 2008 пользователем kamd Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 29 июля, 2008 · Жалоба Возможно, у меня на рабочем SMP, и тестов сравнительных пока не проводил, но тут: https://calomel.org/network_performance.htmlи где-то ещё читал. Во-первых, статья устарела года на три. Во-вторых, про FreeBSD там всего один абзац, не имеющий никакого отношения к реальности. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kapa Опубликовано 29 июля, 2008 (изменено) · Жалоба По моему опыту поллинг - это зло на серверах, где у меня используется ipnat, где его нет - поллинг великая весчь.У меня ipnat вообще не используется, но поллинг убрал из ядра.Плюс он, кажется, мешался при сборке с драйверами от яндекса. Что за яндексовский драйвер? Что-то я сильно стремаюсь подобных экспериментов, ибо обновляюсь по cvsup и там всё замечательно приходит обновлённое, по мере готовности оного. http://people.yandex-team.ru/~wawa/Не надо стрематься - попробуйте ;) Из изменённых на обоих серверах 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, то я даже не знаю что. у меня на 6.2: net.inet.tcp.recvspace=1048576 net.inet.tcp.sendspace=1048576 kern.ipc.maxsockbuf=4194304 kern.ipc.nmbclusters=65536 net.inet.ip.portrange.first=5700 kern.ipc.somaxconn=65535 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.inet.icmp.icmplim=30 net.inet.ip.intr_queue_maxlen=4096 net.inet.tcp.delayed_ack=0 net.inet.tcp.delacktime=10 net.inet.tcp.newreno=0 net.inet.tcp.msl=2500 net.inet.ip.rtmaxcache=1024 net.inet.raw.recvspace=65536 net.inet.ip.dummynet.hash_size=8192 net.inet.ip.fw.dyn_ack_lifetime=60 net.inet.ip.fw.dyn_syn_lifetime=10 net.inet.ip.fw.dyn_fin_lifetime=10 net.inet.ip.fw.dyn_max=16192 net.inet.ip.fastforwarding=1 net.isr.direct=1 Что-то, наверняка, чрезмерно задрано, но оперативки более чем достаточно, поэтому не мешает. Такие скорости на 9402 мне пока не удавалось наблюдать, но по некоторым сведениям потолок гигабитных сетевух в pci разъём это 14.8 мегабайт в секунду.14.8 на все pci сетевухи? т.е. на 2-ух по 7.4?Не слушайте их - у меня такая нагрузка, которую Вы показали, ночью. И сетевухи pci. И ни одного пакета не теряется, даже в ЧНН. Изменено 29 июля, 2008 пользователем kapa Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kapa Опубликовано 29 июля, 2008 (изменено) · Жалоба Возможно, у меня на рабочем SMP, и тестов сравнительных пока не проводил, но тут: https://calomel.org/network_performance.htmlи где-то ещё читал. Во-первых, статья устарела года на три. Во-вторых, про FreeBSD там всего один абзац, не имеющий никакого отношения к реальности. Я на абзац с FreeBSD и не показывал. Давайте полезем в теорию - просто интересно, как оно на самом деле. Мне кажется, что всё логично. Если при SMP в единицу времени только 1 процессор может работать с памятью, то особого прироста в производительности мы не получим. Возможно, система будет стараться равномерно распределить нагрузку по процессорам, но оно нам на роутере надо? А без SMP нас это не заботит, зато свободный процессор может обработать прерывание, когда занят другой. Так? Изменено 29 июля, 2008 пользователем kapa Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kamd Опубликовано 29 июля, 2008 · Жалоба Такие скорости на 9402 мне пока не удавалось наблюдать, но по некоторым сведениям потолок гигабитных сетевух в pci разъём это 14.8 мегабайт в секунду.14.8 на все pci сетевухи? т.е. на 2 уе по 7.4?Не слушайте их - у меня такая нагрузка, которую Вы показали, ночью. И сетевухи pci. И ни одного пакета не теряется, даже в ЧНН. 2 уе?! при чём тут уе?! 14.8 мегабайт/с на одной сетевухе в одну сторону. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 29 июля, 2008 · Жалоба Не так, "схожие" данные должны обрабатываться на соответствующем им процессоре, иначе получим проблему "непопадания" в кеш процессора. Если данные будут прыгать по процессорам - производительность упадет в разы. Если у вас еще и AMD x86_64 NUMA - вообще жопа будет (там память прикреплена к каждому процессору). В Линуксе это учтено, во Фре - не знаю. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kamd Опубликовано 29 июля, 2008 (изменено) · Жалоба Давайте полезем в теорию - просто интересно, как оно на самом деле. Мне кажется, что всё логично. Если при SMP в единицу времени только 1 процессор может работать с памятью, то особого прироста в производительности мы не получим. Возможно, система будет стараться равномерно распределить нагрузку по процессорам, но оно нам на роутере надо? А без SMP нас это не заботит, зато свободный процессор может обработать прерывание, когда занят другой. Так? Однако есть мнение, что на современных многоядерных процах таки немного толще и быстрее шина обмена данными с памятью, тот же hyperTransport, через него же проц и с памятью тоже общается или я не прав?! А вообще было бы чуднО, если бы 4хядерник phenom 9750 мог работать с памятью в единицу времени в таком же объёме как скажем одноядерник athlon 64 3200+ или двух ядерник x2 64 5200+. Очень чуднО, но к счастью это не так. Изменено 29 июля, 2008 пользователем kamd Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kapa Опубликовано 29 июля, 2008 · Жалоба Такие скорости на 9402 мне пока не удавалось наблюдать, но по некоторым сведениям потолок гигабитных сетевух в pci разъём это 14.8 мегабайт в секунду.14.8 на все pci сетевухи? т.е. на 2 уе по 7.4?Не слушайте их - у меня такая нагрузка, которую Вы показали, ночью. И сетевухи pci. И ни одного пакета не теряется, даже в ЧНН. 2 уе?! при чём тут уе?! 14.8 мегабайт/с на одной сетевухе в одну сторону. Опечатался. Читать "на 2-ух".Ок. Если 14.8 на одной в одну сторону, то сколько на 2ух в две стороны? Короче, глупости это всё - пакеты при этом какого размера, для начала? Не так, "схожие" данные должны обрабатываться на соответствующем им процессоре, иначе получим проблему "непопадания" в кеш процессора. Если данные будут прыгать по процессорам - производительность упадет в разы. Если у вас еще и AMD x86_64 NUMA - вообще жопа будет (там память прикреплена к каждому процессору). В Линуксе это учтено, во Фре - не знаю. О каких "схожих" данных мы говорим в контексте роутера? Каждое прерывание без поллинга, насколько я понимаю, обрабатывается отдельно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 29 июля, 2008 · Жалоба Давайте полезем в теорию - просто интересно, как оно на самом деле. Зачем мне теория ? Я просто лезу на рабочий роутер и смотрю, как оно там на самом деле. А Вам советую изучать матчасть, и экспериментировать почаще на больших нагрузках. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kamd Опубликовано 29 июля, 2008 · Жалоба Опечатался. Читать "на 2-ух".Ок. Если 14.8 на одной в одну сторону, то сколько на 2ух в две стороны? Короче, глупости это всё - пакеты при этом какого размера, для начала? В другую сторону на графиках вижу 3.7 мегабайта в секунду. На 2х стало быть надо умножить на 2. Размер пакета - это вопрос на красный диплом. Предполагаю, что их дохера разных. Кстати, типа "прикол" про поллинг. Один из обсуждаемых мной серверов на 7.0 (железо: мать gigabyte GA-MA78GM-S2H, проц phenom 9750). Поллинг включен в sysctl.ctl. Выключаем поллинг через sysctl, то бишь в онлайне. Машина пропадает из онлайна и больше не загружается. Мать сдохла и на экран ничего не выдаёт, в спикер не пищит, линки на вставленной в pcie4x сетевухе не горят. Сетевуха жива уже проверил. Проц врядли умер. Остаётся мать по идее. Этот аспект ещё не проверял. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 29 июля, 2008 · Жалоба О каких "схожих" данных мы говорим в контексте роутера? Каждое прерывание без поллинга, насколько я понимаю, обрабатывается отдельно. Да ну ? Это сколько же Mpps Вы там гоняете, что Вас начали на 7.0 прерывания заботить ? Я предполагаю, sysctl dev.em у Вас правильно выставлены ? ;-) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kapa Опубликовано 29 июля, 2008 (изменено) · Жалоба Давайте полезем в теорию - просто интересно, как оно на самом деле. Зачем мне теория ? Я просто лезу на рабочий роутер и смотрю, как оно там на самом деле. А Вам советую изучать матчасть, и экспериментировать почаще на больших нагрузках. Тогда не вылазьте, пожалуйста, из своего рабочего роутера в форум, где люди пытаются разобраться и прийти к истине, со своим флеймом? Изменено 29 июля, 2008 пользователем kapa Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 29 июля, 2008 · Жалоба Тогда не вылазьте, пожалуйста, из своего рабочего роутера в форум, где люди пытаются разобраться и прийти к истине со своим флеймом? Ухожу, ухожу, ухожу. Нечего было связываться с детским садом. :-) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kamd Опубликовано 29 июля, 2008 (изменено) · Жалоба jab, почему всё-таки Ваш ник так похож на Ваше поведение или наоборот, я ещё не разобрался толком?!?! Разве нельзя взять и открыться душой к человечеству, научать несмышлёнышей как надо, а то Вы таким поведением только карму себе портите!?! Мне конечно всё равно, это Ваша карма, но всё же..... Изменено 29 июля, 2008 пользователем kamd Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...