Intel ve Apple Silicon Mac'lerde gerçek CPU sıcaklığını okumak

Size düz bir sayı veren bir Apple API'si yok

Activity Monitor'ü açıp bir CPU Temperature sütunu arayın — yok. Apple, macOS'un hiçbir yerinde yerleşik bir sıcaklık göstergesi sunmadı: ne Activity Monitor'de, ne System Settings'te, ne de herhangi bir genel sıcaklık API'sinde. Bu bir gözden kaçırma değil; Apple sensör verisini kendi termal yönetiminin iç detayı olarak görüyor, uygulamaların doğrudan okuyabileceği bir şey olarak değil.

Size bir sayı gösteren her araç, ücretsiz ya da ücretli, bu boşluğu aynı yoldan dolaşıyor: SMC'ye konuşarak — macOS ile gerçek termal sensörler ve fanlar arasında oturan, her zaman açık küçük denetleyiciye. "CPU sıcaklığını oku" diye bir sistem çağrısı yok; SMC'den dört karakterlik belirli bir sensör anahtarı istiyorsunuz (TC0D veya Tp01 gibi) ve o da nasıl çözeceğinizi bilene kadar hiçbir anlam ifade etmeyen bir avuç ham bayt döndürüyor.

"Mac'imin CPU sıcaklığını nasıl okurum" sorusunun gerçek cevabı bu: bu spesifik Mac için doğru anahtarı seçmek, sonra döndürdüğü baytları bu spesifik çip için doğru formatla çözmek. İki adımdan birini yanlış yaparsanız ya yanlış bir sayı ya da hiç sayı alamazsınız — aynı Mac'teki iki sıcaklık aracının birbiriyle çelişmesinin, bazı okuyucuların yepyeni bir çipte hiçbir şey göstermemesinin nedeni de tam olarak bu.

İki çözücü: Intel'de sp78, Apple Silicon'da IEEE flt

SMC tek bir evrensel sayısal tip döndürmüyor — her anahtarın kendi veri tipi var ve çözücü bununla eşleşmezse sonuç anlamsız çıkar. Sıcaklık anahtarları, Mac'in mimarisine bağlı olarak iki farklı format kullanır.

Intel Mac'lerde sıcaklık sp78 olarak döner: işaretli 8.8 sabit noktalı bir sayı, bir bayt tam derece ve bir bayt kesir. Çözmek basit bir aritmetik işlemi — ilk bayt işaretli tam sayı olarak okunur, ikinci bayt 256'ya bölünüp eklenir. Örneğin 0x31 0x80 baytları 49 + 128/256 = 49.5°C olarak çözülür.

Apple Silicon'da aynı sensör ailesi flt olarak raporlanır: standart 4 baytlık bir IEEE-754 kayan noktalı sayı, sadece normalde beklediğiniz bayt sırası yerine little-endian olarak saklanır. Yazılımın her yerinde kullanılan aynı 32 bitlik float formatı — Apple sadece baytları ters sırayla paketliyor.

Fan RPM'in de kendine ait bir kodlama ayrımı var — eski Intel donanımında sabit noktalı fpe2, modern Intel'de ve her Apple Silicon Mac'te flt — yani yalnızca tek bir çip neslinin sayı formatları için yazılmış bir okuyucu, geçişin diğer tarafındaki donanımı yanlış okur ya da hiç okuyamaz. LidRun, tüm Mac için tek bir format varsaymak yerine, çözmeden önce her anahtarın gerçekte bildirdiği tipi kontrol eder.

Tek bir 'CPU sıcaklığı' anahtarı yok — ve her çiple birlikte yer değiştiriyor

Bir anahtarı çözebilseniz bile, hangi anahtarı isteyeceğinizi bilmeniz gerekir; bu da Mac modeline, Apple Silicon'da ise çip neslinize göre değişir.

Intel Mac'ler nispeten basit: CPU sensörleri TC0x ailesinin altında yaşar — TC0D (die), TC0P (proximity), TC0E ve TC0F (filtrelenmiş/sanal okumalar), TCAD (package) — ve çoğu Intel okuyucusu sadece bu kısa listeyi yoklar.

