[X-RaY™]

Есть вопросы по разгону на freebsd, пробовали i-920 разогнанный в пптп сервере использовать, грустная вышла история...

i920 (2660 родная частота) разогнал до 3.8 ггц(только множитель и частота шины), отключил спит степ и все энергосбережение это. Кулер поставил получше родного(на штатной частоте при пиковой загрузке часами макс температура самого горячего ядра 42 градуса) Прогонял все это под виндой 2е суток всм стандартым оверклокер софтом(prime95, occt и т.д.), все стабильно, все замечательно. Снизил до 3.6 поставил на роутер, в результате ребут раз в 2-3 часа обеспечен(температура в норме макс 60 град), причем не паники ничего, просто ребут и все, снижал до 3.4, 3.2, результат тот же, вернул на родные настройки, работает как часы.

2 вопроса что не так может быть и чем так в корне отличается нагрузка на процессор и память в винде и фре, если в винде оно проходит кучу тестов и бернеров без проблем?

Спасибо.

[kayot]

Перегревается что-то. БП, vrm платы, чипсет, чипы сетевок, и т.д.

У нас похожая ситуация с одним сервером supermicro - ставишь корпусные кулера в тихий режим и машина ребутится раз в несколько дней, хотя температуры всего что можно промониторить минимальные(cpu 30 в покое, 47 в максимальной загрузке). Ставишь максимальные обороты(с адским шумом) - и все как часы месяцами. Вентиляция в корпусе заведомо хорошая в любом режиме, даже на минимальных оборотах корпусные 10ваттные дельты маслают так, что на метр от сервера ветер стоит :)

Изменено 2 января, 2011 пользователем kayot

[X-RaY™]

Разве что сетевые(внешние 2х портовые интел), только не совсем ясно чего им перегреваться то, система без корпуса, и в помещении прохладно.

[kayot]

Без корпуса как раз температура всех компонентов выше, и иногда на десятки градусов. Если это не кодеген без кулеров конечно :)

[Ivan_83]

2 вопроса что не так может быть и чем так в корне отличается нагрузка на процессор и память в винде и фре, если в винде оно проходит кучу тестов и бернеров без проблем?

Оверклокерский софт не дрючит шины интенсивно, максимум память и видео.

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

А у фряхи там мбуфы ходят, в которых куча указателей, одна ошибка - уже вполне может привести к перезаписи чужих данных и коллапсу.

И сетевые она дёргает.

Им вообще лучше частоту шины не менять.

[X-RaY™]

Спасибо за ответ, а кто то может поделится опытом разгона именно на фре ? Для i920 i950 ?

