Taktowanie Raspberry Pi: governor CPU a dławienie oraz co raportuje vcgencmd get_throttled

Management Summary
Raspberry Pi zmienia szybkość procesora odpowiednio do obciążenia, oszczędzając energię. Może również zwolnić ochronnie przy niewystarczającym chłodzeniu lub zasilaniu. Niska częstotliwość ma więc różne przyczyny. Artykuł wyjaśnia, jak obciążenie, temperatura i ostrzeżenia zasilania pomagają odróżnić normalne działanie od problemu. Ma to znaczenie przy wolnym serwerze domowym lub automatyce, ponieważ ustawienie maksymalnej wydajności nie naprawia zasilacza ani chłodzenia.
Spis treści
Taktowanie procesora Raspberry Pi poniżej wartości nominalnej nie oznacza automatycznie awarii. Regulator CPU, czyli governor, może żądać niższej częstotliwości przy małym obciążeniu. Na wynik wpływają również limity temperatury, zbyt niskie napięcie zasilania i skonfigurowane ograniczenia częstotliwości. Sam odczyt taktowania nie wskazuje przyczyny.
Regulator, limity i rzeczywista częstotliwość
Linux CPUFreq łączy politykę częstotliwości, regulator i sterownik sprzętu. Regulator wybiera żądany poziom wydajności w ustalonych granicach; sprzęt nie musi osiągnąć dokładnie tej częstotliwości. Aktywny regulator i dostępne stopnie zależą od płytki, systemu, jądra i konfiguracji. Ani ondemand, ani dziesięć stopni od 600 do 1500 MHz nie stanowi uniwersalnego ustawienia Raspberry Pi.
scaling_cur_freq często pokazuje ostatnią żądaną częstotliwość zamiast dokładnego pomiaru sprzętowego. vcgencmd measure_clock arm podaje taktowanie rdzeni Arm w hercach. Porównanie wymaga uwzględnienia jednostek oraz odstępu czasu między odczytami.

Status razem z taktowaniem
Poniższe polecenia wyłącznie odczytują informacje w systemie Raspberry Pi udostępniającym vcgencmd oraz CPUFreq policy0. Brak polecenia lub pliku oznacza niedostępny interfejs, a nie prawidłowy stan sprzętu:
vcgencmd get_throttled
vcgencmd measure_clock arm
vcgencmd measure_temp
cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
cat /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq
cat /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq
Limity CPUFreq są podane w kilohercach; dzielenie przez 1000 daje megaherce. Wynik measure_clock jest w hercach; dzielenie przez 1 000 000 daje megaherce. measure_temp podaje temperaturę SoC. Polecenia wykonują się kolejno, więc odczyty opisują nieco różne chwile.
Seria odczytów podczas obciążenia wywołującego spowolnienie jest bardziej użyteczna niż pojedyncza próbka w spoczynku. Znaczniki czasu, model płytki, wersje oprogramowania i czas od startu ułatwiają porównanie obserwacji. Zebranie tych danych nie wymaga zmiany regulatora ani testu przeciążeniowego.
Osiem udokumentowanych bitów
vcgencmd get_throttled zwraca szesnastkową maskę bitową: liczbę łączącą kilka wskaźników stanu typu tak/nie. Każdy ustawiony bit sygnalizuje określony stan; wartość nie jest pomiarem napięcia ani oceną wydajności.
| Stan | Bieżący bit / maska | Historyczny bit / maska |
|---|---|---|
| Niedostateczne napięcie | 0 / 0x1 |
16 / 0x10000 |
| Ograniczenie taktowania Arm | 1 / 0x2 |
17 / 0x20000 |
| Dławienie | 2 / 0x4 |
18 / 0x40000 |
| Miękki limit temperatury | 3 / 0x8 |
19 / 0x80000 |
Cztery wyższe znaczniki zapisują wystąpienie zdarzenia, zwykle od startu, bez czasu, długości ani liczby zdarzeń. Restart rozpoczyna nowy okres obserwacji. Historyczne znaczniki niedostatecznego napięcia i dławienia nie dowodzą jednoczesnego wystąpienia obu zjawisk.
Trzy przykłady, różne wnioski
0x0: brak zgłoszenia któregokolwiek z udokumentowanych stanów bieżących lub historycznych. Niska częstotliwość nadal może wynikać z regulatora albo limitów konfiguracji. Zero nie stanowi pełnego potwierdzenia sprawności sprzętu.0x50000: ustawione bity 16 i 18. Wystąpiły niedostateczne napięcie i dławienie; żaden z czterech bieżących znaczników nie jest ustawiony. Sama maska nie identyfikuje uszkodzonego zasilacza.0x50005: ustawione bity 0, 2, 16 i 18. Niedostateczne napięcie i dławienie są zgłaszane także w chwili odczytu.
Umowny przykład 600 MHz obok 0x0 pasuje więc do normalnej regulacji częstotliwości, ale nie dowodzi takiej przyczyny. Brakujący kontekst tworzą regulator, limity polityki i obciążenie.

Temperatura i zasilanie wymagają osobnych danych
Miękki limit temperatury zależy od modelu: udokumentowane ustawienie temp_soft_limit dotyczy Raspberry Pi 3A+/3B+. Ten próg nie jest ogólną regułą dla Pi 4 ani Pi 5. Dobór chłodzenia powinien uwzględniać dokumentację modelu i temperaturę podczas odpowiedniego obciążenia.
Niedostateczne napięcie może wiązać się z zasilaczem, kablem, złączami lub podłączonymi urządzeniami. Liczy się napięcie docierające do płytki. Oficjalny zasilacz Pi 4/400 ma parametry 5,1 V i 3 A; inne modele mają inne wymagania. Sam napis 5 V nie potwierdza ani przydatności, ani usterki.
Sterownik Linuksa raspberrypi-hwmon okresowo sprawdza właściwość firmware dotyczącą niedostatecznego napięcia. Ten interfejs nie jest ciągłym precyzyjnym woltomierzem. Komunikaty jądra mogą dostarczać dodatkowych wskazówek, ale pusty dziennik nie wyklucza krótkich zdarzeń, braku obsługi sterownika ani niedostępnej historii wpisów.
Pytania i odpowiedzi
Czy performance zapobiega dławieniu?
Nie. Regulator performance żąda najwyższej częstotliwości dozwolonej przez scaling_max_freq. Ochrona firmware i ograniczenia sprzętu nadal obowiązują. Żądanie nie gwarantuje stale wysokiej zmierzonej częstotliwości, a zmiana regulatora nie naprawia problemu z zasilaniem lub chłodzeniem.
Czy zero po długim czasie pracy rozstrzyga sprawę?
Dłuższy okres obserwacji daje więcej kontekstu, ale tylko dla stanów udostępnianych przez ten interfejs. Nadal możliwe są nieobsługiwane błędy, niezarejestrowane zdarzenia i ograniczenia wydajności poza tymi znacznikami.
Czy status wskazuje uszkodzony element?
Nie. Znaczniki określają kierunek dalszego sprawdzania. Powiązane obserwacje taktowania, temperatury i obciążenia oraz kontrolowane sprawdzenie zasilania i chłodzenia pomagają zawęzić przyczynę.