О разгоне процессоров и его последствиях, разгон на MPx'ах и не только Поделиться Опции

[noph8]

Собственно, опрос выше. Интересны комментарии проголосовавших за третий и 6 варианты

Если вы всё же решились разгонять, рекомендую ознакомиться с данным постом

Сообщение отредактировал noph8 - 23.3.2009, 17:55

[CkrueL]

Предупреждение от Nosferatos (wce.by)

Последствия разгона OMAP850 (действительно для всех ARM)

За последней месяц ко мне стало попадать довольно много qtek s200 с приблизительно одинаковыми симптомами, а точнее съезжание цветов на дисплее, периодические зависания на бутовой картинке с последующим появлением явно заметных полос на экране. Снятие процессора и его последующая накатка положительных результатов не дали, в ходе "оперативно-исследовательских операций" и SimpleSoft'а был найден предположительный виновник данных багов - разгон процессора.

Немного теории… в этих процессорах есть три шины:

- CPU, fCPUCLK
- Advanced High-performance Bus (AHB), fHCLK
- Advanced Peripheral Bus (APB), fPCLK

так называемая частота fCPUCLK(её частота как правило в 2 раза выше HCLK), fHCLK- (скоростная шина на ней висят видеоадаптер, SDRAM и т.д. ), fPCLK (на ней висят USB, UART\Irda\COM-порты… ). При разгоне мы увеличиваем множитель, который вляет на работу CPUCLK, согласованием работы ядра и шины занимается арбитр, но последствия оверклокинга на него влияют похоже не благоприятно. Плывёт шина HCLK, мы ускоряем работу с SDRAM, за счёт этого получаем прирост производительности, но при этом разгон затрагивает и LCD-контролер ибо он завязан на частоте этой шины, т.е. там стоят щётчики которые высчитывают сколько клоков подать на одну ножку вывода сколько на другую. При поднятии частоты шины диаграмма работы этих выводов измениться и контроллер будет работать в режиме с не корректной временной зависимостью… но даже при этом "сгореть" он не может, при каких либо багах достаточно вернуть частоту на место. Проблема вероятней всего в самой шине, что-то изменяется в её диаграмме работы поэтому перестают правильно захватываться пиксель-блоки или плывёт синхронизация. Также на некоторых аппаратах пропадает Wi-Fi (он тоже сидит на HCLK) был случай с "исчезнувшим" радиомодулем.
Итак, советую сильно задуматься любителям разгона OMAP, ибо этот высокоинтегрированый проц, явно не заточен под разгон, разработчики ставили во главу угла стоимость и энергопотребление. Имхо, временный разгон врят ли может привести к плачевным последствиям, а вот постоянный разгон при помощи, например, BatteryStatus или OmapClock вполне может уложить аппарат. Не следует забывать что даже процессоры из одной партии не идентичны, погрешность при производстве такова, что один экземпляр может работать годами второй ляжет через неделю.
Одинаковые кристаллы с разными ревизиями ведут себя при оверклокинге по разному.


intruders:

В общем-то Nosferatos правильно всё сказал - разгон OMAP процессоров затрагивает все его блоки. Это связано с тем, что они используют общую частоту, генерируемую из 12Мгц (или 13МГц) задающего тактогенератора путём её умножения и деления (некоторые блоки используют сразу частоту задающего тактогенератора). Эта частота является максимальной для блоков (именно её значение регулирует OmapClock). Но, понятное дело, не всем блокам нужна высокая частота, поэтому большинство блоков имеет делитель частоты (1/2/4/8 ).

Поскольку блоки имеют только делители частоты (множителей нет), то для разгона ARM процессора приходится поднимать общую частоту OMAP процессора. Что и приводит к последствиям.

Сам ARM процессор в нормальном режиме имеет делитель 1, а в спящем режиме 2 (как правило) - для энергосбережения.

В идеале, программа для разгона OMAP процессоров должна позволять устанавливать помимо частоты ещё и делители для отдельных блоков, но таких делителей около дюжины, и человеку, чтобы воспользоваться такой программой, придётся изучить систему частотогенерации в процессоре.

Об этой особенности OMAP процессоров уже вроде как говорили вскоре после выпуска OmapClock, но, видимо, народ подзабыл.

В общем хотелось бы напомнить ещё раз всем: не увлекайтесь экстремальным разгоном.

Источник: http://forum.wce.by/viewtopic.php?p=113766#p113766


Kirgston ,
в последних версиях прошивок на мрх200 с увеличенной частотой процессора, увеличение частоты заданно в ядре ОС, а не программой OmapClock.

Сообщение отредактировал CkrueL - 1.12.2008, 15:26

[Kirgston]