Просто обидно, дома и на 3.8 работает отлично, а на сервере 3.2 и то не завелось ((

[[anp/hsw]]

Ребята, что вы дурью маетесь?

Большинство из вас, тут присутствующих - коммерческие операторы связи.

Глюки или зависание от разгона серверов - это репутация ВАШЕЙ компании, качество ВАШЕГО интернета, отношение к ВАМ пользователей.

 

Вам это надо? Ради копеечной, ЕДИНОРАЗОВОЙ, экономии вы в дальнейшем расплачиваетесь регулярными нештатными ситуациями.

Разница в скорости при разгоне - это не то, что вам нужно.

 

Если у вас тормозит проц 2ГГЦ, это значит что у вас не меньше 300-500 пользователей. Проживите месяц без прибыли, купите нормальный сервер :)

 

[NiTr0]

По поводу разгона - ИМХО на сервере это не самое удачное решение. И я не представляю, чем можно у ISP загрузить i7 так, чтобы это нельзя было распараллелить на 2-3 машины. Разве что роутингом нескольких гигабит с натом - хотя опять же никто не мешает распределить это по нескольким машинам...

Кстати, для оценки реальной температуры компонентов при экспериментах с разгоном неплохо бы обзавестись пирометром.

 

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

Совсем даже не пофиг, на выхлопе будет битый архив - о чем архиватор радостно оповестит. Да и OCCT к примеру проверяет, что в памяти творится во время стресс-теста...

 

А вообще - был у меня случай пару лет назад, собрали новый брас, на внешне довольно кошерной мамке от асуса (полимерные кондеры, вроде неплохой MCP78 чипсет с шикарным как для набортного ланом - по возможностям сродни МСР55, солидное охлаждение и т.д.), угнездили туда 2-головый феном, нормальную память, все это завели - и оно в час пик весело покрашилось в кернел паник. Поставили другую сеть (интел десктопный) - спустя час или около того покрашилось опять. Сменили проц на К8, поставили туда память со старой железки - краш еще быстрее. Плюнули, собрали старую железку на место новой, начали с новой разбираться - не крашится и все в лабораторных условиях, и iperf гонял по туннелям с траффиком близким к присутствовавшему на железке, и в иптейблс десятки тысяч пустых правил вбивал - не крашится; под виндой - тоже как десктоп прекрасно стабильно работает; плюнул, заодно зарекся даже смотреть в сторону свежих нвидиевских чипсетов - хотя проблема скорее всего не в чипсете как таковом, но все же...

Изменено 3 января, 2011 пользователем NiTr0

[photon]

А вообще - был у меня случай пару лет назад, собрали новый брас, на внешне довольно кошерной мамке от асуса (полимерные кондеры, вроде неплохой MCP78 чипсет с шикарным как для набортного ланом - по возможностям сродни МСР55, солидное охлаждение и т.д.), угнездили туда 2-головый феном, нормальную память, все это завели - и оно в час пик весело покрашилось в кернел паник. Поставили другую сеть (интел десктопный) - спустя час или около того покрашилось опять. Сменили проц на К8, поставили туда память со старой железки - краш еще быстрее. Плюнули, собрали старую железку на место новой, начали с новой разбираться - не крашится и все в лабораторных условиях, и iperf гонял по туннелям с траффиком близким к присутствовавшему на железке, и в иптейблс десятки тысяч пустых правил вбивал - не крашится; под виндой - тоже как десктоп прекрасно стабильно работает; плюнул, заодно зарекся даже смотреть в сторону свежих нвидиевских чипсетов - хотя проблема скорее всего не в чипсете как таковом, но все же...

Это известная тема. NVidia не предоставляет спеки на свои сетевухи и чипсеты, хотя там и нет никакой выдающейся интеллектуальной собственности. Поэтому дрова для Linux написаны в основном при помощи reverse engineering, что и приводит к постоянным паникам.

[jab]

Ребята, что вы дурью маетесь?

Большинство из вас, тут присутствующих - коммерческие операторы связи.

Глюки или зависание от разгона серверов - это репутация ВАШЕЙ компании, качество ВАШЕГО интернета, отношение к ВАМ пользователей.

 

Вам это надо? Ради копеечной, ЕДИНОРАЗОВОЙ, экономии вы в дальнейшем расплачиваетесь регулярными нештатными ситуациями.

Разница в скорости при разгоне - это не то, что вам нужно.

 

Если у вас тормозит проц 2ГГЦ, это значит что у вас не меньше 300-500 пользователей. Проживите месяц без прибыли, купите нормальный сервер :)

Много лет штатно разгоняю дешевые процы на 15-20%. Никаких нештатных ситуаций за весь срок службы. А лохи пусть Xeon'ы покупают, и сидят месяц без прибыли.

[jab]

По поводу разгона - ИМХО на сервере это не самое удачное решение. И я не представляю, чем можно у ISP загрузить i7 так, чтобы это нельзя было распараллелить на 2-3 машины. Разве что роутингом нескольких гигабит с натом - хотя опять же никто не мешает распределить это по нескольким машинам...

Распараллелить можно все, но когда у Вас этих машин уже несколько десятков - приходится по вполне понятным причинам переходить от тотального распределения нагрузки к выборочной централизации.

[NiTr0]

Это известная тема. NVidia не предоставляет спеки на свои сетевухи и чипсеты, хотя там и нет никакой выдающейся интеллектуальной собственности. Поэтому дрова для Linux написаны в основном при помощи reverse engineering, что и приводит к постоянным паникам.

Насчет сетевух - согласен. Насчет чипсетов - навскидку мне не приходит в голову чипсетоспецифический код (кроме PATA/SATA ессно). Скорее всего тут проблема была как раз в кривой разводке платы или чем-то подобном (благое дело - краши всплывали разные). Но, как говорится, осадок остался.

 

