[Edytuj: Końcowe przemyślenia dotyczące wyboru procesora]
- AMD vs AMD:
- Richland wykonuje tutaj znacznie lepszą pracę niż Trinity.
- Kaveri nie może konkurować z rozpraszaniem mocy w trybie bezczynności Richlanda (przynajmniej na razie).
- Karta graficzna A10-6700 może być przereklamowana, ale to trochę smutne, że nie będzie zbyt często używana. Niektóre algorytmy mogą być w stanie wykorzystać swoją moc obliczeniową. Nie ma jednak pojęcia, jak wpłynie to na zużycie energii przez procesor.
- Podejrzewam, że A10-6790K to ten sam procesor co A10-6700 z tylko innym zestawem parametrów doładowań Turbo Core. Jeśli to prawda, A10-6790K będzie w stanie zwiększyć częstotliwość i / lub zapewnić wyższe częstotliwości w dłuższej perspektywie ze względu na wyższy TDP. Ale potrzebujesz do tego innego wentylatora procesora (pomyśl o przestrzeni i temperaturze / żywotności).
- AMD A10-6700 vs Intel Core i3-3220:
- A10-6700 ma znacznie więcej mocy GPU, co nie jest tutaj używane.
- I3-3220 ma niższe rozpraszanie mocy w trybie bezczynności.
- Podczas gdy w typowych testach porównawczych i3-3220 jest szybszy do obliczeń, nie widzę, jak jego dwa rdzenie hiperwątkowe byłyby w stanie obsłużyć równoległe żądania (powiedzmy, do bazy danych z interfejsami WWW) tak szybko, jak cztery w pełni wyposażone rdzenie (przynajmniej przy założeniu poważnego buforowania). Nie znalazłem jednak żadnych poważnych punktów odniesienia - tylko niektóre wskazówki.
[Edycja: Parametr darmowego sterownika radeon bapm
jest domyślnie ustawiony dla systemów Kaveri, Kabini i Trinity, Richland na komputery stacjonarne od Linuksa 3.16]
Zobacz [pull] radeon drm-fixes-3.16 .
Jednak w przypadku Debiana opartego na 3.16 wydaje się, że wartości domyślne (jeszcze?) Nie działają, podczas gdy parametr bootowania działa. Zobacz Jak skonfigurować system Debian (koncentrujący się na 2D lub konsoli / serwerze) z APU AMD Turbo Core, aby uzyskać maksymalną energię i wydajność obliczeniową?
[Edytuj: Darmowy sterownik radeon wkrótce będzie miał bapm
parametr]
Ponieważ podstawową kwestią poniżej jest użycie poprawionej wersji darmowego radeon
sterownika z APU do obsługi Turbo Core i maksymalnego wykorzystania (z wyjątkiem grafiki 3D), jeśli możesz (włączenie bapm
może prowadzić do niestabilności w niektórych konfiguracjach ), to dobra wiadomość, że przyszłe wersje radeona będą miały parametr umożliwiający bapm .
[Następuje oryginalny post]
AMD A10-6700 (Richland) APU Experience
Wybór procesora
Mój pierwszy komputer to 486DX2-66 skonfigurowany z dziesiątek 3,5-calowych dyskietek zawierających pakiety źródłowe Slackware. Na razie wiele się zmieniło, a wiele branż wydaje się być w fazie, w której wciąż rośnie liczba wariantów produktu.
Ta okoliczność i niektóre niefortunne decyzje AMD w niedawnej przeszłości nie ułatwiły mi wyboru platformy dla mini-serwera. Ale w końcu zdecydowałem, że A10-6700 będzie dobrym wyborem:
- Kilka recenzji wykazało, że (wciąż powszechnie niedostępny) Kaveri zużywa więcej energii w trybie bezczynności niż Richland lub Trójca
- Przewaga Richland A10-6700 nad Trinity A10-5700 wydaje się być znacząca: niższa najniższa i wyższa najwyższa częstotliwość, bardziej drobnoziarnisty rdzeń turbo (biorąc również pod uwagę temperaturę - całkiem spora zaleta, gdy GPU będzie bezczynny)
- Mówi się, że GPU A10-6700 jest przereklamowane (nazewnictwo marketingowe), a ceny APU wydają się uczciwe
Inne komponenty i konfiguracja
Pomimo niezliczonych procesorów do wyboru, nie ma wielu dostępnych płyt Mini-ITX. ASRock FM2A78M-ITX + wydawał się być rozsądnym wyborem. Test został przeprowadzony z oprogramowaniem układowym wer. 1.30 (brak aktualizacji podczas pisania).
Należy zużywać tylko 80% nominalnej mocy wyjściowej zasilacza. Z drugiej strony wiele nie działa wydajnie poniżej 50% obciążenia. Bardzo trudno jest znaleźć energooszczędny zasilacz dla systemu o szacowanym zakresie rozpraszania mocy od 35 do 120 W. Przeprowadziłem te testy z Seasonic G360 80+ Gold, ponieważ przewyższa on większość konkurentów pod względem wydajności przy niskich obciążeniach.
Dwie konfiguracje pamięci RAM 8 GB DDR3-1866 (skonfigurowane jako takie - co robi różnicę w porównaniu z 1333), jeden dysk SSD i wentylator procesora jakości PWM również były częścią konfiguracji testowej.
Pomiary zostały wykonane przy użyciu AVM Fritz! DECT 200, który według doniesień wykonuje dokładne pomiary. Jednak wiarygodność została sprawdzona przy użyciu starszego urządzenia bez nazwy. Nie stwierdzono żadnych niespójności. Zmierzone rozproszenie mocy systemu będzie obejmować zmniejszoną wydajność zasilacza przy niższych obciążeniach.
Ekran [W] QHD został podłączony przez HDMI.
Początkowa pamięć współdzielona dla GPU została ustawiona na 32M w BIOS UEFI. Również pokładowy procesor GPU został wybrany jako Podstawowy i włączono IOMMU.
Żaden X lub inny system graficzny nie został zainstalowany ani skonfigurowany. Wyjście wideo było ograniczone do trybu konsoli.
Podstawy
Jest kilka rzeczy, które musisz wiedzieć.
- Podczas gdy decyzja o Cool'n'Quiet jest podejmowana przez oprogramowanie poza procesorami, Turbo Core jest decyzją podejmowaną autonomicznie przez dodatkowy mikrokontroler na APU (lub CPU).
- Wiele narzędzi
/proc
oraz /sys
miejsc i nie zgłaszają aktywności Turbo Core. cpufreq-aperf
, cpupower frequency-info
I cpupower monitor
robić, ale dopiero po modprobe msr
.
Grupa przypadków testowych 1: Linux + radeon
Zacząłem od świeżego Arch Linux (instalator 2014.08.01, jądro 3.15.7). Kluczowym czynnikiem jest tutaj obecność acpi_cpufreq
(skalowanie procesora jądra) i radeon
(sterownik GPU jądra) oraz łatwy sposób łatania radeon
.
Przypadek testowy 1.1: BIOS TC włączony - CnQ on / Linux OnDemand - Zwiększenie
UEFI BIOS Turbo Core Setting ............................ Włączone
UEFI BIOS Cool'n'Quiet Setting .......................... Włączone
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... ondemand
„informacje o częstotliwości cpupower” Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Zaobserwowany zakres częstotliwości procesora "/ proc / cpuinfo" ... 1800 - 3700
Obserwowany zakres częstotliwości „monitor cpupower” ... 1800 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... poziom mocy 0
Załaduj | Podstawowe częstotliwości
--------------- + -----------
stres - procesor 1 | 1 x 3700
stres - cpu 2 | 2 x 3700
stres - CPU 3 | 3 x 3700
stres - procesor 4 | 4 x 3700
Przypadek testowy 1.2: BIOS TC włączony - CnQ on / Linux Performance - Zwiększenie
UEFI BIOS Turbo Core Setting ............................ Włączone
UEFI BIOS Cool'n'Quiet Setting .......................... Włączone
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... wydajność
„informacje o częstotliwości cpupower” Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Obserwowany zakres częstotliwości procesora "/ proc / cpuinfo" ... 3700
Obserwowany zakres częstotliwości „monitor cpupower” ... 2000 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... poziom mocy 0
Załaduj | Podstawowe częstotliwości
--------------- + -----------
stres - procesor 1 | 1 x 3700
stres - cpu 2 | 2 x 3700
stres - CPU 3 | 3 x 3700
stres - procesor 4 | 4 x 3700
Podsumowanie grupy przypadków testowych 1
Podstawowe Turbo zwiększa oparte są niemożliwe w tym scenariuszu, ponieważ kierowca obecnie wyłącza flagę z powodu problemów ze stabilnością w niektórych scenariuszach . Dlatego dalsze testy zostały pominięte.radeon
bapm
Grupa przypadków testowych 2: Linux + łatka bapm radeon
W celu umożliwienia bapm
zacząłem ze świeżym Arch Linux (instalatora 2014.08.01 Kernel 3.15.7), dostał mi core
linux
pakiet za pośrednictwem ABS
(3.15.8), redagował PKGBUILD
do użytku pkgbase=linux-tc
, wyciągnął ze źródła makepkg --nobuild, zmienił pi->enable_bapm = true;
się trinity_dpm_init()
w src/linux-3.15/drivers/gpu/drm/radeon/trinity_dpm.c
, i skompilowałem to z makepkg --noextract. Następnie zainstalowałem go ( pacman -U linux-tc-headers-3.15.8-1-x86_64.pkg.tar.xzi pacman -U linux-tc-3.15.8-1-x86_64.pkg.tar.xz) i zaktualizowałem GRUB
( grub-mkconfig -o /boot/grub/grub.cfgale oczywiście YMMV).
W rezultacie otrzymałem wybór uruchomienia linux
lub linux-tc
, a poniższe testy odnoszą się do tego drugiego.
Przypadek testowy 2.1: BIOS TC włączony - CnQ on / Linux OnDemand - Zwiększenie
UEFI BIOS Turbo Core Setting ............................ Włączone
UEFI BIOS Cool'n'Quiet Setting .......................... Włączone
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... ondemand
„informacje o częstotliwości cpupower” Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Zaobserwowany zakres częstotliwości procesora "/ proc / cpuinfo" ... 1800 - 3700
Zaobserwowany zakres częstotliwości „monitor cpupower” ... 1800 - 4300
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... poziom mocy 0
Załaduj | Podstawowe częstotliwości
--------------- + -----------------
stres - procesor 1 | 1 x 4300
stres - cpu 2 | 2 x 4200 .. 4100
stres - CPU 3 | 3 x 4100 .. 3900
stres - procesor 4 | 4 x 4000 .. 3800
Przypadek testowy 2.2: BIOS TC włączony - CnQ on / Linux Performance - Zwiększenie
UEFI BIOS Turbo Core Setting ............................ Włączone
UEFI BIOS Cool'n'Quiet Setting .......................... Włączone
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... performace
„informacje o częstotliwości cpupower” Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Obserwowany zakres częstotliwości procesora "/ proc / cpuinfo" ... 3700
Obserwowany zakres częstotliwości „monitor cpupower” ... 2000 - 4300
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... poziom mocy 0
Załaduj | Podstawowe częstotliwości
--------------- + -----------------
stres - procesor 1 | 1 x 4300
stres - cpu 2 | 2 x 4200 .. 4100
stres - CPU 3 | 3 x 4100 .. 3900
stres - procesor 4 | 4 x 4000 .. 3800
Przypadek testowy 2.3: BIOS TC włączony - CnQ on / Linux OnDemand - Bez wzmocnienia
UEFI BIOS Turbo Core Setting ............................ Włączone
UEFI BIOS Cool'n'Quiet Setting .......................... Włączone
/ sys / devices / system / cpu / cpufreq / boost ................... 0
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... ondemand
„informacje o częstotliwości cpupower” Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Zaobserwowany zakres częstotliwości procesora "/ proc / cpuinfo" ... 1800 - 3700
Obserwowany zakres częstotliwości „monitor cpupower” ... 1800 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... poziom mocy 1
Załaduj | Podstawowe częstotliwości
--------------- + -----------
stres - procesor 1 | 1 x 3700
stres - cpu 2 | 2 x 3700
stres - CPU 3 | 3 x 3700
stres - procesor 4 | 4 x 3700
Przypadek testowy 2.4: BIOS TC włączony - CnQ włączony / Linux - Bez wzmocnienia
UEFI BIOS Turbo Core Setting ............................ Włączone
UEFI BIOS Cool'n'Quiet Setting .......................... Włączone
/ sys / devices / system / cpu / cpufreq / boost ................... 0
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... performace
„informacje o częstotliwości cpupower” Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Obserwowany zakres częstotliwości procesora "/ proc / cpuinfo" ... 3700
Obserwowany zakres częstotliwości „monitor cpupower” ... 2000 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... poziom mocy 1
Załaduj | Podstawowe częstotliwości
--------------- + -----------
stres - procesor 1 | 1 x 3700
stres - cpu 2 | 2 x 3700
stres - CPU 3 | 3 x 3700
stres - procesor 4 | 4 x 3700
Przypadek testowy 2.5: BIOS TC wyłączony - CnQ włączony / Linux OnDemand - Zwiększenie
UEFI BIOS Turbo Core Setting ............................ Wyłączone
UEFI BIOS Cool'n'Quiet Setting .......................... Włączone
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... ondemand
„informacje o częstotliwości cpupower” Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Zaobserwowany zakres częstotliwości procesora "/ proc / cpuinfo" ... 1800 - 3700
Obserwowany zakres częstotliwości „monitor cpupower” ... 1800 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... poziom mocy 0
Innymi słowy, jeśli Turbo Core jest wyłączony w BIOSie, łata radeon
go nie włącza.
Przypadek testowy 2.6: BIOS TC włączony - CnQ wyłączony / Linux nie dotyczy
UEFI BIOS Turbo Core Setting ............................ Włączone
UEFI BIOS Cool'n'Quiet Setting .......................... Wyłączone
/ sys / devices / system / cpu / cpufreq / boost ................... nie dotyczy
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... nie dotyczy
„informacje o częstotliwości cpupower” Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Obserwowany zakres częstotliwości procesora "/ proc / cpuinfo" ... 3700
Obserwowany zakres częstotliwości „monitor cpupower” ... 2000 - 4300
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... poziom mocy 0
Załaduj | Podstawowe częstotliwości
--------------- + -----------------
stres - procesor 1 | 1 x 4300
stres - cpu 2 | 2 x 4100 .. 4000
stres - CPU 3 | 3 x 4000 .. 3800
stres - procesor 4 | 4 x 3900 .. 3700
Po wyłączeniu Cool'n'Qiet jądro Linuksa nie będzie oferowało żadnego wyboru gubernatora i (błędnie) zakłada, że rdzenie pracują ze stałą częstotliwością. Co ciekawe, uzyskane częstotliwości Turbo Core są najgorsze ze wszystkich testowanych kombinacji w grupie przypadków testowych 2.
Podsumowanie grupy przypadków testowych 2
Dzięki poprawionemu radeon
sterownikowi Turbo Core działa. Do bapm
tej pory nie zaobserwowano żadnych niestabilności (które są przyczyną, dla których aka Turbo Core jest tam wyłączony).
Grupa przypadków testowych 3: Linux + fglrx (katalizator)
Zacząłem od nowej instalacji Ubuntu (serwer 14.04, jądro 3.13), którą uważam za porównywalną do Arch Linux (instalator 2014.08.01, jądro 3.15.7) ze względu na obecność acpi_cpufreq
(skalowania procesora jądra) i radeon
(sterownika GPU jądra) ). Powodem przejścia na Ubuntu jest łatwa instalacja fglrx
. Zweryfikowałem zużycie energii i zachowanie w nowej instalacji, która wykorzystuje radeon
.
Zainstalowałem fglrx
z linii poleceń ( sudo apt-get install linux-headers-generic, sudo apt-get install fglrx) i ponownie uruchomiłem system. Zmiana z radeon
na fglrx
jest natychmiast oczywista zarówno pod względem wyglądu konsoli ( fglrx
: 128 x 48,: radeon
znacznie wyższa), jak i zużycia energii w trybie bezczynności ( fglrx
: 40 W radeon
,: 30 W). Ale Turbo Core działa od razu.
Przypadek testowy 3.1: BIOS TC włączony - CnQ on / Linux OnDemand - Zwiększenie
UEFI BIOS Turbo Core Setting ............................ Włączone
UEFI BIOS Cool'n'Quiet Setting .......................... Włączone
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... ondemand
„informacje o częstotliwości cpupower” Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Zaobserwowany zakres częstotliwości procesora "/ proc / cpuinfo" ... 1800 - 3700
Zaobserwowany zakres częstotliwości „monitor cpupower” ... 1800 - 4300
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... nie dotyczy
Załaduj | Podstawowe częstotliwości
--------------- + ----------------------------
stres - procesor 1 | 1 x 4300
stres - cpu 2 | 2 x 4200 .. 3900 (core chg)
stres - CPU 3 | 3 x 4100 .. 3700
stres - procesor 4 | 4 x 4000 .. 3600
fglrx
Zachowanie jest zdecydowanie interesująca. Kiedy wywołano „stres - CPU 2” dla dowolnego przypadku tes w dowolnej grupie przypadków testowych, dwa obciążone rdzenie zawsze znajdowały się w osobnych modułach. Ale z fglrx
, nastąpiło nagłe przeniesienie, tak że użyto jednego modułu (co oszczędza dość energii, patrz poniżej). Po pewnym czasie załadowany rdzeń wrócił do drugiego modułu. Tego nie widać radeon
. Czy to możliwe, że fglrx
manipuluje koligacją procesów?
Podsumowanie grupy przypadków testowych 3
Zaletą fglrx
jest to, że umożliwia on Turbo Core od razu, bez potrzeby łatania go.
Ponieważ fglrx
w naszym scenariuszu zużywa od 10 do 12 W GPU na chipie z 65 W TDP, ogólne wyniki dotyczące dostępnych prędkości rdzenia są imponujące. Dlatego nie przeprowadzono dalszych testów.
Również z technicznego punktu widzenia zachowanie fglrx
wydaje się nieco smutne. Przeniesienie jednego z dwóch zajętych rdzeni do drugiego modułu w celu utrzymania wyższej częstotliwości może, ale nie musi być dobrym pomysłem, ponieważ przed tym krokiem oba rdzenie miały własną pamięć podręczną L2, a następnie muszą je współdzielić. To, czy fglrx
rozważa jakiekolwiek wskaźniki (takie jak pominięcia trafienia do pamięci podręcznej) na poparcie swojej decyzji, będzie musiało zostać wyjaśnione osobno, ale istnieją inne raporty o jego nagłym zachowaniu .
Podsumowanie zużycia energii
Niektóre wartości delta w poniższej tabeli nieco się pogarszają wraz ze wzrostem temperatury; można powiedzieć, że wentylator PWM i układ odgrywają tutaj pewną rolę.
System @ Stan / -> Delta Przejścia | Rozproszenie mocy systemu
------------------------------------- + ------------ -------------
@BIOS | @ 95 .. 86 W.
@ Bootloader | @ 108 .. 89 W.
@Ubuntu Installer Idle | @ 40 W.
@Linux radeon Idle ondemand | @ 30 W.
@Linux radeon Wydajność w stanie bezczynności | @ 30 W.
@Linux fglrx Idle ondemand | @ 40 W.
1 moduł 1800 -> 3700 | + 13 W.
1 moduł 1800 -> 4300 | + 25 W.
1 rdzeń 1800 -> 3700 | + 5 W.
1 rdzeń 1800 -> 4300 | + 10 W.
Wyjście wideo „radeon” -> Wyłącz | - 2 W.
„fglrx” Wyjście wideo -> Przyciemnij | + - 0 W.
@ Linux Radeon Maximum | @ 103 .. 89 W.
@Linux fglrx Maximum | @ 105 .. 92 W.
- Wydaje się, że w Turbo Core (przynajmniej z APU Richland) jest więcej niż oczekiwano: Nie ma zauważalnej różnicy w rozpraszaniu mocy, gdy regulator skalujący „na żądanie” jest na swoim miejscu, w porównaniu z tym, kiedy jest zainstalowany regulator „wydajności”. Althouth
/proc/cpuinfo
zawsze zgłasza 37000 MHz pod regulatorem wydajności, cpupower monitor
ujawnia, że rdzenie faktycznie zwalniają. W niektórych przypadkach pokazano częstotliwości tak niskie, jak 2000 MHz; możliwe, że 1800 MHz będzie również używane wewnętrznie.
- A10-6700 składa się z dwóch modułów z dwoma rdzeniami każdy. Jeśli np. Dwa rdzenie są bezczynne, a dwa rdzenie są zajęte i ulegają przyspieszeniu, zachowanie systemu będzie się różnić w zależności od tego, czy zajęte rdzenie znajdują się w tym samym module, czy nie.
- Przyspieszenie modułu jest bardziej energochłonne niż przyspieszenie rdzenia.
- Pamięć podręczna L2 jest przypisywana na moduł.
- Różnica między rozpraszaniem mocy dwóch rdzeni przyspieszających na tym samym module a na różnych modułach została określona przez zastąpienie stress --cpu 2(co zawsze prowadziło do podziału między dwa moduły) przez .taskset -c 0 stress --cpu 1
and
taskset -c 1 stress --cpu 1
- A10-6700 wydaje się mieć limit całkowitego rozpraszania mocy dla APU (92 W wraz z innymi komponentami), z niewielkim bitem zarezerwowanym dla samego GPU (3 W). Z
radeon
, pozwoli to na więcej przez krótki okres i bardzo płynnie zredukuje do maksimum, natomiast z fglrx
, zaobserwowano, że te granice są znacznie przekraczane, a rozpraszanie mocy jest następnie gwałtownie zmniejszane.
- Podczas gdy wiele osób twierdzi, że opóźnienie w dostępności Kaveri jest zamierzone przez AMD, ponieważ zabiłoby ich obecne APU, błagam, by się różnić. Richland A10 wykazał doskonałe zarządzanie energią, a Kaveri nie może konkurować ze swoim niskim zużyciem energii w stanie bezczynności (złożoność układów Kaveri jest prawie dwa razy większa niż w Richland, więc zajmie to jeden lub dwa etapy rozwoju).
Ogólny wniosek
- Uwzględnienie temperatury w logice Turbo Core (jak opisano dla kroku Trinity -> Richland) wydaje się mieć sens i wydaje się działać dobrze, co widać po zmniejszeniu rozpraszania pwoer w BIOS i Bootloaderze w miarę upływu czasu.
- W przypadku scenariusza Cosole / Server A10-6700 obsługuje 4 rdzenie przy 3700 MHz (3800 MHz z Turbo Core) przez długi czas, przynajmniej ze
radeon
sterownikiem. Prawdopodobnie nie ma dużej szansy na utrzymanie tego poziomu wydajności, gdy procesor graficzny ma trochę pracy.
- Wydaje się, że 65 W TDP może zostać trwale nieznacznie przekroczone przy pełnym obciążeniu, ale trudno powiedzieć, ponieważ zasilacz ma niższą sprawność przy 30 W. Ponieważ istnieją wyraźne oznaki, że brana jest pod uwagę temperatura (zaobserwowano szczytowe rozproszenie mocy prawie 110 W, zanim zaczęto ją zmniejszać do 90 W, a także zgłaszano przez pewien czas 2 rdzenie przy 4300 MHz), inwestowanie w chłodzenie APU może być dobry pomysł. Jednak płyty główne o ograniczonej mocy do 65 W TDP będą w stanie dostarczyć tyle prądu, więc na pewno APU będzie narzucało twardy limit.
- Jeśli zamierzasz korzystać z APU Richland do obliczeń w systemie Linux, zdecydowanie powinieneś użyć poprawionego
radeon
sterownika (jeśli nie napotykasz niestabilności - szczególnie w połączeniu z włączeniem Dynamicznego zarządzania energią). W przeciwnym razie nie otrzymasz pełnej wartości.
- Co dziwne, wydaje się, że najlepszą konfiguracją byłoby włączenie zarówno Turbo Core, jak i Cool'n'Quiet w BIOS-ie, ale następnie wybranie regulatora
performance
skalowania - przynajmniej jeśli APU zachowuje się tak, jak testowany tutaj. Będziesz miał taki sam pobór mocy jak przy ondemand
szybszym skalowaniu częstotliwości i mniejszym obciążeniu jądra, aby podjąć decyzję o skalowaniu.
Podziękowanie
Specjalne podziękowania należą się Alexowi Deucherowi, który znacząco popchnął mnie we właściwym kierunku na bugzilla.kernel.org .
Jestem pod wrażeniem jakości darmowego radeon
sterownika i chciałbym podziękować całemu zespołowi za utrzymanie tego oprogramowania, które wydaje się być starannie zaprojektowane. Gdyby radeon
nie zachowywał się w ten sposób, moja decyzja na korzyść A10-6700 byłaby zasadniczo błędna.