Apple Silicon bilerek parçalanmış durumda, çünkü çipin tek bir "die"dan çok daha fazla ayrı termal bölgesi var. M1, Tp01, Tp05 ve Tp0D gibi performans-çekirdek anahtarlarını, Tc0a/Tc0b altında yardımcı bir CPU kümesini ve Tg05/Tg0D altında GPU anahtarlarını açığa çıkarır. M2, performans çekirdeklerinin yanına ayrı verimlilik-çekirdek anahtarları (Tp1h, Tp1t) ekler. Ardından M3, adlandırma kuralını tamamen değiştirir: performans-çekirdek ve GPU anahtarları yeni bir Tf önekine taşınır (Tf04, Tf09…) ve verimlilik çekirdekleri kendi Te önekini alır — CPU çekirdekleri için Tp'yi tamamen bırakan nesil budur. M4, performans çekirdekleri için Tp'yi geri getirirken verimlilik için Te'yi korur. M5 ise kendi Tp soneki altında ayrı bir "süper çekirdek" katmanı ekler.

Bir sıcaklık okuyucusunun kusursuz çalışırken bir sonraki aldığınız Mac'te birden hiçbir şey göstermemesinin gerçek nedeni bu: M1/M2 anahtar listesi koda gömülü bir araç, M3'te hiçbir şey okumaz, çünkü aradığı anahtarlar artık orada yok — başka bir harfe taşınmışlar. Bu Mac'inizdeki bir hata değil; yeni çip için güncellenmemiş bir anahtar listesi.

LidRun bunu iki adımlı bir yaklaşımla ele alır: önce bilinen anahtarların statik bir listesini dener (hızlı, zaten tanıdığı Mac'lerde yoklama gerektirmez), hiçbiri bir okuma döndürmezse SMC'nin tüm anahtar tablosunu bir kez tarar — Mac'e göre birkaç yüzden yaklaşık bin anahtara kadar — ve die-sensör önekleri (Tp, Te, Tf, Tg, Tc) altında makul bir sıcaklığa çözülen her şeyi tutar, çipin gerçek sıcaklığını olduğundan düşük gösterecek yüzey, ortam ve pil sensörlerini eler. Sonuç önbelleğe alınır, böylece sonraki sorgular neredeyse hiçbir şeye mal olmaz.

Kendi başınıza kontrol etmenin ücretsiz ve yerleşik yolları

Gerçek bir sayı görmek için LidRun'a ya da herhangi bir ücretli uygulamaya ihtiyacınız yok. Birkaç ücretsiz seçenek var, ancak her birinin güvenmeden önce bilmeye değer gerçek bir sınırı var.

Terminal'in yerleşik pmset -g therm komutu, macOS'un sunduğu bir sıcaklık komutuna en yakın şey — ama çıktısını dikkatli okuyun: yazdırdığı CPU_Speed_Limit satırı bir sıcaklık değil, bir kısıtlama yüzdesidir. 100, çipin hiç sınırlanmadığı anlamına gelir; daha düşük bir sayı, macOS'un ısıyı yönetmek için CPU hızını aktif olarak kıstığı anlamına gelir. Gerçekten faydalı bir "Mac'im şu anda zorlanıyor mu" sinyali ve ücretsiz, yerleşik — ama size asla bir derece okuması göstermez.

Gerçek bir sayı için, yukarıda anlatılan anahtar-ve-çözme işini birebir yapan ücretsiz ve açık kaynaklı SMC okuyucuları var. Stats (exelban/stats), Apple Silicon'un sürüm sürüm değişen anahtar isimlerini takip eden ücretsiz, açık kaynaklı bir menü çubuğu uygulaması. smctemp ve osx-cpu-temp gibi komut satırı araçları, GUI'ye gerek kalmadan Terminal'den aynı çözmeyi yapar (osx-cpu-temp, Apple Silicon'dan önceye ait ve yalnızca Intel'i kapsar).

Ücretli ya da freemium araçlar — iStat Menus, TG Pro, Macs Fan Control — aynı SMC anahtarlarını okur ve üstüne cila ekler: geçmiş grafikleri, uyarılar, TG Pro ve Macs Fan Control'de ise okumanın üzerine fan kontrolü. Hiçbiri Apple'ın herkesten sakladığı bir sayıya erişmiyor; hepsi aynı SMC el sıkışmasını yapıyor, sadece anahtar listesinin arkasında daha fazla bakım ve etrafına sarılmış daha hoş bir arayüz var.

İki uygulamanın neden farklı sayılar gösterdiği

Aynı Mac'te, aynı anda bir araç 68°C, diğeri 74°C diyorsa, ikisinden biri illa yanlış demek değildir. Neredeyse kesinlikle farklı bir sensörü okuyorlar ya da birkaç sensörü tek bir sayıya farklı bir şekilde dönüştürüyorlar.

Diyelim ki bir Mac'in o an 65°C ile 75°C arasında okuma yapan sekiz çekirdek sensörü var. Çekirdeklerin ortalamasını alan bir araç (Stats ve smctemp'in daha dostane bir "anlık CPU sıcaklığı" için kullandığı yaklaşım) 70°C gösterebilir. Belirli bir package sensörünü raporlayan bir araç 72°C gösterebilir. Bulduğu en sıcak canlı sensörü raporlayan bir araç — LidRun'ın yaklaşımı — 75°C gösterir. Üç sayı da aynı silikonun gerçek, dürüst okumaları; sadece biraz farklı sorulara cevap veriyorlar.