Распараллелить можно все, но когда у Вас этих машин уже несколько десятков - приходится по вполне понятным причинам переходить от тотального распределения нагрузки к выборочной централизации.

Прирост производительности от разгона в 20-30% не является очень существенным; и уж точно не позволит уполовинить кол-во железяк. + ко всему - зависимость нагрузки на процессор от перевариваемого траффика не всегда линейна (к примеру, если мир и IX разнести на 2 разных машины - как минииуи упадет pps и уменьшится кол-во соединений в conntrack; на брасах нагрузка также нелинейно зависит от траффика и кол-ва абонентов).

А вот для всяческих веб-серверов и т.д., где важна пиковая производительность - таки да, выгоднее централизация. А то и сборка пары мощных машин для HA кластера...

[jab]

Прирост производительности от разгона в 20-30% не является очень существенным; и уж точно не позволит уполовинить кол-во железяк.

Я всем на такие заявления говорю одинаково: давайте Вы откажетесь от 20-30% своей зарплаты, тогда я поверю, что это несущественно.

[x86]

Много лет штатно разгоняю дешевые процы на 15-20%. Никаких нештатных ситуаций за весь срок службы. А лохи пусть Xeon'ы покупают, и сидят месяц без прибыли.

Согласен с уважаемым jab. У многих из нашего стада роутеров процессор разогнан на 50% - и ничего, работают.

IMHO, при разгоне становятся важными много факторов - что разгоняется, на чем, питание, охлаждение.

Поэтому, IMHO - AMD, nVidia,Asus,MSI - мимо кассы.

 

Насчет сетевух - согласен. Насчет чипсетов - навскидку мне не приходит в голову чипсетоспецифический код (кроме PATA/SATA ессно). Скорее всего тут проблема была как раз в кривой разводке платы или чем-то подобном (благое дело - краши всплывали разные). Но, как говорится, осадок остался.

Если приходилось смотреть исходники драйвера сетевой платы, то там можно обнаружить массу железо-специфических вещей. И никто их лучше разработчиков самого железа не знает. Вот пример из жизни: Linux-драйвер для чипов Marvell периодически выдает tx transmit timeout, а драйвер от производителя этой проблемы лишен, не говоря уже о том, что его не нужно допиливать напильником для достижения должной производительности.

 

Изменено 4 января, 2011 пользователем x86

[NiTr0]

Я всем на такие заявления говорю одинаково: давайте Вы откажетесь от 20-30% своей зарплаты, тогда я поверю, что это несущественно.

Ваше право. Лично я не вижу целесообразности в увеличении результирующей пропускной способности на 5-7% (см. выше о нелинейности роста нагрузки на проц) ценой вероятного понижения стабильности и повышенного энергопотребления, особенно - в случае топовых процов с максимальным для данного сокета/платы TDP. Как по мне, оптимизация софта/шейпера/ната даст куда больший прирост производительности.

Не говоря уже о том, что процессоры в ходе эксплуатации вполне могут деградировать (тепловая диффузия не спит), при этом - их макс. частота стабильной работы снижается... К примеру, моя десктопная корка 2 8400, поработав пару лет на 4.1ГГц, летом начала виснуть, сейчас - стабильно работает с тем же напряжением только на 3.8ГГц (перегрева нет, проверял - вис при температуре ядер в районе 65 градусов; кондеры на плате - полимерные так что тоже не являются причиной; 90% времени комп работает с мин. нагрузкой - браузер и т.д.).

 

Согласен с уважаемым jab. У многих из нашего стада роутеров процессор разогнан на 50% - и ничего, работают.

У нас на роутерах, которые на агрегацию крупных районов, вообще стоят корки E2160 - со своей задачей справляются, апгрейдить/разгонять точно не будем в ближайшее время. Загрузка процессора - единицы %. Хотя и траффик там ходит не шибко большой - роутеры все больше для локалки, инет через PPPoE.

Кстати, эти же корки пока пользовались с pci сетевухой, имели привычку рандомно вешаться: похоже, ЮМ (ich7 с небольшим радиатором) перегревался - интел однако...

 

