Я про разгон указал в сообщении. Думаю, всем понятно, что с меньшими частотами результат может значительно отличаться.

Блин ну не переваривает WOT АМД процессоры, такой уж движок и с этим ничего не поделаешь.
Может быть в будущем что то изменится и картошка что то сделает.

EVGENIYYY игра вообще чудо-юдо, собственно, как и любая другая древняя mmo движки которых ничего не знают о новом железе, а драйверы видеокарт ничего не знают об этих играх.

3 штуки кроме максимального разгона нечего не меняется, банально на тех частотах и множителе я могу выставить тайминги 1t 9-9-9, стоит поднять на одно деление и привет 2t 10-10-10
(4 планки, с двумя результаты чуть другие но смысл тот же)

XIMERA123, может дело в материнке?

XIMERA123
это МП не любит ваша))
как то уже был спор по поводу множителя и частоты шины.. в итоге одна и та же производительность, при разгоне множителем и шиной.. разницы нет (при одном и том же разгоне CPUNB, HT, RAM)

тайминги сами по себе меняться не могут, если они жестко зафиксированы пользователем..
если могут - то глюк биоса..

у меня 4 матери под am+

а кто говорил что разница должна быть? я говорю о стабильности системы в целом.

у меня все тайминги вручную, и мы вроде на сайте оверов должно быть понятно о бсоде.

XIMERA123

а это я к слову добавил.. раз уж речь зашла о шине выше 250 и т.п... хоть 300 - если МП не полное "Г" - она это стерпит и никаких падений в стабильности (а от сюда и в производительности) не будет, ведь не всегда бывает БСОД -
бсод - это уже явные проблемы и критическая ошибка, бывают и скрытые : падение частот, пропуск тактов, просто ошибки - не критические


ну тогда должны знать - что и охлаждение так же должно быть нормальным
чтобы при 4Ггц уже тротлинг не начинался


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

выражайтесь так чтобы было понятно о чем идет речь а не связывайте несколько страниц текста и свое воображение



хрустальный шар чтоль заказать себе? откуда должно быть понятно, из следующего? ->


из этого я могу сделать вывод только один - тайминги чудесным образом сами превращаются из 1t 9-9-9 в 2t 10-10-10 после того как вы что то поднимаете на одно деление(наверное множитель, х.з. история умалчивает)

не понятно? тогда нечего писать.
чудесным образом при разгоне до 4000Мгц множителем, я такие тайминги выставить не могу, ибо привет бсод на загрузки windows.
не понятно? тогда вам лучше не гнать систему учите матчасть.



фантазия прет только от вас

XIMERA123

учите)) не можете - не беритесь, на 4х МП и 3х CPU не могли - я вас поздравляю ) тут и добавить нечего

а еще пишите всем что якобы CPU AMD FX не дружит с шиной больше 250.. бред ведь



в обоих ваших постах - виноват CPU, что явно не так..

cannibal_pro зашел в профиль и о чудо увидел тесты в linX c ошибками гуру разгона.

что бы у меня тоже

спасибо, такого счастья не надо, я конечно могу поставить 4700 Мгц, и мамка с охлаждением позволяют, вот только толку с этого 0, (в играх минимальный фпс еще и упадет)
мне хватает и этого.
#77

XIMERA123 ну вам хватит - это тоже хорошо, я ж не говорю что мало)
у каждого свой потолок и потребности


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

нет, фпс именно упадет, да средний и максимальный подрастет, но минимальный вообще улетит в дно, и дело не в частотах, а в коррекции ошибок который достаточно агрессивен и достался нам от серверных опертронов.
я уже переболел разгоном на этой системе и сотню раз все протестировал, касательно буля не скажу, (а также новых на 9xxx,) но fx 83xx ведут себя одинаково
тоже самое касается apu, особо радуют разгонялщики gpu до предела и играющие с фпсом меньшим чем в номинале.

XIMERA123 буль от вишеры не отличается этим..
и не ясно какие ошибки корректируются...
например в серверных платформах ошибки корректируются в RAM - ECC .. тут же используется обычно память без коррекции ошибок..
так что ошибки пролетают так же, и отказоустойчивость соответственно обычная (нежели с памятью ECC)

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

тоже самое только защита от ошибок в памяти.

XIMERA123 коррекция - это исправление, и если бы она была - как раз таки на моем скрине ошибок бы не было)
вся информация оперируется в памяти! - именно там и исправляется
если память без ECC - то исправлений нет, ошибка выводится в таком виде в каком есть - как в моем случае
только ошибка может быть критической , а может и не быть таковой
и еще раз - это тестовая версия линпака - мне на это уже указывали(на платформе intel), т.к. с этой оболочкой плохо дружит(как бы говорили что оболочка пропускает ошибки, считая цикл пройденным успешно)
при запуске без оболочки - таких проблем нет, и результаты совпадают)

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

XIMERA123 все верно делает перерасчет - результаты в ГФЛ должны были бы различаться(как и время прохода).. в результате невязка бы была везде одинаковая ..
но невязка разная - корректировка не работает в данном случае, и если бы это было в обычной версии линпака- то LinX показал бы ошибку и остановил тест..


коррекции нет у нас. это просто конфликт линпака с оболочкой
как вы выразились - невозможно исправить неверный код!
да и как будут исправляться ошибки если память без ECC