@Zerocool, я поискал на просторах, на указанном Вами сайте, сходу не смог найти... А для интелов ( i7 ) Вам не встречался план питания специальный? Было бы крайне любопытно попробовать, посмотреть, что именно настроено там..
Собираем PC топовой конфигурации.
- Автор темы fakeitback
- Дата начала
Я полагаю что для того чтобы исключить влияние аудиоинтерфейса, и сравнивать чисто ЦПУ - нам надо наоборот на максимальный буфер ставить карты...
Вот в чем ошибка метода этого
поставил у себя 4096 семплов
Правда есть еще одно ,у меня включен агрессивный достаточно PBO
Вот в чем ошибка метода этого
поставил у себя 4096 семплов
Правда есть еще одно ,у меня включен агрессивный достаточно PBO
У меня на Apollo больше 2048 буфер не ставится.
В этом варианте Total CPU скачет в пределах 11-26%
RT CPU - 24,5%
В этом варианте Total CPU скачет в пределах 11-26%
RT CPU - 24,5%
Артём, это всё равно не даёт понимания полного.
Правильный тест, это когда один Аудио Девайс, Один Тестер, несколько компов на столе - и не смотреть разницу в нагрузках, а включать плагины пока не затрещит. Сравнивать кол-во плагинов.
eokarm
Невнимательно присоединились , у вас асиогард включен )
все должно быть как на этом скриншоте ..
количество ядер вверху физическое , внизу логическое ..
anticipative fx processing - (выключен )
Ну и задержку тогда ставьте большую уже ...как все
ps. У меня с включенным асиогард rt cpu вообще ноль )) а общая 10)
Невнимательно присоединились , у вас асиогард включен )
все должно быть как на этом скриншоте ..
количество ядер вверху физическое , внизу логическое ..
anticipative fx processing - (выключен )
Ну и задержку тогда ставьте большую уже ...как все
ps. У меня с включенным асиогард rt cpu вообще ноль )) а общая 10)
Последнее редактирование:
Что-то очень стеснительно и не полностью...Забыл подсветить - прям под мастер-шиной на скрине, справа
Total CPU - 23.5% (скачет от 19 до 25)
RT CPU - 37.1%
Всего оставил 30 треков с плагинами (в оригинальном тесте 40, убавил для того, чтобы слабый проц справлялся)
Получается 1 трек с 8 плагами - это 3,3%
_____________________________________________
Один и тот же ПК, просто убавил процессору ядрышек для теста
BS 128smpls SR 44.1kHz
Будем разбираться со значением RT CPU
Первый участник 8cpu RT-64%
Удалось добавить лишь 4трека (13.2%) и появился треск
Второй участник 16cpu RT-46%
уже + 16треков (52.8%)
И вот мы выкладываем скриншотики: у одного участника RT - 46%, а у другого 64%
Как будем сравнивать этих красавцев, опираясь лишь на эти циферки?
Вот посчитав абсолютное значение треков с плагинами, вывод сделать уже проще.
_________________________________________________________________________________
Ещё один интересный тест. "Показатели RT CPU при разных буферах"
На этот раз один процессор, и кол-во треков не уменьшал (40 треков с плагинами)
Открываю проект с буфером 128, загрузка RT 67.5% (треска нет) *
поднимаю буфер до 2048, и вижу, что показатель RT спал всего на 3%
Это как так-то вообще?
т.е. При 128smpls RT CPU = 67.5%
При 2048smpls RT CPU = 64.5%
А в действительности при BF 128smpls до появления треска пришлось добавить всего 6 треков, а при BF 2048smpls + 18треков.
Учитывая всё это, никак нельзя сравнивать процессоры опираясь на показатели Perfomance Meter.
Так что все эти скриншотики в теме - 0
Вывод: более менее объективным будет просто считать "попугаев" (добавлять треки с плагинами до появления треска) при одинаковом буфере, желательно НЕ минимальном.
А после посчитать общее кол-во плагинов и проценты подсчитать, если нужно
"За месяц Вася увеличил свой рекорд подтягиваний на 400%, а Коля свой всего на 25%.
Без данных ниже можно подумать, что Коля сильно болел,
Хотя прошлый рекорд Коли составлял 20 подтягиваний, а Васи - одно."
* На буфере 128smpls треск появляется после превышения значения RT CPU 69%
На буфере 2048smpls треск появляется после превышения значения RT CPU 89%
Получается 1 трек с 8 плагами - это 3,3%
_____________________________________________
Один и тот же ПК, просто убавил процессору ядрышек для теста
BS 128smpls SR 44.1kHz
Будем разбираться со значением RT CPU
Первый участник 8cpu RT-64%
Удалось добавить лишь 4трека (13.2%) и появился треск
Второй участник 16cpu RT-46%
уже + 16треков (52.8%)
И вот мы выкладываем скриншотики: у одного участника RT - 46%, а у другого 64%
Как будем сравнивать этих красавцев, опираясь лишь на эти циферки?
Вот посчитав абсолютное значение треков с плагинами, вывод сделать уже проще.
_________________________________________________________________________________
Ещё один интересный тест. "Показатели RT CPU при разных буферах"
На этот раз один процессор, и кол-во треков не уменьшал (40 треков с плагинами)
Открываю проект с буфером 128, загрузка RT 67.5% (треска нет) *
поднимаю буфер до 2048, и вижу, что показатель RT спал всего на 3%
Это как так-то вообще?
т.е. При 128smpls RT CPU = 67.5%
При 2048smpls RT CPU = 64.5%
А в действительности при BF 128smpls до появления треска пришлось добавить всего 6 треков, а при BF 2048smpls + 18треков.
Учитывая всё это, никак нельзя сравнивать процессоры опираясь на показатели Perfomance Meter.
Так что все эти скриншотики в теме - 0
Вывод: более менее объективным будет просто считать "попугаев" (добавлять треки с плагинами до появления треска) при одинаковом буфере, желательно НЕ минимальном.
А после посчитать общее кол-во плагинов и проценты подсчитать, если нужно
"За месяц Вася увеличил свой рекорд подтягиваний на 400%, а Коля свой всего на 25%.
Без данных ниже можно подумать, что Коля сильно болел,
Хотя прошлый рекорд Коли составлял 20 подтягиваний, а Васи - одно."
* На буфере 128smpls треск появляется после превышения значения RT CPU 69%
На буфере 2048smpls треск появляется после превышения значения RT CPU 89%
Можно (нужно) было просто мьют нажать на не используемых треках!
Я об этом уже писал - не замьютированные треки, даже с отключенными плагинами, жрут процессор в любом случаи.
Последнее редактирование:
И об этом я тоже писал. Именно ТАК и устроен и доя этого предназначен тест давбенча.
Но с этим тоже есть проблема потому как разные люди по разному оценивают понятия треск.
Я бы предложил другой критерий - плэй, ресет графики перформенс метра, 10 лупов при том, что левая часть дроби меньше или равна правой (при hold) в RT longest-block:
Вот ЭТОТ параметр объективный.
Последнее редактирование:
А вот это лишний раз объясняет ПОЧЕМУ следует смотреть не на RT CPU, а на левую цифру в дроби RT longest-block.
Тоже об этом много раз писал.
RT CPU - это среднее значение нагрузки, а дропауты (треск) появляется от максимальных выбросов нагрузки АСИО(Коре Аудио). И в левой части дроби ( при hold) мы видим именно максимальное значение нагрузки АСИО (Коре Аудио).
При маленьких буферах АСИО дропауты будут появляться всегда при меньших значениях средней нагрузи RT CPU, потому как разброс между минимальным и максимальным ЗНАЧИТЕЛЬНО больше, чем при больших значениях буфера АСИО.
Тем и хорош тест Dawbench, что позволяет протестировать и CPU и ASIO (Core Audio).
Я пошёл по пути добавления треков с плагинами, я ничего не отключал и не мьютировал. Суть от этого не поменялась.
Зирокулу пришлось 170 треков с плагинами добавить.
И Я вам лайк влепил, но не я продолжил постить скриншоты с perfomance meter и не я начал.
Я как раз предположил необъективность такого подхода... что было потом? Блин... переписывать написанное ранее желания нет.
Я лишь хочу, чтобы мы пришли к более менее объективному тесту, учитывая разные системы.
Поэтому
По прежнему считаем попугаев? Т.е. добавили n количество треков с плагинами, прогнали 10 раз, RT перевалил за значения Longest block, останавливаемся и считаем плаги, правильно понял?
Если перевалил - выключаем один-два плагина, запускаем плей, ресетим значения, ждём 10 лупов - смотрим на левую часть дроби - если число не перевалило за правое значение дроби - публикуем результат.
ну это-то понятно, так и с треском поступал. Такой подход, конечно, более объективен из-за чел. фактора. Но разница небольшая получается, у меня примерно так и выходит. Сейчас ещё раз прогоню.
Ну, так что, может быть составите(опишете) общий стандарт тестирования?
И ЭТО тоже коверкает тест, так как там на каждой дорожке должна быть СВОЯ вавка!
Иначе Рипер играет ОДИН файл и раздаёт его на разные треки как-то через кэш наверное, не знаю...
Aleksandr Oleynik
Саш - "своя вавка " , это - просто нагрузка на жесткий диск , к процессору это не имеет ровным счетом никакого отношения ...
главное плагины ...
Я дублировал дорожки
И все кто делает тест - могут делать так же точно ...
А то скорее всего - ЖД захрипит задолго до процессора ) в случае с реально мощными процессорами ..
И автор теста - кстати тоже говорил на GS - что можно просто дублировать треки ..
Саш - "своя вавка " , это - просто нагрузка на жесткий диск , к процессору это не имеет ровным счетом никакого отношения ...
главное плагины ...
Я дублировал дорожки
И все кто делает тест - могут делать так же точно ...
А то скорее всего - ЖД захрипит задолго до процессора ) в случае с реально мощными процессорами ..
И автор теста - кстати тоже говорил на GS - что можно просто дублировать треки ..
Неа, можешь сам проверить. Я проверил.
Зачем, по твоему, тогда в AUDIO DawBench лежит такое кол-во совершенно одинаковых вавок Sine для каждого трека отдельно?
Aleksandr Oleynik
Я не вижу в этом никакой логики , потому что нам -нужна не сферическая производительность ,
а сравнение , и если все участники сравнения - дублируют дорожки - то получим адекватные результаты
а " в случае" со своей вавкой- на этом тесте мы получим дропауты от жесткого диска задолго до загрузки процессора
значит , этот тест нужно делать уже с более ресурсоемкими плагинами ...
Потому что он как бы старый ..
Или брать другой тест с sga1155 , и там включать оверсемплинг ...на максимум , на всех плагинах
Я не вижу в этом никакой логики , потому что нам -нужна не сферическая производительность ,
а сравнение , и если все участники сравнения - дублируют дорожки - то получим адекватные результаты
а " в случае" со своей вавкой- на этом тесте мы получим дропауты от жесткого диска задолго до загрузки процессора
значит , этот тест нужно делать уже с более ресурсоемкими плагинами ...
Потому что он как бы старый ..
Или брать другой тест с sga1155 , и там включать оверсемплинг ...на максимум , на всех плагинах