IMHO, при разгоне становятся важными много факторов - что разгоняется, на чем, питание, охлаждение.

Поэтому, IMHO - AMD, nVidia,Asus,MSI - мимо кассы.

Угу, а интел всенепременно прекрасно погонится, не смотря на проблемы с его разгоном прямо в этом топике... Фанатизмом однако попахивает.

 

Если приходилось смотреть исходники драйвера сетевой платы, то там можно обнаружить массу железо-специфических вещей.

Ну-ну, покажите-ка мне к примеру в e1000 драйвере хоть что-то, что цепляется за nvidia чипсет.

 

Вот пример из жизни: Linux-драйвер для чипов Marvell периодически выдает tx transmit timeout, а драйвер от производителя этой проблемы лишен

Потому что у него при подвисании трансивера ресет оного происходит тихо и без лишнего шума, в отличие от ядреного драйвера... Не верите - сравните код, благое дело опенсорс. А последний драйвер от марвелла летом у меня стабильно вызывал кернел паник через максимум сутки работы независимо от нагрузки на сеть...

 

[x86]

У нас на роутерах, которые на агрегацию крупных районов, вообще стоят корки E2160 - со своей задачей справляются, апгрейдить/разгонять точно не будем в ближайшее время. Загрузка процессора - единицы %. Хотя и траффик там ходит не шибко большой - роутеры все больше для локалки, инет через PPPoE.

Кстати, эти же корки пока пользовались с pci сетевухой, имели привычку рандомно вешаться: похоже, ЮМ (ich7 с небольшим радиатором) перегревался - интел однако...

Как-то странно у вас - локалки меньше чем инета, неужели совсем юзеры друг у друга не качают?

По поводу перегрева ЮМ - марку материнской платы в студию. И по зависаниям - не забываем про параметры питания и охлаждения.

И если уж поглубже копнуть - не всегда желательно гнаться за новыми версиями ядра и порой не мешает ознакомиться с исходниками драйверов сетевой карты( дабы быть в них уверенным :) ), хотя последнее, скорее для энтузиастов.

И еще относительно Intel, если речь идет об их дескотпных материнках, то это, IMHO, редкое гуано.

Так-что не все попугаи одинаковы...

IMHO, при разгоне становятся важными много факторов - что разгоняется, на чем, питание, охлаждение.

Поэтому, IMHO - AMD, nVidia,Asus,MSI - мимо кассы.

Угу, а интел всенепременно прекрасно погонится, не смотря на проблемы с его разгоном прямо в этом топике... Фанатизмом однако попахивает.

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

 

Если приходилось смотреть исходники драйвера сетевой платы, то там можно обнаружить массу железо-специфических вещей.

Ну-ну, покажите-ка мне к примеру в e1000 драйвере хоть что-то, что цепляется за nvidia чипсет.

Не надо передергивать. Речь шла о драйвере для чипа от nVidia, который отдельно от чипсета в природе не существует. И если уж nVidia так нравиться - можно ознакомиться с netdev относительно проблем/глюков с ихним железом, не говоря уже о том, что HPET так и не могли заставить нормально работать.

А e1000 обязан соответствовать только спецификациям PCI-Express, а уж насколько им соответствует чипсет материнской платы - это отдельный вопрос. И если уж хочется стабильности - то не забываем учитывать на чем и сколько сэкономил производитель материнской платы.

 

Вот пример из жизни: Linux-драйвер для чипов Marvell периодически выдает tx transmit timeout, а драйвер от производителя этой проблемы лишен

Потому что у него при подвисании трансивера ресет оного происходит тихо и без лишнего шума, в отличие от ядреного драйвера... Не верите - сравните код, благое дело опенсорс. А последний драйвер от марвелла летом у меня стабильно вызывал кернел паник через максимум сутки работы независимо от нагрузки на сеть...

Практика - лучший критерий истины.

У вас - паник, а у меня они на бордере работают :)

 

 

[Ainy]

хм.. я за около 20 лет работы разгонял процы только в один период времени - когда "графические станции" собирали на Cyrix M1(где-то в 1992-м чтоли), и то там каждый проц индивидуально разгонялся.