Ortalama almak daha pürüzsüz, günlük kullanım için daha temsili bir sayı verir. Maksimumu raporlamak, güvenlikle ilgili herhangi bir şey için daha temkinli seçimdir, çünkü kısıtlama ortalama değil tek bir en sıcak die sensörünün sınırını aşmasıyla tetiklenir — yani sadece bir sayı göstermek yerine geri çekilip çekilmeyeceğine karar veren bir monitörün, ortalama yerine tepe değeri tercih etmesi için gerçek bir nedeni vardır.

Pratikteki ders şu: tek bir CPU sıcaklığını, Mac'inizin tek gerçek değeri olarak değil, bir aracın seçtiği sensörden ve yönteminden gelen bir okuma olarak görün. Gerçekten bir sorun olup olmadığını değerlendirirken önemli olan son birkaç dakikadaki eğilim ve ne kadar yükseldiği — sayınızın bir arkadaşınızın aracıyla derece derece eşleşip eşleşmediği değil.

Tek bir okuyucuya güvenmenin riski

Yukarıdaki çip nesli sorunu varsayımsal değil — zaten gerçek, belgelenmiş arızalara yol açtı. Popüler açık kaynaklı sistem monitörü btop, yalnızca sp78 çözücüsünü uygulayan bir sıcaklık okuyucusuyla çıktı; flt'yi hiç ele almadığı için, düzeltilene kadar her Apple Silicon Mac'te sessizce CPU sıcaklığı göstermedi (proje bunu #1653 numaralı sorun olarak takip etti). Hiçbir şey çökmedi, hiçbir hata görünmedi — sayı sadece eksikti, bu da "bu aracın çözücüsü eksik" değil "Mac'imde sıcaklık sensörü yok" gibi görünüyordu.

Aynı arıza modu sadece eksik çözücüler için değil, eskimiş anahtar listeleri için de geçerli: M3 çıkmadan önce yazılmış ve hiç güncellenmemiş bir okuyucu, M3'te hiçbir şey okumaz, çünkü yokladığı performans-çekirdek anahtarları (Tp01, Tp05…) artık orada yok — bunun yerine Tf04, Tf09 var. Eskimiş bir anahtar listesi ile eksik bir çözücü aynı belirtiyi üretir: aslında olmadığı halde bir donanım sorunu gibi görünen boş ya da sıfır bir okuma.

Okumanın ötesine geçen araçlarla ayrı, daha küçük bir risk var. Macs Fan Control, TG Pro ve smcFanControl, SMC'ye yazabilmek için ayrıcalıklı bir yardımcı daemon kuruyorlar — fan kontrolünün gerçekten gerektirdiği meşru mekanizma bu, çünkü Apple bunun için Developer-ID imzalı, root seviyesinde bir yardımcı istiyor ve daha hafif bir yol yok. Ama bu, artık ikinci bir arka plan sürecinin fanlarınızı manuel bir hedefte tutabilme yeteneğine sahip olduğu anlamına geliyor. Uygulamayı otomatiğe döndürmeden kapatırsanız, o daemon kontrolü macOS'un kendi firmware eğrisine geri vermek yerine son manuel ayarıyla çalışmaya devam edebilir.

Bunların hiçbiri bu araçların güvenilmez olduğu anlamına gelmiyor — Stats, TG Pro ve Macs Fan Control hepsi aktif olarak bakımı yapılan araçlar ve tam destek bazen bir çipin çıkışından bir iki sürüm geride kalsa bile, yeni Apple Silicon nesillerinin peşinden gitmeye devam ediyorlar. Bunun anlamı, bir sıcaklık sayısının ancak arkasındaki anahtar listesi ve çözücü kadar güncel olduğu ve Apple'ın her yeni çip çıkardığı yıl bu listenin gerçek sonuçlarla değiştiği.

Aslında 'çok sıcak' sayılan nedir

Gerçek bir sayınız olduğunda, daha zor soru onunla ne yapacağınız — ve her Mac'te işe yarayan tek bir güvenli eşik yok, çünkü Apple çiplerini sürekli yük altında bilerek termal tavanlarına yakın çalıştırıyor. Bu normal bir çalışma, bir uyarı işareti değil.

M1 çipleri, sürekli ağır yük altında bozulmadan kabaca 100°C kadar sıcak çalışacak şekilde tasarlandı — bu SoC tasarımının istendiği gibi çalışması, bir arıza değil. M2 aynı koşullar altında daha da sıcak çalışıyor, sık sık 100'lerin üzerine çıkıyor. Intel Mac'ler yük altında düzenli olarak 90–100°C aralığında oturur, bu sadece o mimarinin davranış biçimi. Fansız MacBook Air'in geri düşeceği bir fanı hiç yok — ısıyı tamamen kısıtlama yoluyla yönetiyor, yani bir Air'de sürekli 90–100°C okuması normal çalışma aralığıdır, bir şeylerin yanlış gittiğinin kanıtı değil.

Kısıtlamanın kendisi — çipin ısıyı yönetmek için kendi hızını sınırlaması — çoğu güncel Mac'te tipik olarak 95–100°C civarında başlar, bu donanımın kendi korumasının işini yapması, iş yükünüzün bir şeyi bozduğunun işareti değil.

Tek bir "güvenli" derece sayısı modeller arasında geçerli olmadığından, daha faydalı sinyal Apple'ın bunun için gerçekten inşa ettiği nitel sinyaldir: ProcessInfo.thermalState, bir dereceyle değil Mac'inizin ne yapması gerektiğiyle tanımlanan dört seviyeli bir değerlendirme (nominal, fair, serious, critical). Her düzgün davranan uygulamanın tepki vermesi gereken sinyal bu, ve LidRun'ın kendi güvenlik tepkisi de gerçek yük altındaki normal, sağlıklı bir Mac'te yanlışlıkla tetiklenecek sabit bir derece eşiği yerine bunun üzerine kurulu.

LidRun nereye oturuyor

Sıcaklık okuma LidRun'da ücretli bir özellik değil — her kurulum, Intel ve Apple Silicon fark etmeksizin, yukarıda anlatılan aynı anahtar-ve-çözme yaklaşımıyla bunu alır: aktif listedeki en sıcak geçerli anahtar, o anahtar için SMC'nin gerçekte bildirdiğine göre sp78 veya flt ile eşleştirilir.

LidRun'ın bunu okumasının nedeni, ücretsiz araçların zaten yaptığından daha güzel bir gösterge sunmak değil. Amaç, LidRun bir agent çalışması için Mac'inizi uyanık tutarken kendi güvenlik tepkisinin gerçek bir sinyale sahip olması. LidRun'ın temel vaadi basit: agent çalışıyor → uyanık kal; agent bitti ya da güvensiz → bırak, ya da uyu. Bu, ne olursa olsun Mac'i açık tutan kör bir uyanık-tutma kilidi değil — "güvensiz" tarafı öncelikle resmi olarak belgelenmiş sinyal olan thermalState'e dayanır, sayısal sıcaklık ve CPU kısıtlama yüzdesi ikincil bir kontrol olarak destekler. Kritik ısıda, LidRun herhangi bir Mac'te, kapak açık ya da kapalı, uyanık-tutma kilidini her zaman hemen bırakır. Closed-Lid modu açıksa ve kapak gerçekten kapalıysa — ısının gidecek yeri olmadığı durum — sürekli kritik ısı bir bırakmadan gerçek bir uykuya yükselir, çünkü aksi halde Closed-Lid'in kendi uyku-önleme mekanizması bırakmaya rağmen Mac'i uyanık tutmaya devam ederdi. Kapak açıkken, sadece bırakır ve aktif olarak kullandığınız bir Mac'i asla zorla uyutmaz.

Fan kontrolü, LidRun'ın özellikle Apple Silicon'da ne vaat ettiği konusunda bilerek mütevazı kaldığı tek yer. Fan RPM orada firmware tarafından korunan bir yazma işlemi — SoC'nin kendi termal denetleyicisi eğriyi aktif olarak yönetir ve manuel bir müdahaleyi tamamen reddedebilir, birkaç Apple Silicon Pro/Max çipinde firmware, hangi uygulama ne isterse istesin fanları kabaca 70'lerin üst sınırının altında hiç döndürmez. Bu gerçek bir donanım tavanı, herhangi bir aracın mühendisliğindeki bir boşluk değil. Bu yüzden sıcaklık okumayı güvenilir, her zaman açık katman olarak görün ve uzun çalışmalar sırasında Mac'i sert, açık bir yüzeyde havalandırılmış tutun — bu, herhangi bir fan eğrisinin tek başına vaat edebileceğinden hâlâ daha fazlasını termal alan için yapar.