noph8,
Ой ... извините. Тоисть я покупатель =) . Просто уже второй покупатель после допроса про телефон пропадает или говорит "уже продано" )))
CkrueL,
Ай... честно глупо... скорее всего вы не знакомы с Асм и низким уровнем и электроникой. Самое интересное то что год назад я её еле учил. Я её проклинал и т.д. а теперь ей благодарен за то что её щас знаю =) . Вобщем всё не так. Это более характерно для высокого уровня, но не для низкого и для самого низкого (транзисторы и т.д.) . Вобщем сама по себе микросхема (а таких в процессоре миллиарды...) имеет свое напряжение и т.д. Всё сделано на микросхемах Алгебры-логики. Не буду вникать в суть. Будет вам интересно - почитаете . Так вот. Для каждой микросхемы характерна частота (Мгц) и оптимальное напряжение при каком будет максимальный эффект. Теперь представим что таких микросхем миллиарды о они сочитают вместе ЦПУ . Вопрос к разгонщикам. Ну и как вы измените характеристики микросхемы?! Впаяете туда чтото??? ИМХО нет и никак! Люди которые пишут дрова к платам это прекрасно понимают. Иначе бы Асус, Гигабайт и т.д. сами бы разгоняли... чем им то плохо?! Быстрее разгонишь - больше прибыли получишь. И разгон это имхо глупо (лично моя позиция и я никого не принуждаю ей пользоваться). Аргументирую. Разогнать микросхему просто нельзя. Чтоб сделать быстрее саму микросхему надо её делать с нуля и впаивать в процессор. Я щитаю что разгоняют те люди которые не знают грубой логики. Когда человек программирует он только максимум распределяет приоритеты. Да есть такая штука как SMOD в 2 раза увеличение передачи данных. Но логично откуда ? Значит тратятся другие ресурсы. Но это не болезненно. Но. Когда вы так сказать разгоняете ЦПУ через систему - вы меняете только приоритеты. Система быстрее работать не БУДЕТ! Кто такое сказал что быстрее? Где тесты? Где гарантия что система будет быстрее работать везде. Вот ответ... гарантий никаких нету. Кто вам сказал что вы разогнали? Винда ? Наврала она вам... она лишь пишет только то что вы ей скажите... так вот. Изменяя приоритеты вы убиваете этим другую ветвь процессов. Ну да например ява начали бегать быстрее. Где гарантии что уровень сигнала не упадет? Какие гарантии что видео не стало глючить? Поймите ничего не берется с воздуха. И если есть "+" значит есть и "-" просто вы его не видете. Это только обман самого себя. Четкий пример. Когда пользователь нажал кнопку внутренний таймер щитает начало и конец импульса. Вы нагружаете ЦПУ другим делом и таймер чуток пересчитал. В итоге система что то подсчитает не так и что то произойдет такое что не должно. Ето если программа была написана на чистом асм. Но никто ВМ не писал на асм! На С++... а значит риск не просто удваивается а возростает в раз 100. И это вам не компютер где выход на 220в и вам повезет если резистор и т.д. будет работать с лучшим напряжением. А тут телефон... входной поток энергии ограничен... Вобщем сказал что думал. Ваше право думать и делать как вы хотите и т.д. и это чисто мое личное мнение.

З.Ы. Программы для разгона ЦПУ - бред...

[BAHEC]

проголосовал за 3 вариант, потому что нет необходимости для меня в разгоне, на стареньком мпх200 делал наоборот все: ставил значение на 60 МГц (когда заряд акб подходил к концу, а до зарядника доберусь не скоро), несильно, но продлевал жизьнь телефона (все равно обычно пользуюсь им как телефоном)

[noph8]

Kirgston,
самое интересное, что фильм, на который Вы привели ссылку, никак не отрицает того, что я Вам привёл. Более того, Ваши собственные слова подтверждают мои:

Теперь представим что таких микросхем миллиарды о они сочитают вместе ЦПУ

Вы действительно думаете, что можно впаять ровно 1 млрд микросхем?
Я тут покопался и нашёл статью, с которой я начинал свой путь оверклокера
По поводу "впаяете туда что-то" - если верить Вашим словам, разгон - вообще дело невозможное: либо пан, либо пропал. Но тогда достаточно сложно объяснить миллионы удачных разгонов по всему миру
Ну и для справки - я проголосовал за "Разгон - только для ББ (компьютера)", потому что мои девайсы на WM: MPx220 и Toshiba G900 не особо нуждаются в рагоне: они и так довольно шустрые. Но если бы у меня был MPx200 скорее всего я бы проголосовал за другой вариант. Ну, а на компе лишних мегагерц никогда не бывает

[Honorocker]

Постоянно мой 220 на 240 мгц и жуву и радуюсь , кстати некто не знает как можно класно освободить оперативку , а то я больше 9.5 не могу ((

[flybirdr]

Разгон процессора (в некоторых пределах) не считаю вредным для процессора. Т.к. это всего лишь в большинстве случаев черевато перегревом на 1 - 5 градуса и повышением потребляемой мощности и только. Свою 220 держу на уровне 252 МГц. Пробовал 264 - иногда зависает иногда нормально, т.е. не стабильно. Смысл от разгона есть - и не мне вам рассказывать какой.

[noph8]

flybirdr,
ну почему же? Мне, например, не понятно, зачем его постоянно держать разогнанным? Разогнать его для какой-нибудь игрушки (типа Quake) - пусть я в игры на телефоне не играю, но понимаю. Но в остальных случаях его разгон ничего, кроме большего энергопотребления не принесёт: видео, к примеру, все равно нужно конвертировать. Гораздо более критическим является ограничение оперативной памяти, по-моему.
Honorocker,
больше 11 все равно не освободишь

[flybirdr]

flybirdr,
ну почему же? Мне, например, не понятно, зачем его постоянно держать разогнанным? Разогнать его для какой-нибудь игрушки (типа Quake) - пусть я в игры на телефоне не играю, но понимаю. Но в остальных случаях его разгон ничего, кроме большего энергопотребления не принесёт: видео, к примеру, все равно нужно конвертировать. Гораздо более критическим является ограничение оперативной памяти, по-моему.

Даже просто по менюшкам и то быстрее бегает.

[noph8]

flybirdr,
Хм.. Дак он и так немедленно бегает... Первый раз медленно, затем - очень даже шустро. Это, конечно, если речь о меню "Пуск"