А гонять современные процы, а тем более шину - не вижу никакого смысла - разве что искать себе источник проблем. На всех серверах, какие у меня были, загрузка проца выше 0.9% не поднималась.

Натить абонентов(да еще и на роутере) впрочем никогда в голову не приходило. Когда еще этим занимался, последний трафик был около 6Гбит/с. Сейчас там поболее будет раз в несколько. Но тоже никто не натит.

Зачем LIR-у натить абонентов? Пусть абоненты себе там внутри что хотят, то и натят, это их дело. Шейпера были на кошках и на редбеках. Счас вроде еще 1 линух добавился. Чисто шейпер. 10-ка входа и 10-ка выхода, но это уже после мене было. Потому что там внутри точно не скажу. Вроде дуалксеон квад. А зароутить/зашейпить проходящий мимо гигабит - одного ядра от core i5 как раз обычно хватает с парой интелов на экспрессе. Всякие балансировки прерываний, раскидывания по ядрам итп - звучить просто смешно, когда речь идет про 1 Гбит проходящего трафика. Левые набортные контроллеры понятно не используются в принципе. всякие там аттансики атеросы марвеллы и рилтеки(особенно).

 

[Ivan_83]

Насчет сетевух - согласен. Насчет чипсетов - навскидку мне не приходит в голову чипсетоспецифический код (кроме PATA/SATA ессно). Скорее всего тут проблема была как раз в кривой разводке платы или чем-то подобном (благое дело - краши всплывали разные). Но, как говорится, осадок остался.

Помнится был аппаратный фаер гдето в чипсетах нвидии.

Явно требует специфического отношения в коде.

 

 

Я всем на такие заявления говорю одинаково: давайте Вы откажетесь от 20-30% своей зарплаты, тогда я поверю, что это несущественно.

Если это уменьшит количество решаемых проблемы на 50-60% то запросто.

Там выше к вам вопрос про фаст форвадинг висит без ответа :(

 

 

К примеру, моя десктопная корка 2 8400, поработав пару лет на 4.1ГГц, летом начала виснуть, сейчас - стабильно работает с тем же напряжением только на 3.8ГГц (перегрева нет, проверял - вис при температуре ядер в районе 65 градусов; кондеры на плате - полимерные так что тоже не являются причиной; 90% времени комп работает с мин. нагрузкой - браузер и т.д.).

То что кондёры не изменили геометрических параметров не означает что их электрические характеристики не изменились.

[Ainy]

про фаст форвадинг

могу предположить, что на картах с акселераторами типа LRO, данный режим будет замедлять работу и грузить проц.

 

[jab]

На всех серверах, какие у меня были, загрузка проца выше 0.9% не поднималась.

О да... highload в чистом виде.

 

Если это уменьшит количество решаемых проблемы на 50-60% то запросто.

Там выше к вам вопрос про фаст форвадинг висит без ответа :(

Там не надо думать, там надо сделать и посмотреть. Сам fastforwarding ортогонален net.isr.direct и на современных SMP системах ведет к деградации.

[jab]

Ваше право. Лично я не вижу целесообразности в увеличении результирующей пропускной способности на 5-7% (см. выше о нелинейности роста нагрузки на проц) ценой вероятного понижения стабильности и повышенного энергопотребления, особенно - в случае топовых процов с максимальным для данного сокета/платы TDP.

Я подозреваю, что сами Вы тестов на производительность и энергопотребление не проводили. Мои замеры на Core i7 920 до 15% разгона дают практически линейный рост производительности, Vcore не

увеличивается, температура не растет на боксовом кулере, энергопотребление всей системы изменяется на грани погрешности токовых клещей.

 

Как по мне, оптимизация софта/шейпера/ната даст куда больший прирост производительности.

Думаю что стоимость переписывания одного dummynet значительно дороже всего моего стада писюков и не факт что получатся те же 20%. Про драйвера сетевух и сетевую подсистему ядра я вообще молчу.

[x86]

Как по мне, оптимизация софта/шейпера/ната даст куда больший прирост производительности.

Думаю что стоимость переписывания одного dummynet значительно дороже всего моего стада писюков и не факт что получатся те же 20%. Про драйвера сетевух и сетевую подсистему ядра я вообще молчу.

Позволю заметить, что софт тоже играет немалую роль. Вот потратил пару недель, написал/отладил демон на бордере - нагрузка по pps упала минимум на 20% - и оно того стоило.

Что касается драйверов, то если умеючи :), тоже можно много добиться - на разогнаном десктоптном железе получал ~600к на чистом роутинге.

 

[jab]

Что касается драйверов, то если умеючи :), тоже можно много добиться - на разогнаном десктоптном железе получал ~600к на чистом роутинге.

