Moim celem jest skonfigurowanie mini serwera (nie HTPC) o niskim zużyciu energii w trybie bezczynności, ale oferującego niezłą wydajność, gdy jest używany. Nacisk kładziony jest bardziej na bezpieczeństwo danych niż dostępność. Innymi słowy: części wysokiej jakości, ale redundancja tylko do przechowywania.

Nie sądząc, że jestem stronniczy, po przeprowadzeniu niektórych badań poczułem, że niektóre APU dla komputerów stacjonarnych AMD oferują dobrą wartość.

Pozostałe pytania to:

• Czy stan bezczynności GPU obniży zużycie energii i uwolni zasoby procesora?
• Czy Cool'n'Quiet i Turbo Core doprowadzą do zamierzonego niskiego zużycia energii w trybie jałowym, ale wydajności pod obciążeniem?
• Czy Linux będzie obsługiwał ten scenariusz zgodnie z przeznaczeniem? Sporo pytań i dyskusji na forum sugeruje, że niekoniecznie tak jest.

[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 bapmjest 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ł bapmparametr]

Ponieważ podstawową kwestią poniżej jest użycie poprawionej wersji darmowego radeonsterownika z APU do obsługi Turbo Core i maksymalnego wykorzystania (z wyjątkiem grafiki 3D), jeśli możesz (włączenie bapmmoż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 /procoraz /sysmiejsc i nie zgłaszają aktywności Turbo Core. cpufreq-aperf, cpupower frequency-infoI cpupower monitorrobić, 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.radeonbapm

Grupa przypadków testowych 2: Linux + łatka bapm radeon

W celu umożliwienia bapmzacząłem ze świeżym Arch Linux (instalatora 2014.08.01 Kernel 3.15.7), dostał mi core linuxpakiet za pośrednictwem ABS(3.15.8), redagował PKGBUILDdo 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 linuxlub 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 radeongo 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 radeonsterownikowi Turbo Core działa. Do bapmtej 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 fglrxz linii poleceń ( sudo apt-get install linux-headers-generic, sudo apt-get install fglrx) i ponownie uruchomiłem system. Zmiana z radeonna fglrxjest natychmiast oczywista zarówno pod względem wyglądu konsoli ( fglrx: 128 x 48,: radeonznacznie 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

fglrxZachowanie 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 fglrxmanipuluje koligacją procesów?

Podsumowanie grupy przypadków testowych 3

Zaletą fglrxjest to, że umożliwia on Turbo Core od razu, bez potrzeby łatania go.

Ponieważ fglrxw 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 fglrxwydaje 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 fglrxrozważ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/cpuinfozawsze zgłasza 37000 MHz pod regulatorem wydajności, cpupower monitorujawnia, ż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 1andtaskset -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 radeonsterownikiem. 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 radeonsterownika (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 performanceskalowania - przynajmniej jeśli APU zachowuje się tak, jak testowany tutaj. Będziesz miał taki sam pobór mocy jak przy ondemandszybszym 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 radeonsterownika i chciałbym podziękować całemu zespołowi za utrzymanie tego oprogramowania, które wydaje się być starannie zaprojektowane. Gdyby radeonnie zachowywał się w ten sposób, moja decyzja na korzyść A10-6700 byłaby zasadniczo błędna.