Ваш сценарий жемчуга в середине, вероятно, страдает от буферизации. Попробуйте команды без | /home/Beer/./addtimestamp.pl
. Если это разрешает, что проблема пытается добавить:
$| = 1;
к сценарию жемчуга.
[Edit: Заключительные мысли относительно выбора процессора]
[Изменить: параметр bapm
бесплатного драйвера Radeon установлен по умолчанию для систем Kaveri, Kabini и настольных систем Trinity, Richland начиная с Linux 3.16]
См. [pull] radeon drm-fixes-3.16 .
Однако, что касается Debian на базе 3.16, значения по умолчанию (пока?) Не работают, в то время как параметр загрузки работает. См. Как настроить систему Debian (фокус на 2D или консоль / сервер) с APU AMD Turbo Core для максимальной энергоэффективности и вычислительной эффективности?
[Изменить: бесплатный драйвер Radeon скоро будет иметь параметр bapm
]
Поскольку нижняя строка ниже - это использовать исправленную версию бесплатного radeon
с вашим APU для поддержки Turbo Core и получения от него максимальной отдачи (кроме трехмерной графики), если вы можете (включение bapm
может привести к нестабильности в некоторых конфигурациях), это отличная новость, что в будущих версиях radeon будет параметр для включения bapm .
[Исходное сообщение следует]
Моим первым компьютером был 486DX2-66, собранный из десятков 3,5-дюймовых гибких дисков, содержащих Slackware Таким образом, многое изменилось, и многие отрасли в настоящее время, похоже, находятся в стадии, когда они все еще увеличивают количество вариантов продукта.
Это обстоятельство и некоторые неудачные решения AMD в недавнем прошлом не упростил мне выбор платформы для мини-сервера. Но в конце концов я решил, что A10-6700 будет хорошим выбором:
Несмотря на бесчисленное количество процессоров на выбор, плат Mini-ITX не так много. ASRock FM2A78M-ITX + оказался разумным выбором. Тест проводился с прошивкой V1.30 (на момент написания этой статьи обновлений не было).
Должно потребляться только 80% номинальной мощности источника питания. С другой стороны, многие не могут эффективно работать при нагрузке ниже 50%. Очень сложно найти энергоэффективный источник питания для системы с расчетным диапазоном рассеиваемой мощности от 35 Вт до 120 Вт. Я провел эти тесты с Seasonic G360 80+ Gold, потому что он превосходит большинство конкурентов по эффективности при низких нагрузках.
Два 8 ГБ ОЗУ DDR3-1866 (сконфигурированные как таковые - что действительно имеет значение по сравнению с 1333), один SSD-накопитель и вентилятор ЦП с регулируемым качеством ШИМ также были частью тестовой установки.
Измерения проводились с использованием AVM Fritz! DECT 200, который, как сообщается, выполняет точные измерения. Тем не менее, правдоподобие было подтверждено с использованием более старого безымянного устройства. Несоответствий выявить не удалось. Измеренная рассеиваемая мощность системы будет включать снижение эффективности источника питания при более низких нагрузках.
Экран [W] QHD был подключен через HDMI.
Исходная общая память для графического процессора была установлена на 32 МБ в UEFI BIOS. Кроме того, встроенный графический процессор был выбран в качестве основного и был включен IOMMU.
Ни X, ни другая графическая система не была установлена или настроена. Вывод видео был ограничен консольным режимом.
Есть несколько вещей, которые нужно знать.
/ proc
и / sys
не сообщают об активности Turbo Core. cpufreq-aperf
, cpupower frequency-info
и cpupower monitor
работают, но только после modprobe msr
. Я начал со свежего Arch Linux (установщик 2014.08.01, ядро 3.15.7). Ключевым фактором здесь является наличие acpi_cpufreq
(масштабирование процессора ядра) и radeon
(драйвер графического процессора ядра), а также простой способ обновления radeon
.
UEFI BIOS Turbo Core Setting............................ Enabled UEFI BIOS Cool'n'Quiet Setting.......................... Enabled /sys/devices/system/cpu/cpufreq/boost................... 1 /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... ondemand
"cpupower frequency-info" Pstates........ 4300 4200 3900 3700 3400 2700 2300 1800 Observed "/proc/cpuinfo" cpu MHz range... 1800 - 3700 Observed "cpupower monitor" Freq range... 1800 - 3700 /sys/kernel/debug/dri/0/radeon_pm_info... power level 0
Load | Core Freqs ---------------+----------- stress --cpu 1 | 1 x 3700 stress --cpu 2 | 2 x 3700 stress --cpu 3 | 3 x 3700 stress --cpu 4 | 4 x 3700
UEFI BIOS Turbo Core Setting............................ Enabled UEFI BIOS Cool'n'Quiet Setting.......................... Enabled /sys/devices/system/cpu/cpufreq/boost................... 1 /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... performance
"cpupower frequency-info" Pstates........ 4300 4200 3900 3700 3400 2700 2300 1800 Observed "/proc/cpuinfo" cpu MHz range... 3700 Observed "cpupower monitor" Freq range... 2000 - 3700 /sys/kernel/debug/dri/0/radeon_pm_info... power level 0
Load | Core Freqs ---------------+----------- stress --cpu 1 | 1 x 3700 stress --cpu 2 | 2 x 3700 stress --cpu 3 | 3 x 3700 stress --cpu 4 | 4 x 3700
На основе Turbo Core ускорение невозможно в этом сценарии, потому что драйвер radeon
в настоящее время отключает флаг bapm
из-за проблем со стабильностью в некоторых сценариях . Поэтому дальнейшее тестирование было пропущено.
Чтобы включить bapm
, я начал со свежего Arch Linux (установщик 2014.08.01, ядро 3.15.7), получил пакет core
linux
через ABS
(3.15.8), отредактировал PKGBUILD
, чтобы использовать pkgbase = linux-tc
, вытащил исходники с помощью makepkg --nobuild , изменил pi-> enable_bapm = true;
в trinity_dpm_init ()
в src / linux-3.15 / drivers /gpu/drm/radeon/trinity_dpm.c
и скомпилировал его с помощью makepkg --noextract . Затем я установил его ( pacman -U linux-tc-headers-3.15.8-1-x86_64.pkg.tar.xz и pacman -U linux-tc-3.15.8-1 -x86_64.pkg.tar.xz ) и обновленный GRUB
( grub-mkconfig -o /boot/grub/grub.cfg но, конечно, YMMV).
В результате мне было предложено загрузить linux
или linux-tc
, и следующие тесты относятся к последнему.
UEFI BIOS Turbo Core Setting............................ Enabled UEFI BIOS Cool'n'Quiet Setting.......................... Enabled /sys/devices/system/cpu/cpufreq/boost................... 1 /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... ondemand
"cpupower frequency-info" Pstates........ 4300 4200 3900 3700 3400 2700 2300 1800 Observed "/proc/cpuinfo" cpu MHz range... 1800 - 3700 Observed "cpupower monitor" Freq range... 1800 - 4300 /sys/kernel/debug/dri/0/radeon_pm_info... power level 0
Load | Core Freqs ---------------+----------------- stress --cpu 1 | 1 x 4300 stress --cpu 2 | 2 x 4200 .. 4100 stress --cpu 3 | 3 x 4100 .. 3900 stress --cpu 4 | 4 x 4000 .. 3800
UEFI BIOS Turbo Core Setting............................ Enabled UEFI BIOS Cool'n'Quiet Setting.......................... Enabled /sys/devices/system/cpu/cpufreq/boost................... 1 /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... performace
"cpupower frequency-info" Pstates........ 4300 4200 3900 3700 3400 2700 2300 1800 Observed "/proc/cpuinfo" cpu MHz range... 3700 Observed "cpupower monitor" Freq range... 2000 - 4300 /sys/kernel/debug/dri/0/radeon_pm_info... power level 0
Load | Core Freqs ---------------+----------------- stress --cpu 1 | 1 x 4300 stress --cpu 2 | 2 x 4200 .. 4100 stress --cpu 3 | 3 x 4100 .. 3900 stress --cpu 4 | 4 x 4000 .. 3800
UEFI BIOS Turbo Core Setting............................ Enabled UEFI BIOS Cool'n'Quiet Setting.......................... Enabled /sys/devices/system/cpu/cpufreq/boost................... 0 /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... ondemand
"cpupower frequency-info" Pstates........ 4300 4200 3900 3700 3400 2700 2300 1800 Observed "/proc/cpuinfo" cpu MHz range... 1800 - 3700 Observed "cpupower monitor" Freq range... 1800 - 3700 /sys/kernel/debug/dri/0/radeon_pm_info... power level 1
Load | Core Freqs ---------------+----------- stress --cpu 1 | 1 x 3700 stress --cpu 2 | 2 x 3700 stress --cpu 3 | 3 x 3700 stress --cpu 4 | 4 x 3700
UEFI BIOS Turbo Core Setting............................ Enabled UEFI BIOS Cool'n'Quiet Setting.......................... Enabled /sys/devices/system/cpu/cpufreq/boost................... 0 /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... performace
"cpupower frequency-info" Pstates........ 4300 4200 3900 3700 3400 2700 2300 1800 Observed "/proc/cpuinfo" cpu MHz range... 3700 Observed "cpupower monitor" Freq range... 2000 - 3700 /sys/kernel/debug/dri/0/radeon_pm_info... power level 1
Load | Core Freqs ---------------+----------- stress --cpu 1 | 1 x 3700 stress --cpu 2 | 2 x 3700 stress --cpu 3 | 3 x 3700 stress --cpu 4 | 4 x 3700
UEFI BIOS Turbo Core Setting............................ Disabled UEFI BIOS Cool'n'Quiet Setting.......................... Enabled /sys/devices/system/cpu/cpufreq/boost................... 1 /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... ondemand
"cpupower frequency-info" Pstates........ 4300 4200 3900 3700 3400 2700 2300 1800 Observed "/proc/cpuinfo" cpu MHz range... 1800 - 3700 Observed "cpupower monitor" Freq range... 1800 - 3700 /sys/kernel/debug/dri/0/radeon_pm_info... power level 0
Другими словами, если Turbo Core отключен в BIOS, пропатченный radeon
не включит его.
UEFI BIOS Turbo Core Setting............................ Enabled UEFI BIOS Cool'n'Quiet Setting.......................... Disabled /sys/devices/system/cpu/cpufreq/boost................... n/a /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... n/a
"cpupower frequency-info" Pstates........ 4300 4200 3900 3700 3400 2700 2300 1800 Observed "/proc/cpuinfo" cpu MHz range... 3700 Observed "cpupower monitor" Freq range... 2000 - 4300 /sys/kernel/debug/dri/0/radeon_pm_info... power level 0
Load | Core Freqs ---------------+----------------- stress --cpu 1 | 1 x 4300 stress --cpu 2 | 2 x 4100 .. 4000 stress --cpu 3 | 3 x 4000 .. 3800 stress --cpu 4 | 4 x 3900 .. 3700
При отключенном Cool'n'Qiet ядро Linux не предлагает никакого выбора регулятора и (ошибочно) предполагает, что ядра работают с фиксированным частота. Интересно, что результирующие частоты Turbo Core являются худшими из всех протестированных комбинаций в группе тестовых примеров 2.
Turbo Core работает с исправленным драйвером radeon
. Никаких нестабильностей (которые являются причиной отключения там bapm
aka Turbo Core) до сих пор не наблюдалось.
Я начал с новой установки Ubuntu (14.04 Server, ядро 3.13), которую я считаю сопоставимой с Arch Linux (установщик 2014.08.01, ядро 3.15. 7) из-за наличия acpi_cpufreq
(масштабирование процессора ядра) и radeon
(драйвер графического процессора ядра). Причина перехода на Ubuntu - простая установка fglrx
. Я проверил энергопотребление и поведение на новой установке, использующей radeon
.
Я установил fglrx
из командной строки ( sudo apt-get install linux-headers-generic , sudo apt-get install fglrx ) и перезагрузил система. Переход с radeon
на fglrx
сразу очевиден как в отношении внешнего вида консоли ( fglrx
: 128 x 48, radeon
: намного выше), так и Потребляемая мощность в режиме ожидания ( fglrx
: 40 Вт, radeon
: 30 Вт). Но Turbo Core работает сразу.
UEFI BIOS Turbo Core Setting............................ Enabled UEFI BIOS Cool'n'Quiet Setting.......................... Enabled /sys/devices/system/cpu/cpufreq/boost................... 1 /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... ondemand
"cpupower frequency-info" Pstates........ 4300 4200 3900 3700 3400 2700 2300 1800 Observed "/proc/cpuinfo" cpu MHz range... 1800 - 3700 Observed "cpupower monitor" Freq range... 1800 - 4300 /sys/kernel/debug/dri/0/radeon_pm_info... n/a
Load | Core Freqs ---------------+---------------------------- stress --cpu 1 | 1 x 4300 stress --cpu 2 | 2 x 4200 .. 3900 (core chg) stress --cpu 3 | 3 x 4100 .. 3700 stress --cpu 4 | 4 x 4000 .. 3600
Поведение fglrx
определенно интересно. Когда вызывалось «stress --cpu 2» для любого из тестовых случаев в любой группе тестовых примеров, два загруженных ядра всегда располагались на отдельных модулях. Но с fglrx
произошло внезапное перераспределение, так что использовался единственный модуль (что значительно экономит энергию, см. Ниже). Через некоторое время загруженное ядро переместилось обратно в другой модуль. Этого не было у radeon
. Может быть, fglrx
манипулирует сродством ядра процессов?
Преимущество fglrx
заключается в том, что он сразу включает Turbo Core, без необходимости исправлять его.
Поскольку fglrx
тратит от 10 до 12 Вт для графического процессора в нашем сценарии на чипе с TDP 65 Вт, общие результаты относительно доступных частот ядра не впечатляют. Поэтому дальнейшие испытания не проводились.
Также с инженерной точки зрения поведение fglrx
кажется немного печальным. Перераспределение одного из двух занятых ядер другому модулю для поддержания более высокой частоты может быть, а может и не быть хорошей идеей, потому что до этого шага у обоих ядер был собственный кеш L2, а после этого они должны были совместно использовать один. Учитывает ли fglrx
какие-либо метрики (такие как попадания в кэш) в поддержку своего решения, необходимо уточнить отдельно, но есть и другие отчеты о его резком поведении .
Некоторые дельта-значения в следующей таблице немного ухудшаются при повышении температуры; можно сказать, вентилятор с ШИМ-управлением и чип играют здесь роль.
System @State / ->Transition Delta | System Power Dissipation -------------------------------------+------------------------- @BIOS | @ 95 .. 86W @Bootloader | @108 .. 89W @Ubuntu Installer Idle | @ 40W @Linux radeon Idle ondemand | @ 30W @Linux radeon Idle performance | @ 30W @Linux fglrx Idle ondemand | @ 40W 1 Module 1800 -> 3700 | + 13W 1 Module 1800 -> 4300 | + 25W 1 Core 1800 -> 3700 | + 5W 1 Core 1800 -> 4300 | + 10W "radeon" Video Out -> Disable | - 2W 'fglrx" Video Out -> Darken | +- 0W @Linux radeon Maximum | @103 .. 89W @Linux fglrx Maximum | @105 .. 92W
/ proc / cpuinfo
всегда будет сообщать 37000 МГц под регулятором производительности, cpupower monitor
покажет, что ядра действительно замедляются. В некоторых случаях были показаны частоты до 2000 МГц; возможно, что 1800 МГц также будет использоваться для внутреннего использования. и
набор задач -c 1 напряжение - процессор 1 . radeon
он позволяет получать больше в течение короткого периода и очень плавно снижать до максимума, в то время как с fglrx
было замечено, что эти пределы превышаются более значительно и рассеиваемая мощность затем резко снижается. radeon
. Вероятно, не так много шансов сохранить этот уровень производительности, когда графический процессор получит некоторую работу. radeon
(если вы не столкнетесь с нестабильностью, особенно в сочетании с включением динамического управления питанием ). В противном случае вы не получите полной отдачи. производительности
- по крайней мере, если ваш APU ведет себя как тот, который протестирован здесь.У вас будет такое же энергопотребление, как и в случае ondemand
, но более быстрое масштабирование частоты и меньшие накладные расходы ядра для принятия решения о масштабировании. Особая благодарность Алексу Дойчеру, который значительно подтолкнул меня в правильном направлении на bugzilla.kernel.org .
Я впечатлен качеством бесплатного драйвера radeon
и хотел бы поблагодарить всю команду за поддержку этого программного обеспечения, которое, похоже, было продумано до мелочей. Если бы radeon
не вел себя так, то мое решение в пользу A10-6700 было бы в значительной степени неправильным.