Да что Вы говорите ? Целых 600kpps ? Все, мне с моим мппсом надо срочно в монастырь уходить.

[x86]

Да что Вы говорите ? Целых 600kpps ? Все, мне с моим мппсом надо срочно в монастырь уходить.

Ни в коей мере не хотел преуменьшить достижения уважаемого jab.

Просто одно дело получить Mpps на серверном железе, и несколько другое - 600к на железе за 150$.

И вообще мысль которую я хотел донести - современное железо( даже дешевое ) способно на многое, просто софт не всегда может выжать с него максимальную производительность.

 

[NiTr0]

Как-то странно у вас - локалки меньше чем инета, неужели совсем юзеры друг у друга не качают?

При ценах на инет в районе $20 дза 100М - таки не качают.

 

По поводу перегрева ЮМ - марку материнской платы в студию. И по зависаниям - не забываем про параметры питания и охлаждения.

Тысячи их, наблюдал и на биостарах, и на асусах, и на прочих - везде, где стоит небольшой рекомендованный интелом рабиатор в виде немного ребристой пластинки. Висы как в серверном применении, так и в десктопном (к прмиеру если на PCI стоит карта видеозахвата на несколько входов, дающая нагрузку на шину близкую к 100%).

 

Не надо передергивать. Речь шла о драйвере для чипа от nVidia, который отдельно от чипсета в природе не существует.

А я говорил, что в данном конкретном случае паника была и без нвидиевской сетевухи.

 

И если уж nVidia так нравиться - можно ознакомиться с netdev относительно проблем/глюков с ихним железом, не говоря уже о том, что HPET так и не могли заставить нормально работать.

У меня на MCP55 (пара forcedeth) бордюр собран, молотит до 600 мбит/с, из замеченых минусов - сеть отваливается при минусовой температуре (было время стоял в неотапливаемом помещении, года 3-4 назад), и не совсем красиво на нем работает шейпер для приоритезации траффика (дабы при всплеске траффика до полки не было неудобств серферам/геймерам).

 

У вас - паник, а у меня они на бордере работают :)

У меня на штатном ядреном драйвере марвелл 8052 на тестовом брасе (на котором обкатываю новые сборки дистра на стабильность) работает, хоть и ругается где-то раз в сутки что повешался ифейс - но это происходит незаметно для юзерленда на 2.6.35, и вызывает максимум секундный лаг. А при попытке в апреле собрать вендор-драйвер на 2.6.32 ядро - поимел краш, и отказался от этой затеи.

Хотя при той цене, что за них отдали в свое время - куда лучше было бы купить какие-то десктопные интелы...

 

Помнится был аппаратный фаер гдето в чипсетах нвидии.

Явно требует специфического отношения в коде.

Не где-то в чипсетах, а в собссно сетевухе. И "аппаратность" его под вопросом еще, что, впрочем, никак не влияет на тот факт что в моем конкеетном случае проблемы были вызваны не forcedeth.

 

То что кондёры не изменили геометрических параметров не означает что их электрические характеристики не изменились.

Я к примеру не слышал что-то о деградации полимерных кондеров... А вы?

 

Я подозреваю, что сами Вы тестов на производительность и энергопотребление не проводили. Мои замеры на Core i7 920 до 15% разгона дают практически линейный рост производительности, Vcore не

увеличивается, температура не растет на боксовом кулере, энергопотребление всей системы изменяется на грани погрешности токовых клещей.

Живой пример: 400 мбит на бордюре - загрузка ядер в районе 20%; 500 мбит - в районе 40-50%; 600 мбит - 85-90%. Т.е. 650 мбит максимум - и полка. Вопрос: на сколько 15% разгон при такой тенденции увеличит полку?