Bagikan melalui

Panduan Desain

Panduan desain manajemen termal PC ini menyediakan informasi tentang cara menentukan nilai suhu PC yang "terlalu panas" dan "terlalu dingin."

Membuat penentuan ini adalah persyaratan utama untuk desain yang memberikan pengalaman pengguna PC yang baik. Selain itu, ambang batas ini membantu memilih tindakan mitigasi pertama yang harus diambil untuk komponen PC yang berada di beberapa zona termal.

Merancang ambang suhu

Variabel dan asumsi

Faktor-faktor berikut memengaruhi perilaku termal PC:

  • Desain perangkat keras

    Pentingnya desain perangkat keras yang baik tidak dapat terlalu ditekankan. Untuk informasi selengkapnya, lihat Pemodelan dan evaluasi termal perangkat keras.

  • Lingkungan

    Ini adalah faktor eksternal yang berkontribusi pada perilaku termal sistem. Perangkat lunak hanya dapat memengaruhi lingkungan dengan memberi tahu pengguna bahwa batasan termal adalah masalah—misalnya, dengan menampilkan logo thermal-failure-to-boot. Pengguna harus pindah ke lingkungan yang berbeda agar faktor-faktor ini berubah:

    • Radiasi sinar matahari

      Intensitas dan sudut sinar matahari yang berdampak pada layar atau bagian mana pun dari sistem.

    • Suhu sekitar

      Suhu lingkungan.

    • Aliran udara

      Dengan atau tanpa sirkulasi udara. Berangin atau dalam kasus komputer.

    • Kelembapan

      Kering atau lembab.

  • Beban kerja dan konsumsi daya

    Asumsi di sini adalah bahwa beban kerja dan konsumsi daya sebanding satu sama lain. Dengan kata lain, semakin banyak pekerjaan yang dilakukan PC atau komponen, semakin banyak daya yang dikonsumsinya dan semakin panas yang dihasilkannya. Meskipun ini mungkin tidak benar dalam semua kasus, model yang disederhanakan ini kurang lebih cukup di sini. Di sinilah mitigasi perangkat lunak masuk. Dengan mengurangi beban kerja, lebih sedikit panas yang dihasilkan dan PC terus beroperasi.

Saat merancang dan memodelkan perangkat keras, mempertimbangkan parameter yang disebutkan dalam daftar sebelumnya. Harap gunakan nilai kasus terburuk untuk lingkungan. Satu-satunya parameter yang dapat dikontrol langsung oleh perangkat lunak adalah beban kerja.

Dasar-dasar termal

Pertimbangkan perilaku termal PC saat menjalankan beban kerja yang konstan. Saat beban kerja dimulai, komponen perangkat keras PC seperti CPU dan GPU menghasilkan panas dan meningkatkan suhu. Ketika suhu meningkat relatif terhadap suhu sekitar, PC mulai menghilangkan panas lebih cepat sampai akhirnya generasi panas sama dengan pembuangan panas, dan suhu mencapai keadaan stabil. Selama seluruh durasi beban kerja konstan ini, karena tidak ada pembatasan yang terlibat, performa dan throughput konstan.

Diagram berikut menunjukkan hubungan antara pembuatan panas, suhu, dan performa ketika tidak ada pembatasan yang terlibat. Perhatikan bahwa suhu PC tetap berada dalam amplop termal, seperti yang dibatasi oleh suhu sekitar dan suhu pembatasan.

panas, suhu, dan performa tanpa pembatasan

Sekarang pertimbangkan perilaku termal PC ketika menjalankan beban kerja yang berbeda yang juga konstan tetapi lebih intensif sumber daya. Ketika beban kerja ini dijalankan, panas yang dihasilkan jauh lebih tinggi daripada apa yang mampu disipasi sistem ke lingkungan sekitar, dan akibatnya suhu naik terus. Tanpa pendinginan pasif, suhu akan terus naik sampai akhirnya sistem akan menjadi terlalu panas dan berdampak buruk pada kenyamanan dan keamanan pengguna akhir. Perangkat keras juga dapat rusak pada suhu tinggi. Pembatasan termal membantu memastikan bahwa PC tidak mencapai suhu tinggi ini. Ketika suhu naik di atas titik perjalanan suhu pembatasan yang telah ditentukan sebelumnya, sistem mulai membatasi performa. Akibatnya, pembuatan panas berkurang dan bertahap—setelah pembuatan panas dan disipasi menyamakan—suhu sistem mencapai keadaan stabil.

Diagram berikut menunjukkan hubungan antara pembuatan panas, suhu, dan performa saat performa dibatasi untuk mengurangi pembuatan panas.

panas, suhu, dan performa dengan pembatasan

Dalam kedua kasus yang ditunjukkan dalam diagram sebelumnya, beban kerja harus beroperasi dalam amplop termal untuk memastikan bahwa suhu sistem tidak melebihi batas aman. Amplop dimulai dengan suhu sekitar dan berakhir dengan suhu pembatasan. Juga dalam kedua kasus, pembangkit panas dan disipasi akhirnya mencapai keadaan seimbang, dan suhu sistem stabil.

Mendefinisikan amplop termal

PC yang dirancang dengan baik harus memiliki amplop termal sebesar mungkin, memberi pengguna pengalaman jangka panjang dan bebas mitigasi. Seperti yang ditunjukkan pada diagram sebelumnya, amplop termal memiliki batas bawah yang ditentukan oleh suhu sekitar. Ini dibatasi di atas oleh suhu pembatasan. Meskipun suhu sekitar bukanlah variabel yang dapat dikontrol oleh perancang sistem, batas atas dapat didorong lebih tinggi oleh desain perangkat keras yang baik. Untuk informasi selengkapnya, lihat Pemodelan dan evaluasi termal perangkat keras. Tetapi bahkan dengan asumsi bahwa perangkat keras bukanlah batasan utama, faktor penting lainnya harus dipertimbangkan ketika mendefinisikan amplop termal.

Rentang operasi yang diinginkan harus sebesar mungkin tanpa merangkum faktor-faktor pembatas ini:

  • Keselamatan

    Suhu sistem harus terlebih dahulu memastikan bahwa pengguna tidak mengalami cedera dari penggunaan sistem. Persyaratan ini sebagian besar berlaku untuk sensor suhu kulit.

  • Perlindungan perangkat keras

    Suhu harus mencegah komponen sistem "mencair" atau menyebabkan kerusakan karena panas. Persyaratan ini sebagian besar berlaku untuk sensor suhu komponen—misalnya, sensor yang berada di atas prosesor.

  • Peraturan pemerintah

    Semua sistem harus memenuhi standar industri yang berlaku (seperti IEC 62368) untuk keamanan elektronik konsumen.

Pemodelan dan evaluasi termal perangkat keras

Perangkat lunak sebagai pelengkap desain perangkat keras

Saat merancang perangkat keras, penting untuk mengingat manajemen termal. Memilih bagian berdaya rendah, menempatkan komponen panas jauh dari satu sama lain, dan menggabungkan isolasi termal hanyalah beberapa contoh bagaimana perangkat keras dapat sangat meningkatkan pengalaman termal. Metode ini tidak dapat diganti dalam perangkat lunak. Dengan demikian, solusi perangkat lunak hanya berfungsi sebagai pelengkap desain perangkat keras dalam pengalaman termal secara keseluruhan.

Tujuan perangkat keras

Beban kerja umum tidak boleh memerlukan bentuk mitigasi termal perangkat lunak untuk dijalankan. Desain termal perangkat keras harus dapat membubarkan panas untuk beban kerja ini dengan sendirinya.

Pemodelan

Pemodelan adalah proses berulang untuk mencapai tujuan perangkat keras yang dijelaskan sebelumnya. Dalam proses ini, jangan memperhitungkan mitigasi perangkat lunak apa pun. Hanya mengandalkan kemampuan perangkat keras dan menyesuaikan seperlunya.

  1. Tentukan beban kerja umum. Tergantung pada platform sistem, dari telepon ke server, setiap sistem harus memiliki set standar beban kerja umum. Ini seharusnya tidak menjadi beban kerja yang intens seperti konferensi video HD, melainkan beban kerja yang lebih rata-rata seperti menelusuri web atau mendengarkan musik.

  2. Sistem model dan konsumsi daya komponen individu pada beban kerja umum karena panas tidak akan tersebar di sasis secara seragam. Perhatikan secara khusus komponen yang mengonsumsi sebagian besar daya, seperti prosesor.

  3. Berdasarkan estimasi konsumsi daya beban kerja, model kenaikan komponen dan suhu kulit dari waktu ke waktu.

  4. Sesuaikan desain mekanis sistem untuk memastikan bahwa suhu komponen berada dalam batas keamanan perangkat keras dan batas kenyamanan pengguna atas semua suhu sekitar. Beberapa metode untuk mengatasi masalah desain mekanis adalah:

    1. Tingkatkan kemampuan disipasi panas dengan menambahkan bahan penghantar panas yang lebih baik.
    2. Tingkatkan suhu delta antara kulit dan suhu internal dengan menambahkan lapisan isolasi.

  5. Ulangi langkah 1 sampai 4 hingga terpenuhi.

  6. Bangun perangkat keras dan evaluasi.

Evaluasi

Untuk setiap revisi perangkat keras, pengukuran suhu dan daya terhadap beban kerja yang representatif harus dilakukan untuk mengevaluasi perilaku termal, dan desain mekanis harus dimodifikasi sesuai kebutuhan.

Langkah-langkah berikut disarankan untuk melakukan evaluasi termal tersebut:

  1. Tentukan matriks pengujian pengukuran termal:

    1. Matriks harus mencakup suhu sekitar normal dan maksimum.
    2. Matriks harus mencakup semua beban kerja khas yang diidentifikasi sebagai bagian dari pemodelan termal, dan untuk setiap beban kerja, data harus diambil setidaknya selama satu jam.
    3. Matriks harus dijalankan dalam beberapa PC beberapa kali untuk menghasilkan hasil yang konsisten.

  2. Untuk setiap beban kerja yang ditentukan dalam matriks pengujian, ambil data berikut:

    1. Data konsumsi daya sistem dan komponen.
    2. Sekitar, komponen internal, dan data suhu kulit.
    3. Jejak perangkat lunak untuk mendeteksi pembatasan termal, metrik performa, dan pemanfaatan prosesor.

Data suhu kulit dan komponen secara langsung menunjukkan suhu kulit maksimum yang mungkin dijangkau sistem dan apakah suhu ini dapat diterima. Pertimbangkan berapa banyak ruang kepala termal yang mungkin dimiliki sistem sebelum pematian kritis. Data metrik performa akan membantu menentukan apakah sistem memberikan performa yang diperlukan. Data pelacakan yang direkam oleh perangkat lunak pembatasan termal menunjukkan persentase pembatasan termal. Data konsumsi daya dan data pemanfaatan CPU dapat membantu menentukan faktor apa yang memengaruhi perubahan suhu.

Tabel berikut ini menyediakan contoh pengumpulan data tersebut untuk PC dengan konfigurasi berikut:

Konfigurasi

  • Nama mesin: Thermal-Test-1
  • Suhu sekitar rata-rata: 23oC
  • Titik perjalanan zona termal (_PSV): 80oC
Kategori Subkategori Streaming video Game kasual Fishbowl Game 3D TDP
Penyiapan beban kerja Streaming video 720p H.264 layar penuh melalui Wi-Fi

Nama permainan

Penggunaan CPU

 IE klasik dengan 100 ikan

Nama permainan

Penggunaan CPU

 CPU dan GPU 100%
Konsumsi daya Daya sistem
Daya SoC
Tampilkan daya
Daya lampu latar
Suhu Suhu SoC Maks
Suhu kulit maks
Metrik performa Kecepatan bingkai rata-rata Kecepatan bingkai rata-rata Kecepatan bingkai rata-rata Kecepatan bingkai rata-rata

Kerangka kerja manajemen termal Windows

Kerangka kerja manajemen termal Windows menyediakan solusi komprehensif untuk manajemen termal perangkat lunak. Contoh berikut menunjukkan cara menerapkan manajemen termal. Dengan pemodelan termal, validasi, dan desain mekanis termal yang tepat, semua sistem harus dapat memberikan pengalaman pengguna yang lancar pada sebagian besar beban kerja pada suhu sekitar yang paling ditargetkan. Di mana mitigasi termal diperlukan, Windows menyediakan arsitektur manajemen termal yang efektif dan dapat diperluas.

Manajemen termal Windows mendukung pendinginan aktif dan pasif. Dengan pendinginan aktif, kipas menyalakan untuk mengedarkan udara dan membantu mendinginkan sistem. Dengan pendinginan pasif, perangkat mengurangi performa perangkat sebagai respons terhadap kondisi termal yang berlebihan. Mengurangi performa menurunkan konsumsi daya, dan dengan demikian menghasilkan lebih sedikit panas.

Kerangka kerja manajemen termal Windows bergantung pada kebijakan yang ditentukan oleh perancang sistem untuk menegakkan manajemen termal pada sistem. Pada tingkat tinggi, desainer harus menentukan bagaimana pembacaan yang diperoleh dari setiap sensor termal dipengaruhi oleh setiap komponen. Tanpa spesifikasi ini, Windows tidak dapat mengelola sistem secara termal. Dengan demikian adalah tanggung jawab setiap perancang sistem untuk mencirikan sistem mereka secara termal untuk mencapai desain termal yang baik.

Meskipun sistem tidak diperlukan untuk menggunakan kerangka kerja manajemen termal Windows, itu adalah solusi yang direkomendasikan karena integrasinya yang ketat dengan sistem operasi. Namun, terlepas dari solusi manajemen termal yang digunakan, semua PC Siaga Modern harus mematuhi persyaratan HCK untuk tujuan diagnostik.

Arsitektur manajemen termal

Arsitektur manajemen termal Windows didasarkan pada konsep ACPI zona termal. Model zona termal ACPI membutuhkan kerja sama antara firmware, sistem operasi, dan driver. Model ini mengabstraksi sensor dan perangkat pendingin dari komponen manajemen termal pusat melalui antarmuka yang terdefinisi dengan baik. Peningkatan manajemen termal didasarkan pada Bab 11 spesifikasi ACPI 5.0. Kerangka kerja manajemen termal Windows mengimplementasikan subset kemampuan yang dijelaskan dalam bab ini.

Komponen penting dari model adalah:

  • Definisi zona termal platform yang dijelaskan untuk Windows melalui firmware. Zona termal adalah entitas abstrak yang memiliki nilai suhu terkait. Sistem operasi memantau suhu ini sehingga dapat menerapkan mitigasi termal ke perangkat di dalam zona. Zona ini berisi sekumpulan perangkat fungsional yang menghasilkan panas, dan subset perangkat yang pembuatan panasnya dapat dikontrol dengan menyesuaikan performa.
  • Sensor suhu yang mewakili suhu wilayah. Sensor harus menerapkan antarmuka Read Temperature untuk mengambil suhu zona dari firmware atau driver suhu Windows.
  • Antarmuka pendinginan termal untuk memungkinkan driver untuk perangkat dalam zona termal untuk menerapkan tindakan pendinginan pasif. Setiap driver terkelola harus memiliki antarmuka pendinginan untuk berpartisipasi dalam infrastruktur termal Windows.
  • Manajer termal terpusat yang mengatur pendinginan dengan menginterpretasikan definisi zona termal dan memanggil antarmuka pada waktu yang diperlukan. Manajer termal diimplementasikan di kernel Windows dan tidak memerlukan pekerjaan dari perancang sistem.

Diagram blok berikut adalah gambaran umum arsitektur manajemen termal Windows. Komponen utama adalah manajer termal, zona termal, driver terkelola, dan sensor suhu. Zona termal menentukan perilaku pembatasan perangkat terkelolanya berdasarkan batasan yang disediakan oleh manajer termal. Algoritma yang digunakan oleh manajer termal menggunakan pembacaan suhu sensor untuk zona termal sebagai parameter inputnya.

gambaran umum arsitektur manajemen termal windows

Zona termal dalam sistem harus dijelaskan dalam firmware ACPI dan diekspos ke manajer termal melalui ACPI. Dengan informasi konfigurasi, manajer termal tahu berapa banyak zona termal yang perlu dikelola, kapan harus mulai membatasi setiap zona termal, dan perangkat mana yang merupakan bagian dari zona tersebut. Untuk memantau suhu, perancang sistem menyediakan dukungan di firmware ACPI untuk pemberitahuan termal.

Ketika manajer termal diberi tahu tentang peristiwa termal di zona enumerasi, itu akan mulai secara berkala mengevaluasi suhu zona dan menentukan persentase performa pembatasan termal untuk diterapkan ke perangkat di zona termal. Evaluasi ini dilakukan oleh algoritma pembatasan termal yang diuraikan dalam spesifikasi ACPI. Kemudian manajer termal memberi tahu semua perangkat di zona untuk membatasi performa dengan persentase tertentu dan driver perangkat menerjemahkan persentase pembatasan ke tindakan khusus kelas perangkat untuk mengurangi performa. Evaluasi dan pembatasan berkala akan berhenti ketika suhu zona termal turun di bawah suhu ambang pembatasan dan tidak diperlukan lagi pembatasan.

Perulangan umpan balik

Cara lain untuk memikirkan arsitektur manajemen termal adalah dalam hal input, direktur kebijakan, dan perangkat terkelola. Dalam diagram blok berikut, input ke perulangan umpan balik adalah suhu dan arus listrik. Input ini digunakan untuk menentukan kebijakan termal yang akan diterapkan. Manajer termal bergantung pada input suhu secara eksklusif, dan driver kebijakan dapat menggunakan input apa pun yang diinginkannya. Zona termal kemudian menerapkan kebijakan itu ke driver terkelolanya. Setelah kebijakan diterapkan, sensor akan memperbarui nilainya dan menutup perulangan.

Diagram blok berikut menunjukkan tiga tahap model respons termal. Input dari sensor suhu dan arus listrik memberikan informasi untuk membantu menentukan kebijakan termal apa yang akan diterapkan. Kebijakan ini diterapkan pada driver terkelola, yang kemudian memengaruhi pembacaan pada sensor. Proses ini diulang dalam perulangan umpan balik.

model respons termal

Tanggung jawab pelaksana sistem

Seperti disebutkan di atas, sejumlah komponen diperlukan untuk memiliki solusi termal Windows yang lengkap. Arsitektur kerangka kerja termal dirancang khusus sehingga tanggung jawab vendor perangkat keras dan integrator sistem dapat dipisahkan.

Komponen yang diperlukan untuk diimplementasikan mitra adalah:

  • Sensor

    Driver sensor suhu harus disediakan oleh vendor perangkat keras. Mengingat bahwa sensor suhu tidak memerlukan pengetahuan tentang zona termal yang mengandalkannya, fungsionalitasnya harus standar di berbagai desain platform. Sensor kustom untuk driver kebijakan, seperti sensor saat ini, juga merupakan tanggung jawab vendor perangkat keras.

  • Zona termal

    Zona termal dapat didefinisikan oleh vendor perangkat keras dan/atau integrator sistem. Semua sistem harus memiliki setidaknya satu zona termal yang menerapkan suhu matikan kritis (dan suhu hibernasi, jika didukung), yang dapat dilakukan oleh vendor perangkat keras atau integrator sistem. Namun, untuk zona termal lainnya yang memantau perangkat tertentu atau suhu kulit untuk mitigasi, adalah umum bagi integrator sistem untuk memiliki pengetahuan yang lebih spesifik tentang perilaku termal sistem. Dengan demikian, zona termal ini biasanya diimplementasikan oleh integrator sistem.

  • Antarmuka pendinginan termal untuk driver perangkat

    Pengembang yang menulis driver untuk perangkat yang akan dikelola secara termal juga harus menjadi yang mengimplementasikan antarmuka pendinginan. Driver perangkat menggunakan antarmuka ini untuk memilih kerangka kerja manajemen termal. Driver perangkat memiliki pengetahuan khusus tentang kemampuan perangkat mereka. Driver yang sama ini harus mengimplementasikan antarmuka pendingin termal sehingga dapat menafsirkan tindakan yang diminta oleh zona termal dengan benar.

Sensor

Sensor memberikan input untuk menentukan kebijakan termal apa yang seharusnya. Windows hanya mendukung sensor suhu sebagai input ke manajer termal. Namun, driver kebijakan juga dapat mengambil input dari driver kustom, seperti driver sensor saat ini.

Sensor suhu

Sensor suhu menyediakan mode fungsionalitas berikut:

  • Terus memantau perubahan suhu tanpa keterlibatan manajer termal atau zona termal.
  • Memberi tahu manajer termal ketika suhu melewati ambang batas yang ditentukan oleh _PSV, _HOT, atau _CRT.
  • Merespons kueri suhu dan mengembalikan nilai suhu saat ini.

Diagram berikut menunjukkan bagaimana fungsi pemantauan suhu selama pembatasan. Firmware ACPI atau driver sensor suhu harus memberi tahu manajer termal ketika suhu mencapai ambang batas yang telah ditentukan seperti _PSV, _HOT atau _CRT, dan kemudian menanggapi kueri berkala dari manajer termal untuk suhu saat ini. Periode kueri suhu ditentukan oleh _TSP.

pemantauan dan pelaporan suhu

Untuk memastikan bahwa manajer termal akan selalu diberi tahu ketika suhu melebihi ambang batas, gangguan sensor suhu harus selalu dapat dibangunkan (bahkan ketika sistem berada dalam Siaga Modern dan SoC dalam keadaan berdaya rendah). Jika gangguan sensor suhu tidak selalu dapat dibangunkan, setidaknya gangguan harus dikonfigurasi sebagai dipicu tingkat untuk menghindari potensi kehilangan gangguan.

Sensor termal dapat digunakan oleh beberapa zona termal, meskipun tidak boleh ada lebih dari satu sensor termal di zona termal.

Kami menyarankan agar perangkat keras sensor akurat hingga +/- 2oC.

Suhu yang dilaporkan oleh _TMP atau driver sensor suhu mungkin merupakan nilai aktual sensor, atau nilai yang diekstrapolasi berdasarkan beberapa sensor.

Ini biasanya disediakan oleh vendor perangkat keras. Windows mendukung dua implementasi untuk memantau suhu:

  • Driver sensor suhu
  • Berbasis ACPI

Implementasi 1: Driver sensor suhu

Driver sensor suhu hanya melaporkan suhu sensor. Driver ACPI akan mengeluarkan satu IOCTL yang beredar dengan driver sensor untuk mendeteksi persimpangan salah satu titik perjalanan. Selain itu, ACPI dapat mengeluarkan satu IOCTL tanpa waktu habis untuk membaca suhu saat ini. Driver sensor harus menangani pembatalan IOCTL baca, jika dibatalkan saat menunggu waktu habis kedaluwarsa. Sensor suhu harus mengimplementasikan antarmuka berikut:

typedef struct _THERMAL_WAIT_READ {  
    ULONG Timeout;  
    ULONG LowTemperature;  
    ULONG HighTemperature;  
} THERMAL_WAIT_READ, *PTHERMAL_WAIT_READ;

#define IOCTL_THERMAL_READ_TEMPERATURE\  
        CTL_CODE(FILE_DEVICE_BATTERY, 0x24, METHOD_BUFFERED, FILE_READ_ACCESS)

Tabel berikut menjelaskan parameter input dan output untuk antarmuka pembacaan suhu.

Parameter Deskripsi
Timeout

Waktu untuk menunggu sebelum mengembalikan data suhu, dalam milidetik.

0 menunjukkan suhu harus segera dibaca, tanpa menunggu. -1 menunjukkan bacaan seharusnya tidak kehabisan waktu.
LowTemperature

Ambang batas bawah untuk mengembalikan suhu baru. Segera setelah suhu turun di bawah ambang suhu rendah, driver harus menyelesaikan IOCTL. Jika suhu sudah di bawah suhu rendah, IOCTL harus segera diselesaikan.
HighTemperature

Ambang atas untuk mengembalikan suhu baru. Segera setelah suhu naik di atas ambang suhu tinggi, driver harus menyelesaikan IOCTL. Jika suhu sudah di atas suhu tinggi, IOCTL harus segera diselesaikan.
Nilai pengembalian IOCTL

Buffer output berukuran ULONG yang akan mengembalikan suhu saat ini, dalam sepuluh derajat Kelvin.

Satu sensor suhu dapat digunakan oleh satu zona termal atau beberapa zona termal. Untuk menentukan sensor suhu mana yang harus digunakan untuk zona termal, _DSM termal harus ditentukan pada zona termal, dan harus menerapkan fungsi 2. (Untuk kompatibilitas mundur, driver sensor suhu dapat dimuat di atas tumpukan zona termal. Namun, implementasi yang disukai adalah memiliki driver sensor yang terpisah dari tumpukan zona termal.) _DSM ini didefinisikan sebagai berikut:

ArgumenArg0: UUID = 14d399cd-7a27-4b18-8fb4-7cb7b9f4e500 Arg1: Revisi = 0 Arg2: Fungsi = 2 Arg3: Paket kosong Mengembalikan Referensi tunggal ke perangkat yang akan mengembalikan suhu zona termal.

Zona termal juga harus menentukan dependensi pada perangkat sensor suhu dengan _DEP. Berikut adalah contoh sederhana untuk implementasi _DSM perangkat sensor.

Device(\_SB.TSEN) {
    Name(_HID, "FBKM0001")     // temperature sensor device
}

ThermalZone(\_TZ.TZ01) {
    Method(_DSM, 0x4, NotSerialized){
        Switch (ToBuffer(Arg0)) {
            Case (ToUUID("14d399cd-7a27-4b18-8fb4-7cb7b9f4e500")) {
                Switch (ToInteger(Arg2)) {
                    Case(0) {
                        // _DSM functions 0 and 2 (bits 0 and 2) are supported
                        Return (Buffer() {0x5})
                    }       
                    Case (2) {
                        Return ("\_SB.TSEN")
                    }
                }
            }
        }
    }

    Method(_DEP) {
        Return (Package() {\_SB.TSEN})
    }

    // Other thermal methods: _PSV, etc.

}

Untuk informasi selengkapnya, lihat Metode Khusus Perangkat untuk ekstensi termal Microsoft.

Implementasi 2: Berbasis ACPI

Firmware ACPI harus mendukung _TMP dan Memberi tahu 0x80, seperti yang didefinisikan dalam spesifikasi ACPI. Keuntungan dari pendekatan ini adalah tidak memerlukan driver tambahan yang diinstal pada sistem. Namun, pendekatan ini terbatas pada interaksi dengan sumber daya yang dapat diakses melalui wilayah operasi ACPI.

Kontrol kebijakan termal

Zona termal

Zona termal adalah entitas pembatasan termal individu. Ini memiliki karakteristik pembatasan termal sendiri, seperti titik perjalanan, laju sampel pembatasan, dan konstanta persamaan pembatasan. Satu zona termal mungkin mencakup beberapa perangkat pembatasan termal, yang masing-masing dapat berkontribusi pada peningkatan suhu di zona termal. Semua perangkat di zona termal yang sama harus mengikuti batasan yang sama yang diterapkan ke zona termal.

Untuk memastikan zona termal dan parameternya didefinisikan secara akurat, perancang sistem harus:

  • Identifikasi titik panas dalam sasis sistem, dan tentukan bagaimana titik panas ini membuang panas ke sensor suhu. (Idealnya, sensor termal duduk di hot spot pada sistem, kecuali untuk sensor suhu kulit.)
  • Mencirikan hubungan suhu sistem. Petakan pembacaan sensor suhu ke suhu komponen dan suhu kulit.

Ambang batas overthrottle

Dimulai dengan Windows 10, fitur baru yang disebut status zona termal, telah diperkenalkan ke dalam manajemen termal Windows, bersama dengan satu status: ditimpa. Ketika zona termal melebihi tingkat pembatasan yang dirancang perangkat, manajer termal akan memberi tahu komponen sistem operasi bahwa sistem ditimpa. Pemberitahuan ini memungkinkan sistem mengurangi beban kerja untuk meningkatkan status termal.

Manajer termal mempertahankan jumlah global dari jumlah zona termal yang berada dalam status overthrottled. Ketika jumlah meningkat di atas nol (0), manajer termal mengirimkan pemberitahuan Windows Notification Facility (WNF) ke sistem, yang menunjukkan bahwa itu overthrottled. Ketika jumlah zona yang dilewati kembali ke nol (0), manajer termal mengirimkan pemberitahuan WNF lain ke sistem, yang menunjukkan tidak ada zona yang dilewati.

Untuk menentukan ambang overthrottle untuk zona termal, _DSM termal harus ditentukan pada zona termal, dengan fungsi 3 diimplementasikan. _DSM ini didefinisikan sebagai berikut:

ArgumenArg0: UUID = 14d399cd-7a27-4b18-8fb4-7cb7b9f4e500 Arg1: Revisi = 0 Arg2: Fungsi = 3 Arg3: Paket kosong Mengembalikan nilai Bilangan Bulat dengan ambang batas overthrottle saat ini, dinyatakan sebagai persentase.

Berikut adalah contoh _DSM yang menunjukkan bahwa zona ditimpa, pada tingkat pembatasan 0% hingga 49%.

 ThermalZone (TZ4) {
    Name (_HID, "QCOM24AE")
    Name (_UID, 0)
    Name(_TZD, Package (){\_SB.CPU4, \_SB.CPU5, \_SB.CPU6, \_SB.CPU7})
    Method(_PSV) { Return (3530) }
       Name(_TC1, 1)
       Name(_TC2, 1)
       Name(_TSP, 1)
       Name(_TZP, 0)
       // _DSM - Device Specific Method
       // Arg0: UUID Unique function identifier
       // Arg1: Integer Revision Level
       // Arg2: Integer Function Index (0 = Return Supported Functions)
       // Arg3: Package Parameters
       Method(_DSM, 0x4, NotSerialized) {
          Switch (ToBuffer(Arg0)) {
             Case (ToUUID("14d399cd-7a27-4b18-8fb4-7cb7b9f4e500")) {
                Switch (ToInteger(Arg2)) {
                   Case(0) {
                      // _DSM functions 0 and 3 (bits 0 and 3) are supported
                      Return (Buffer() {0x9})
                   }
                   Case (3) {
                      Return (50)  // overthrottled below 50%
                   }
                }
             }
          }
       }
 } // end of TZ4

Ambang overthrottle akan dibaca kembali ketika Notify(0x81) diterima sebagai referensi ke zona termal.

Menerapkan objek ACPI

Tabel berikut mencantumkan semua objek ACPI yang perlu diimplementasikan di firmware ACPI untuk menentukan zona termal.

Kategori Metode pengendalian
Mengidentifikasi perangkat yang terkandung dalam zona

_TZD

Mencantumkan perangkat di zona termal.

_PSL

(Opsional) Mencantumkan prosesor di zona termal. Prosesor dapat disertakan dalam _TZD sebagai gantinya—Windows mendukung kedua implementasi.
Tentukan ambang batas termal di mana tindakan harus diambil

_PSV

Suhu untuk memulai pembatasan. Untuk informasi selengkapnya, lihat Menentukan amplop termal.

_HOT

(Opsional) Suhu di mana sistem operasi menghibernasi sistem. Untuk sistem yang tidak mendukung hibernasi, sistem operasi akan memulai pematian kritis. Ini sangat disarankan untuk setidaknya satu zona termal untuk semua sistem x86/x64 karena manfaat hibernasi untuk menyimpan data pengguna.

_CRT

Suhu di mana sistem operasi memulai pematian kritis. Tidak ada pemberitahuan mode pengguna. Setidaknya satu zona termal pada sistem harus memiliki _CRT yang ditentukan. Jika tidak, sistem tidak melalui jalur pematian ketika sistem mencapai suhu kritis. Sebaliknya, titik perjalanan firmware fail-safe tercapai dan daya kemungkinan ditarik dari bawah sistem operasi.
Menjelaskan perilaku pendinginan pasif

_TC1

Kontrol seberapa agresif manajer termal menerapkan performa pembatasan termal terhadap perubahan suhu.

_TC2

Kontrol seberapa agresif manajer termal menerapkan performa pembatasan termal terhadap delta suhu antara suhu saat ini dan _PSV.

_SDT

Interval pengambilan sampel suhu yang sesuai untuk zona dalam persepuluh detik. Manajer termal menggunakan interval ini untuk menentukan seberapa sering ia harus mengevaluasi performa pembatasan termal. Harus lebih besar dari nol. Untuk informasi selengkapnya, lihat Algoritma pembatasan termal.
Menjelaskan perilaku pendinginan aktif

_ACx

(Opsional) Suhu untuk menyalakan kipas angin. Harus dalam urutan terbesar untuk paling sedikit, dengan _AC0 menjadi yang terbesar.

_Alx

Daftar perangkat pendingin aktif.
Mengatur kebijakan pendinginan aktif/pasif

_SCP

(Opsional) Untuk mengatur kebijakan pendinginan pilihan pengguna, jika pendinginan aktif dan pasif didukung oleh zona.
Batas Pembatasan Minimum

_DSM

Gunakan UUID: 14d399cd-7a27-4b18-8fb4-7cb7b9f4e500 untuk menetapkan batas pembatasan minimum. Perhatikan bahwa ini kustom untuk kerangka kerja termal Windows dan tidak didefinisikan dalam ACPI. Untuk informasi selengkapnya, lihat Batas pembatasan minimum.
Melaporkan suhu

_TMP

Baca suhu zona termal.

_HID

Pengidentifikasi perangkat keras unik vendor untuk memuat driver suhu Windows.

_DTI

(Opsional) Untuk memberi tahu firmware platform bahwa salah satu ambang batas termal zona telah terlampaui. Metode ini memungkinkan firmware untuk mengimplementasikan histeresis dengan mengubah ambang batas zona.

_NTT

(Opsional) Untuk menentukan perubahan suhu yang signifikan, firmware platform juga harus diberi tahu melalui _DTI.
Memberi tahu manajer termal

Beri tahu 0x80

Memberi tahu sistem operasi bahwa ambang batas (_PSV) telah terlampaui. Manajer termal Windows akan memulai kontrol termal.

Beri tahu 0x81

(Opsional) Memberi tahu sistem operasi bahwa nilai ambang zona telah berubah. Manajer termal Windows akan memperbarui dirinya sendiri untuk menggunakan nilai baru. Metode ini biasanya digunakan untuk mengimplementasikan histeresis.
Tentukan perangkat sensor suhu

_DSM

Gunakan UUID: 14d399cd-7a27-4b18-8fb4-7cb7b9f4e500. Untuk informasi selengkapnya, lihat Sensor suhu.

_DEP

Muat perangkat yang dirujuk sensor suhu.

Batas pembatasan minimum

Batas pembatasan minimum adalah metode _DSM ekstensi termal Microsoft yang membuat batas bawah untuk _PSV diminta dari perangkat yang dibatasi. Dengan kata lain, ini menentukan berapa banyak zona termal yang membatasi performa perangkat yang dikontrolnya. Jika ada, pembatasan minimum _DSM akan dibaca saat boot dan kapan saja zona termal menerima ACPI Notify (0x81). Pada setiap perulangan algoritma pendinginan pasif, berikut ini digunakan untuk menghitung perubahan batas performa (DP) yang diterapkan manajer termal untuk perangkat di zona tersebut:

DP [%] = _TC1 × (Tn – Tn₋₁) + _TC2 × (Tn – Tt) Kami kemudian menggunakan yang berikut ini untuk menghitung batas performa aktual:

Pn = Pn₋₁ – DP Dengan batas pembatasan minimum (MTL) yang diterapkan, persamaan kedua ini berubah menjadi:

Pn = max(Pn₋₁ – DP, MTL) Untuk menentukan batas pembatasan minimum untuk zona termal, _DSM termal harus ditentukan pada zona termal, dengan fungsi 1 diimplementasikan. _DSM ini didefinisikan sebagai berikut:

ArgumenArg0: UUID = 14d399cd-7a27-4b18-8fb4-7cb7b9f4e500 Arg1: Revisi = 0 Arg2: Fungsi = 1 Arg3: Paket kosong Mengembalikan nilai Bilangan Bulat dengan batas pembatasan minimum saat ini, dinyatakan sebagai persentase.

Berikut adalah contoh sederhana untuk pembatasan pembatasan _DSM tidak kurang dari 50 persen.

ThermalZone(\_TZ.TZ01) {
    Method(_DSM, 0x4, NotSerialized) {
        Switch (ToBuffer(Arg0)) {
            Case (ToUUID("14d399cd-7a27-4b18-8fb4-7cb7b9f4e500")) {
                Switch (ToInteger(Arg2)) {
                    Case(0) {
                        // _DSM functions 0 and 1 (bits 0 and 1) are supported
                        Return (Buffer() {0x3})
                    }       
                    Case (1) {
                        Return (50)
                    }
                }
            }
        }
    }

Manajer termal dalam kernel

Manajer termal Windows diimplementasikan sebagai bagian dari kernel Windows. Ini memantau suhu semua zona termal dan menerapkan pembatasan termal yang sesuai.

Setiap kali manajer termal meminta driver ACPI untuk suhu saat ini, itu akan melakukan perhitungan tentang berapa banyak persentase performa pembatasan termal yang harus berlaku untuk semua perangkat pembatasan termal di zona termal. Batas termal dievaluasi dan diterapkan ketika ambang pendinginan pasif (_PSV) terlampaui, dan pada setiap interval pengambilan sampel suhu (_TSP) sampai suhu didinginkan di bawahnya dan batas termal kembali ke 100 persen. Perangkat keras harus mendeteksi kapan _PSV telah terlampaui dan harus memberi sinyal bahwa melalui pemberitahuan peristiwa ACPI perangkat keras.

Algoritma pembatasan termal

Algoritma pembatasan termal menggunakan persamaan berikut, yang didefinisikan dalam spesifikasi ACPI:

DP [%] = _TC1 × ( Tn – Tn₋₁ ) + _TC2 × (Tn – Tt) di mana

Tn = pembacaan suhu sensor suhu saat ini di zona termal dalam persepuluh derajat Kelvin. Tn₋₁ = suhu dari pembacaan sebelumnya. Tt = suhu target dalam persepuluh derajat Kelvin (_PSV). DP = perubahan performa diperlukan. Ini adalah nilai linier antara 0 (sepenuhnya dibatasi) dan 100 persen (tidak terhambat), yang akan diterapkan ke setiap perangkat pendingin di zona tersebut. Persamaan ini menjelaskan perulangan umpan balik antara perubahan suhu dan performa pembatasan. Dalam setiap iterasi perulangan, delta suhu antara pembacaan suhu saat ini dan sebelumnya membutuhkan performa P untuk mengurangi persentase DP. Nilai DP adalah jumlah pembatasan termal yang akan diterapkan. Banyak perangkat pendingin tidak memiliki respons termal linier terhadap mitigasi pendinginan. Dalam perangkat ini, batas termal adalah petunjuk untuk perangkat untuk menunjukkan berapa banyak pendinginan yang diperlukan. Setiap perangkat pendingin akan memiliki pemetaan sendiri dari nilai linier ini ke mitigasi termal khusus perangkat. Performa perangkat pembatasan mengurangi konsumsi daya dan pembangkit panas, yang menyebabkan suhu menurun.

Dua konstanta, _TC1 dan _TC2, mengontrol seberapa agresif pembatasan termal diterapkan dalam perulangan umpan balik ini. Semakin besar _TC1, semakin agresif pembatasan termal digunakan untuk mempertahankan suhu yang stabil. Semakin besar _TC2, semakin agresif pembatasan termal digunakan untuk mendorong suhu di dekat titik perjalanan.

Tabel berikut ini menyediakan contoh cara manajer termal menghitung dan menerapkan DP. Contoh ini menggunakan nilai parameter berikut:

Konfigurasi

  • _PSV = 325oK
  • _TC1 = 2
  • _TC2 = 3
  • _TSP = 5000 milidetik
  • Asumsikan suhu terus naik 1 derajat setiap 5 detik.

Kolom paling kanan dalam tabel berikut (berlabel P) menunjukkan tingkat performa yang dibatasi yang dihasilkan dari memberlakukan batasan yang ditentukan oleh parameter ini.

Iterasi Waktu Tn DP P
1 0 detik 326oK = 2 × 1 + 3 × 1 = 5% 95%
2 5 detik 327oK = 2 × 1 + 3 × 2 = 8% 87%
3 10 detik 328oK = 2 × 1 + 3 × 3 = 11% 76%
4 15 detik 320oK = 2 × 1 + 3 × 4 = 14% 62%
5 20 detik 330oK = 2 × 1 + 3 × 5 = 17% 45%
...

Driver kebijakan

Secara default, algoritma yang digunakan untuk menentukan persentase pembatasan seperti yang ditentukan oleh spesifikasi ACPI digunakan untuk semua zona termal. Seperti yang dijelaskan sebelumnya, algoritma ini hanya didasarkan pada sensor suhu yang melekat pada zona termal, yang dapat membatasi.

Jika algoritma yang berbeda lebih disukai, perancang sistem dapat menerapkan pendorong kebijakan untuk mewujudkan algoritma yang disukai. Driver kebijakan berada di atas tumpukan zona termal untuk zona yang dikontrolnya. Untuk zona ini, algoritma driver kebijakan dapat digunakan sebagai pengganti algoritma ACPI di manajer termal. Algoritma driver kebijakan memiliki kemampuan untuk mempertimbangkan informasi apa pun yang dapat diaksesnya sebagai input. Keputusan kebijakan yang dibuat oleh pengemudi diteruskan ke manajer termal, yang mencatat informasi dan meneruskannya ke zona termal untuk dilakukan.

Menggunakan pendorong kebijakan untuk zona termal berarti bahwa driver kebijakan—bukan ACPI dan bukan sistem operasi—bertanggung jawab sepenuhnya untuk memutuskan kapan harus membatasi zona dan berapa banyak.

Jika pengemudi kebijakan ada, semua titik perjalanan, semua konstanta termal, batas pembatasan minimum, dan sebagainya, sepenuhnya diabaikan. Sistem operasi tidak memiliki wawasan tentang mengapa zona termal diatur pada tingkat pembatasan saat ini. Beberapa manfaat datang dengan menggunakan driver kebijakan alih-alih solusi kepatutan. Driver kebijakan memanfaatkan proses bawaan perangkat pembatasan. Apa pun yang dapat dilakukan zona termal untuk memberikan mitigasi termal dapat dilakukan oleh pendorong kebijakan. Selain itu, diagnostik untuk manajemen termal Windows secara otomatis diwarisi.

Antarmuka kebijakan termal telah diperbarui untuk menyertakan parameter baru untuk menunjukkan apakah zona ditimpa atau tidak. Parameter ini diinisialisasi ke FALSE. Driver kebijakan lama tidak akan menyadari parameter baru, dan driver baru akan tahu bahwa parameter baru didukung, ketika mereka mendeteksi versi kebijakan '2'.

#define TZ_ACTIVATION_REASON_THERMAL      0x00000001  
#define TZ_ACTIVATION_REASON_CURRENT      0x00000002

#define THERMAL_POLICY_VERSION_1          1
#define THERMAL_POLICY_VERSION_2          2

typedef struct _THERMAL_POLICY {  
    ULONG           Version;  
    BOOLEAN         WaitForUpdate;  
    BOOLEAN         Hibernate;  
    BOOLEAN         Critical;  
    ULONG           ActivationReasons;  
    ULONG           PassiveLimit;  
    ULONG           ActiveLevel;
    BOOLEAN         OverThrottled;  
} THERMAL_POLICY, *PTHERMAL_POLICY;

Driver kebijakan dapat menunjukkan bahwa zona termal ditimpa, dengan menyelesaikan kebijakan IOCTL dengan parameter OverThrottled yang diatur ke TRUE. Ketika kondisi termal membaik, driver kebijakan termal kemudian dapat menyelesaikan IOCTL dengan overThrottled reset ke FALSE, untuk menunjukkan bahwa zona termal telah pulih. Windows tidak akan mengharuskan driver kebijakan untuk dibatasi ketika bendera overthrottle diatur.

Perangkat yang dikelola secara termal

Zona termal mengontrol perilaku termal perangkat terkelola melalui driver mode kernel mereka. Satu perangkat pembatasan termal mungkin berada di beberapa zona termal. Ketika beberapa zona termal meminta persentase performa pembatasan termal yang berbeda, manajer termal memilih persentase performa pembatasan termal minimal untuk diterapkan ke perangkat pembatasan termal.

Banyak perangkat pendingin tidak memiliki respons termal linier terhadap mitigasi pendinginan. Dalam kasus ini, batas termal adalah petunjuk untuk perangkat tingkat pendinginan yang diperlukan. Setiap perangkat pendingin akan memiliki pemetaan sendiri dari nilai linier ini ke mitigasi termal spesifiknya.

Saat setiap driver perangkat dimuat, ACPI akan meminta Antarmuka Pendinginan Termal dan mendaftarkan setiap perangkat yang merespons sebagai perangkat pendingin. Nantinya, ketika pendinginan pasif sedang dalam proses dan batas termal untuk zona telah berubah, ACPI akan memanggil antarmuka ini pada setiap perangkat pendingin di zona tersebut. Perangkat pendingin kemudian akan memetakan batas termal yang disediakan ke karakteristik pendinginan spesifiknya, dan menerapkan mitigasi pendinginan yang sesuai. Perhatikan bahwa jika perangkat pendingin muncul di beberapa zona termal, batas termal yang paling membatasi perangkat (yaitu, persentase terendah) diteruskan ke perangkat.

Catatan Windows menyediakan implementasi bawaan pembatasan termal untuk prosesor, backlight, dan baterai metode kontrol ACPI.

Antarmuka pendinginan termal

Windows menyediakan titik ekstensi bagi driver perangkat untuk mendaftar sebagai perangkat pembatasan termal dan menerima permintaan persentase pembatasan termal. Perangkat kemudian bertanggung jawab untuk menerjemahkan persentase tersebut ke tindakan yang masuk akal untuk dirinya sendiri.

Perangkat yang ingin ditambahkan sebagai perangkat pembatasan termal harus terlebih dahulu menambahkan _HIDs ke dalam daftar perangkat termal zona termal lalu mengimplementasikan set antarmuka berikut. Saat setiap driver perangkat dimuat, ACPI akan meminta antarmuka ini dan mendaftarkan setiap perangkat yang merespons sebagai perangkat pendingin. Nantinya, ketika pendinginan pasif sedang dalam proses dan batas termal untuk zona telah berubah, ACPI akan memanggil antarmuka ini pada setiap perangkat pendingin di zona tersebut. Perangkat pendingin kemudian akan memetakan batas termal yang disediakan ke karakteristik pendinginan spesifiknya, dan menerapkan mitigasi pendinginan yang sesuai. Perhatikan bahwa jika perangkat pendingin muncul di beberapa zona termal, batas termal yang paling membatasi perangkat (yaitu, persentase terendah) diteruskan ke perangkat.

//  
// Thermal client interface (devices implementing  
// GUID_THERMAL_COOLING_INTERFACE)  
//

typedef  
_Function_class_(DEVICE_ACTIVE_COOLING)  
VOID  
DEVICE_ACTIVE_COOLING (  
    _Inout_opt_ PVOID Context,  
    _In_ BOOLEAN Engaged  
    );  

typedef DEVICE_ACTIVE_COOLING *PDEVICE_ACTIVE_COOLING;  

typedef  
_Function_class_(DEVICE_PASSIVE_COOLING)  
VOID  
DEVICE_PASSIVE_COOLING (  
    _Inout_opt_ PVOID Context,  
    _In_ ULONG Percentage  
    );  

typedef DEVICE_PASSIVE_COOLING *PDEVICE_PASSIVE_COOLING;  

typedef struct _THERMAL_COOLING_INTERFACE {  
    //  
    // generic interface header  
    //  
    USHORT Size;  
    USHORT Version;  
    PVOID Context;  
    PINTERFACE_REFERENCE    InterfaceReference;  
    PINTERFACE_DEREFERENCE  InterfaceDereference;  
    //  
    // Thermal cooling interface  
    //  
    ULONG Flags;  
    PDEVICE_ACTIVE_COOLING ActiveCooling;  
    PDEVICE_PASSIVE_COOLING PassiveCooling;  
} THERMAL_COOLING_INTERFACE, *PTHERMAL_COOLING_INTERFACE;  

#define THERMAL_COOLING_INTERFACE_VERSION 1

Prosesor

Untuk prosesor, manajer termal mengkomunikasikan persentase pembatasan termal ke manajer daya prosesor (PPM). Pembatasan termal prosesor adalah fitur bawaan Windows.

Agregator prosesor

Perangkat agregator prosesor memungkinkan parkir inti sebagai mitigasi termal. Zona dapat menentukan parkir inti sebagai mitigasi termal jika perangkat agregator prosesor adalah anggota zona termal. Prosesor tidak perlu dibatasi agar parkir inti terjadi. Implementasi ini bekerja secara paralel dengan prosesor logis idling (LPI). Perhatikan bahwa ini masih tunduk pada peringatan parkir inti. Secara khusus, setiap pekerjaan yang diafinisisikan ke inti yang diparkir akan menyebabkan inti berjalan.

Device(\_SB.PAGR) {
    Name(_HID, "ACPI000C")
}
ThermalZone(\_TZ.TZ01) {
    Name(_TZD, Package() {"\_SB.PAGR"})
    // Other thermal methods: _PSV, etc.
}

Grafik

Agar driver miniport grafis pihak ketiga dikelola secara termal, driver harus berinteraksi dengan driver port grafis Windows, Dxgkrnl.sys. Dxgkrnl.sys memiliki antarmuka pendingin termal dan meneruskan permintaan pembatasan ke bawah tumpukan ke driver miniport. Driver miniport bertanggung jawab untuk menerjemahkan permintaan ke tindakan khusus untuk perangkatnya.

Diagram blok berikut menunjukkan arsitektur zona termal yang mengontrol GPU.

arsitektur untuk zona termal yang mengontrol gpu

Lampu latar

Mengurangi lampu latar dapat secara dramatis meningkatkan kondisi termal pada platform seluler. Windows merekomendasikan agar saat beroperasi, kecerahan tampilan sistem tidak pernah dibatasi secara termal hingga kurang dari 100 nits.

Untuk kontrol lampu latar, manajer termal mengkomunikasikan persentase pembatasan termal ke driver monitor, Monitor.sys. Monitor.sys akan memutuskan pengaturan tingkat backlight aktual berdasarkan input termal ini dan input lain di Windows. Kemudian Monitor.sys akan menerapkan pengaturan tingkat backlight melalui ACPI atau driver tampilan.

Perhatikan bahwa jika suhu zona termal yang mencakup lampu latar terus meningkat, persentase pembatasan termal yang diminta pada akhirnya mungkin turun ke nol persen. Implementasi tingkat backlight di ACPI atau driver tampilan harus memastikan bahwa tingkat kecerahan minimal yang tersedia untuk kontrol performa masih terlihat untuk pengguna akhir.

Catatan Saat beroperasi, kecerahan tampilan sistem tidak pernah dibatasi secara termal hingga kurang dari 100 nits.

Baterai

Sumber panas utama lain dalam sistem adalah pengisian daya baterai. Dari perspektif pengguna, pengisian daya harus dikurangi dan bahkan sepenuhnya dihentikan dalam kondisi termal yang dibatasi. Namun, pengisian daya baterai tidak boleh dihalangi di bawah kasus penggunaan normal.

Catatan Sebaiknya pengisian daya baterai tidak dibatasi saat sistem (1) tidak aktif dan dalam rentang suhu sekitar di bawah 35oC, atau (2) dalam kondisi apa pun sementara suhu sekitar di bawah 25oC.

Driver miniclass Baterai Metode Kontrol Windows, Cmbatt.sys, menggunakan Antarmuka Pendinginan Termal secara langsung, seperti yang dijelaskan di atas. Firmware bertanggung jawab untuk mempertimbangkan batas termal saat ini saat melibatkan pengisian daya. Metode kontrol ACPI baru diperlukan untuk mengatur batas termal untuk pengisian daya. Metode ini diimplementasikan sebagai Metode Khusus Perangkat (_DSM), seperti yang didefinisikan dalam spesifikasi ACPI 5.0, Bagian 9.14.1.

Untuk menerapkan persentase pembatasan termal, Cmbatt.sys akan mengevaluasi metode kontrol Metode Khusus Perangkat (_DSM) untuk meminta firmware ACPI menetapkan batas termal untuk pengisian daya. Dalam metode kontrol _DSM, GUID didefinisikan untuk menunjukkan batas termal.

Arg # Nilai Deskripsi
Arg0 4c2067e3-887d-475c-9720-4af1d3ed602e UUID
Arg1 0 Revisi
Arg2 1 Fungsi
Arg3 Nilai bilangan bulat dari 0 hingga 100 Batas termal untuk pengisian daya baterai. Setara dengan persentase penghitungan pembatasan pasif.
Nilai pengembalian T/A Tidak ada nilai yang dikembalikan

Pendinginan aktif

Dari sudut pandang sistem operasi, platform memiliki dua strategi yang dapat digunakan untuk menerapkan kontrol kipas angin:

  • Terapkan satu atau beberapa zona termal ACPI dengan titik perjalanan aktif untuk melibatkan/melepaskan kipas angin.

    Kerangka kerja termal Windows mendukung perangkat pendingin aktif pada tingkat yang sangat dasar. Satu-satunya kotak masuk yang didukung perangkat adalah kipas ACPI, dan hanya dapat dikontrol dengan sinyal aktif/mati.

  • Terapkan solusi kepemilikan untuk mengontrol kipas angin (melalui driver, pengontrol tertanam, dll.).

    Meskipun Windows tidak mengontrol perilaku solusi kepemilikan untuk penggemar, Windows mendukung pemberitahuan kipas ke manajer termal untuk semua implementasi termasuk pengontrol yang disematkan sehingga informasi diagnostik dan telemetri dapat dikumpulkan. Dengan demikian paparan kipas ke sistem operasi diperlukan untuk semua PC Siaga Modern dan sangat direkomendasikan untuk semua yang lain.

Perhatikan bahwa implementasi untuk pendinginan aktif benar-benar terpisah dari mitigasi pendinginan pasif yang sebelumnya dibahas.

Kontrol kipas menurut zona termal ACPI

Windows mendukung definisi kipas berbasis status ACPI 1.0 D. (Untuk informasi selengkapnya, lihat spesifikasi ACPI.) Dengan demikian, kontrol terbatas pada kipas hidup dan mati. Driver untuk kipas disediakan di driver Windows ACPI, Acpi.sys.

  1. Sensor suhu membaca suhu telah melewati titik perjalanan dan mengeluarkan Notify (0x80) pada zona termal terkait.
  2. Zona termal membaca suhu dengan metode kontrol _TMP dan membandingkan suhu dengan titik perjalanan aktif (_ACx) untuk memutuskan apakah kipas perlu menyala atau mati.
  3. Sistem operasi menempatkan perangkat kipas di D0 atau D3 yang menyebabkan kipas menyala atau mati.

Diagram blok berikut menunjukkan alur kontrol untuk kipas yang dikontrol oleh zona termal ACPI.

alur kontrol untuk kipas yang dikendalikan oleh zona termal acpi 

Scope(\_SB) {
    Device(FAN) {
        Name(_HID, EISAID("PNP0C0B"))
        // additional methods to turn the fan on/off (_PR0, etc.)
    }

    ThermalZone(TZ0) {
        Method(_TMP) {...}
        Name(_AC0, 3200)
        Name(_AL0, Package() {\_SB.FAN})
    }
}

Kipas multi-kecepatan di ACPI

Untuk mencapai beberapa kecepatan untuk kipas angin menggunakan ACPI 1.0, ada dua opsi:

  • Zona termal dapat berisi beberapa "kipas", ketika hanya ada satu kipas fisik. Memiliki lebih banyak "penggemar" pada satu waktu diterjemahkan ke kecepatan kipas yang lebih cepat. Untuk informasi selengkapnya, lihat contoh opsi ini di Bagian 11.7.2 dalam spesifikasi ACPI 5.0.
  • Ketika kipas angin menyala, itu dapat memutuskan sendiri seberapa cepat berputar. Sistem dengan pengontrol yang disematkan, misalnya, dapat memilih opsi ini.

Solusi kepemilikan untuk penggemar

Windows harus dapat mendeteksi aktivitas kipas dengan salah satu implementasi. Ketika platform menggunakan model termal ACPI, Windows bertanggung jawab untuk mengaktifkan dan menonaktifkan kipas dan karena itu sudah tahu kapan aktif. Ketika solusi kepemilikan digunakan untuk mengontrol kipas, Windows memerlukan pemberitahuan bahwa kipas sedang berjalan. Untuk mengaktifkan ini, Windows akan mendukung sebagian subset ekstensi kipas ACPI 4.0, yang tercantum dalam tabel berikut.

Fitur Deskripsi Didukung
_FST Mengembalikan status kipas. ya
Beri tahu(0x80) Menunjukkan status kipas telah berubah. ya
_FIF Mengembalikan informasi perangkat kipas. tidak
_FPS Mengembalikan daftar status performa kipas. tidak
_FSL Mengatur status performa kipas (kecepatan). tidak

Windows akan menggunakan objek _FST untuk menentukan apakah kipas berjalan (bidang Kontrol bukan nol) atau nonzero (Bidang kontrol nol). Windows juga akan mendukung Notify(0x80) pada perangkat kipas sebagai indikasi bahwa _FST telah berubah dan perlu dievaluasi ulang.

Kipas yang mengimplementasikan objek _FST tidak diharuskan berada dalam daftar perangkat _ALx zona termal, tetapi dapat, sebagai opsi, berada dalam daftar ini. Opsi ini memungkinkan solusi hibrid di mana kipas biasanya dikendalikan oleh driver pihak ketiga, tetapi dapat dikontrol oleh zona termal OS jika driver pihak ketiga tidak diinstal. Jika kipas berada dalam daftar perangkat _ALx dan dilibatkan oleh zona termal (ditempatkan di D0), objek _FST diperlukan untuk menunjukkan nilai Kontrol bukan nol.

Untuk semua kipas, Windows akan menggunakan algoritma berikut menentukan status kipas angin:

  1. Jika kipas berada di D0 (sebagai akibat dari titik perjalanan _ACx zona termal yang dilintasi), maka akan diaktifkan.
  2. Jika kipas berada di D3 dan tidak mendukung ekstensi ACPI 4.0, maka akan dilepaskan.
  3. Jika kipas berada di D3 dan mendukung ekstensi ACPI 4.0, sistem operasi akan memeriksa bidang Kontrol _FST untuk nilai bukan nol untuk melihat apakah kipas terlibat.

Contoh 1: Kontrol kipas perangkat keras

Dalam contoh ini, kipas dikendalikan oleh pengontrol tertanam.

  1. Pengontrol yang disematkan memutuskan untuk memulai atau menghentikan kipas berdasarkan algoritma internalnya sendiri.
  2. Setelah memulai atau menghentikan kipas, pengontrol yang disematkan mengeluarkan Notify(0x80) pada perangkat kipas.
  3. Sistem operasi mengevaluasi _FST dan membaca status baru kipas angin.

Diagram blok berikut menunjukkan alur kontrol untuk kipas yang dikontrol oleh pengontrol tertanam.

alur kontrol untuk kipas yang dikontrol oleh pengontrol tertanam

Contoh ASL berikut mendefinisikan perangkat "FAN" yang dapat memberi tahu sistem operasi perubahan dalam status kipas:

Scope(\_SB) {
    Device(FAN) {
        Name(_HID, EISAID("PNP0C0B"))
        Name(_FST, Package() {0, 0, 0xffffffff})

        // \_SB.FAN.SFST called by EC event handler upon fan status change
        Method(SFST, 1) {
            // Arg0 contains the new fan status
            Store(Arg0, Index(_FST, 1))
            Notify(\_SB.FAN, 0x80)
        }
    }

    // Omitted: EC event handler
}

Contoh 2: Kontrol kipas driver

Dalam contoh ini, driver pihak ketiga mengontrol kipas angin.

  1. Driver memutuskan untuk memulai atau menghentikan kipas berdasarkan algoritma internalnya sendiri.
  2. Driver memodifikasi status kipas dan mengevaluasi metode kontrol kustom (SFST) pada perangkat termalnya.
  3. Metode kontrol perangkat termal memperbarui konten _FST perangkat kipas dan masalah Beri tahu (0x80) pada perangkat kipas.
  4. Sistem operasi mengevaluasi _FST dan membaca status baru kipas angin.

Diagram blok berikut menunjukkan alur kontrol untuk kipas yang dikendalikan oleh driver pihak ketiga.

alur kontrol untuk kipas yang dikendalikan oleh driver pihak ketiga 

Scope(\_SB) {
    Device(FAN) {
        Name(_HID, EISAID("PNP0C0B"))
        Name(_FST, Package() {0, 0, 0xffffffff})
    }

    Device(THML) {
        Name(_HID, "FBKM0001")
        Method(SFST, 1) {
            // Arg0 contains the new fan status
            Store(Arg0, Index(\_SB.FAN._FST, 1))
            Notify(\_SB.FAN, 0x80)
        }
    }
}

Kehadiran kipas

Platform menunjukkan bahwa ada kipas pada sistem dengan menyertakan perangkat kipas (PnP ID PNP0C0B) di namespace ACPI. Windows akan mengambil kehadiran perangkat ini sebagai indikasi bahwa sistem memiliki kipas angin, dan tidak adanya perangkat ini sebagai indikasi bahwa sistem tidak memiliki kipas angin.

Panduan khusus untuk Siaga Modern

Kerangka kerja manajemen termal Windows adalah bagian dari kernel dan pengiriman dengan semua sistem Windows. Dengan demikian, bahan di atas berlaku untuk semua mesin. Namun, berbagai jenis mesin memerlukan panduan tambahan yang lebih spesifik untuk Siaga Modern.

Modern Standby menghadirkan model daya ponsel pintar ke PC. Ini memberikan pengalaman pengguna instan dan instan yang diharapkan pengguna di ponsel mereka. Dan sama seperti di ponsel, Modern Standby memungkinkan sistem untuk tetap segar, terbaru, dan dapat dijangkau setiap kali jaringan yang sesuai tersedia. Windows 10 mendukung Modern Standby pada platform berdaya rendah yang memenuhi persyaratan sertifikasi Windows tertentu.

PC Siaga Modern adalah perangkat yang sangat seluler dalam bentuk tipis dan ringan. Selanjutnya, PC Siaga Modern selalu aktif dan dalam status ACPI S0. Untuk memberikan pengalaman pelanggan yang kuat dan andal, seluruh sistem — dari desain mekanis hingga implementasi firmware dan perangkat lunak — harus dirancang dengan perhatian penting terhadap karakteristik termal. Dengan demikian, semua PC Siaga Modern harus mematuhi persyaratan termal.

Persyaratan Siaga Modern

Semua PC Siaga Modern harus lulus tes HCK berikut:

  • Semua PC Siaga Modern harus memiliki setidaknya satu zona termal tempat suhu matikan kritis (_CRT) ditentukan. Untuk sistem x86, sebaiknya tentukan suhu hibernasi kritis (_HOT) untuk memicu penghematan data pengguna. _HOT harus lebih rendah dari _CRT, dan _CRT harus lebih rendah dari titik perjalanan termal firmware yang gagal aman.
  • Setiap zona termal harus melaporkan suhu aktual pada sensor (_TMP). Pengujian menjalankan berbagai beban kerja pada PC, dan suhu diperkirakan akan berubah.

Selain itu, kami sarankan setiap PC menyertakan setidaknya satu sensor suhu untuk SoC.

Persyaratan pendinginan aktif

PC Siaga Modern yang menggunakan kipas harus mematuhi persyaratan tambahan berikut, yang diuji dalam HCK:

  • Kipas harus diekspos ke sistem operasi. Untuk informasi selengkapnya, lihat Kehadiran penggemar.
  • Sistem operasi harus tahu setiap saat apakah kipas menyala atau nonaktif. Bahkan saat dalam ketahanan diam di Siaga Modern, setiap perubahan aktivitas kipas harus membangunkan SoC untuk memperbarui status. Untuk informasi selengkapnya tentang menerapkan pemberitahuan kipas, lihat Kontrol kipas oleh zona termal ACPI.
  • Kipas angin tidak boleh menyala saat PC dalam Mode Siaga Modern. Dengan beban kerja yang realistis selama Siaga Modern, yang setiap kali layar dimatikan, kipas tidak boleh menyala.

Dari perspektif pengguna, PC tampaknya dimatikan saat berada di Siaga Modern. Pengguna mengharapkan PC dalam Siaga Modern bersifat seolah-olah berada dalam status "tidur" sistem. Dengan demikian, pengguna mengharapkan kipas untuk tidak pernah datang, sama seperti pada PC tradisional selama tidur. Jika kipas angin datang, pengguna mungkin mendengarnya dan/atau merasakan udara panas beredar dan berpikir bahwa komputer tidak berfungsi dengan benar. Oleh karena itu, kipas tidak boleh menyala saat berada di Siaga Modern. Untuk informasi selengkapnya tentang perilaku yang diperlukan, lihat Persyaratan pengujian HCK untuk PC siaga modern.

Persyaratan ini menyiratkan bahwa kebijakan pendinginan saat layar diaktifkan mungkin harus berbeda dari saat layar dimatikan. PC mungkin menggunakan pendinginan aktif saat layar menyala, tetapi hanya harus mengandalkan pendinginan pasif saat layar mati. Titik perjalanan aktif untuk kipas mungkin jauh lebih rendah ketika layar menyala daripada saat mati. Untuk implementasi ACPI, _ACx harus diperbarui pada entri ke Modern Standby. Untuk solusi kepemilikan, pastikan untuk memperbarui kebijakan di pengontrol yang disematkan.

Pembatasan prosesor

PPM mengomunikasikan tingkat performa maksimum, diinginkan, dan minimal ke PEP. Dalam kondisi pembatasan termal, tingkat performa maksimum harus sama dengan performa pembatasan yang diminta oleh manajer termal. PEP kemudian menetapkan tegangan fisik dan frekuensi CPU berdasarkan persyaratan tingkat performa PPM.


Sinyal Kebisingan Kipas

Mulai dari Windows 11, perangkat dapat mengirim sinyal kebisingan kipas ke OS untuk digunakan dalam keputusan manajemen sumber daya, dengan tujuan memberi pengguna pengalaman yang dingin dan tenang. Antarmuka keikutsertaan ini memungkinkan firmware untuk mengirim informasi RPM kipas ke OS sebagai nilai dari 0 (kipas nonaktif) ke MAX RPM, yang dapat digunakan OS dalam keputusan manajemen sumber daya untuk mendinginkan perangkat sesuai kebutuhan. Ini berkontribusi pada dua manfaat utama:

  1. Pengalaman Pengguna Yang Tenang: Kebisingan kipas dan hembusan udara panas adalah sumber ketidakpuasan pelanggan yang signifikan. Ini terutama berlaku ketika pengguna tidak mengharapkan aktivitas kipas berat, seperti ketika perangkat menjalankan jumlah pekerjaan yang rendah atau tidak ada pekerjaan latar depan.
  2. Peningkatan Masa Pakai Baterai: Kecepatan kipas yang lebih tinggi menghasilkan lebih banyak penggunaan daya, yang menyebabkan pengosongan baterai yang lebih cepat saat berada di DC dan pengisian daya yang lebih lambat saat menggunakan AC.

Saat ini, sinyal ini dapat digunakan untuk mengelola tugas Pengindeks Pencarian, dan ada rencana untuk mengaktifkan tugas latar belakang tambahan untuk menggunakan sinyal ini juga.

Diagram berikut merangkum bagaimana sinyal kebisingan kipas dikirim di lapisan dari firmware ke perangkat lunak.

Diagram yang meringkas bagaimana sinyal kebisingan kipas dikirim dari firmware ke perangkat lunak

Cara Kerja Sinyal Kebisingan Kipas

Detail Antarmuka ACPI

Di bawah ini adalah empat fungsi Metode Spesifik Perangkat (_DSM, UUID: A7611840-99FE-41ae-A488-35C75926C8EB) yang digunakan untuk mendukung fitur ini. Informasi tentang _FST (Status Kipas) dapat ditemukan pada bagian 11.3.1.4 spesifikasi ACPI dan di Contoh 1: Kontrol kipas perangkat keras dari Perangkat Terkelola Termal

Diagram berikut ini meringkas alur bagaimana fungsi-fungsi ini digunakan.

Diagram meringkas alur penggunaan fungsi-fungsi ini.

Diagram blok berikut menunjukkan alur kontrol untuk kipas yang dikontrol oleh pengontrol tertanam, termasuk metode kontrol Beri tahu(0x80).

Catatan

Fan Noise Signal tidak akan mengontrol FAN RPM tetapi sebaliknya memberi tahu OS ada kebisingan kipas yang mengharuskan pemindahan sumber daya CPU dari tugas latar belakang untuk menyelesaikan pekerjaan prioritas.

Alur kontrol kipas


Menghitung Fungsi (Fungsi 0)

Agar sistem operasi berinteraksi dengan platform, perangkat ACPI harus diekspos melalui Namespace. Perangkat ini harus menyertakan objek _CID yang berisi EISAID("PNP0C0B"). Cakupan perangkat ini harus berisi definisi _DSM berikut yang menunjukkan _DSMs yang didukung perangkat.

UUID Revisi Fungsi Deskripsi

A7611840-99FE-41ae-A488-35C75926C8EB

0

0

Menghitung fungsi

Kembali: Untuk menunjukkan dukungan untuk fungsi 0 hingga 3 yang tercantum di atas, fungsi Enumerate Functions (fungsi 0) harus mengembalikan 0xF. Silakan merujuk ke bagian 9.1.1 dari spesifikasi ACPI untuk informasi lebih lanjut.


Dapatkan Fungsi Dukungan Titik Perjalanan Kipas (Fungsi 1)

Perangkat keras memberi tahu OS apa yang didukung dalam hal RPM.

UUID Revisi Fungsi Deskripsi

A7611840-99FE-41ae-A488-35C75926C8EB

0

1

Dapatkan dukungan titik perjalanan kipas

Argumen

Arg0: UUID: A7611840-99FE-41ae-A488- 35C75926C8EB

Arg1: Revisi: 0

Arg2: Fungsi: 1

Arg3: Paket kosong


Kembali: Nilai bilangan bulat yang berisi granularitas yang didukung untuk titik perjalanan kipas, dalam RPM. Jika bukan nol, OS dapat memilih titik perjalanan yang merupakan kelipatan granularitas pemberitahuan. Misalnya, dengan granularitas 200, OSPM akan diizinkan untuk memilih titik perjalanan di 0, 200, 400, 600, dll. Rpm. Nilai 0 menunjukkan titik perjalanan tidak didukung.


Mengatur Fungsi Titik Perjalanan Kipas (Fungsi 2)

OS berkomunikasi ke perangkat keras apa titik perjalanan pemberitahuan berikutnya; perangkat keras memberi tahu OS ketika itu terjadi.

UUID Revisi Fungsi Deskripsi

A7611840-99FE-41ae-A488-35C75926C8EB

0

2

Dapatkan poin perjalanan penggemar

Argumen

Arg0: UUID: A7611840-99FE-41ae-A488-35C75926C8EB

Arg1: Revisi: 0

Arg2: Fungsi: 2

Arg3: Paket yang berisi titik perjalanan bawah dan atas. (2 elemen int. Lebih rendah pada indeks 0, Atas pada indeks 1)

OSPM hanya akan memilih titik perjalanan yang merupakan kelipatan granularitas titik perjalanan yang ditentukan dalam fungsi 1. Ketika kecepatan kipas yang sebenarnya berada di atas atau di bawah titik perjalanan atas/bawah, platform harus mengeluarkan Notify (0x80) pada perangkat kipas. OSPM kemudian akan mengevaluasi _FST (Status kipas) untuk menentukan kecepatan kipas saat ini. Jika kecepatan kipas sudah berada di luar titik perjalanan yang ditentukan saat titik perjalanan ditetapkan, platform harus segera mengeluarkan Pemberitahuan (0x80).

Titik perjalanan atas akan menjadi kelipatan granularitas. Titik perjalanan yang lebih rendah adalah (kelipatan granularitas) + 1 (titik perjalanan lebih rendah titik < perjalanan atas). Ketika RPM adalah 0, OS akan mengatur titik perjalanan yang lebih rendah ke 0, dan titik perjalanan atas ke 1.

Kembali: Tidak.


Mendapatkan Fungsi Rentang Operasi Kipas (Fungsi 3)

Pemetaan antara RPM –> Dampak. Harap dicatat bahwa hanya satu kipas (yang paling dekat dengan SoC) yang dapat mengimplementasikan antarmuka ini, itu harus mengimplementasikan semua 3 fungsi ditambah fungsi 0 dari bagian 9.1.1 dari spesifikasi ACPI.

UUID Revisi Fungsi Deskripsi

A7611840-99FE-41ae-A488-35C75926C8EB

0

3

Mendapatkan rentang operasi kipas

Argumen

Arg0: UUID: A7611840-99FE-41ae-A488-35C75926C8EB

Arg1: Revisi: 0

Arg2: Fungsi: 3

Arg3: Paket kosong.

Kembali: Paket yang berisi format berikut:

Package () {
	Impact1MaxRPM,		// Integer (DWORD)
	Impact2MaxRPM, 		// Integer (DWORD)
	Impact3MaxRPM, 		// Integer (DWORD)
	MaxRPM				// Integer (DWORD)
}
Bidang Format Deskripsi

Impact1MaxRPM

Bilangan bulat (DWORD)

RPM maksimum untuk rentang dampak kipas 1.

Impact2MaxRPM

Bilangan bulat (DWORD)

RPM maksimum untuk rentang dampak kipas 2. Harus >= Impact1MaxRPM.

Impact3MaxRPM

Bilangan bulat (DWORD)

RPM maksimum untuk rentang dampak kipas 3. Harus >= Impact2MaxRPM.

MaxRPM

Bilangan bulat (DWORD)

RPM maksimum yang dapat dioperasikan kipas angin. Harus >= Impact3MaxRPM.

Tabel ini digunakan untuk memperoleh rentang RPM untuk setiap tingkat dampak kipas:

Skor Dampak Nilai RPM Yang Lebih Rendah Nilai RPM Atas

1

1

Impact1MaxRPM

2

Impact1MaxRPM + 1

Impact2MaxRPM.

3

Impact2MaxRPM + 1

Impact3MaxRPM

4

Impact3MaxRPM + 1

MaxRPM

Jika rentang dampak tidak digunakan oleh platform (misalnya, jika kipas beralih langsung dari rentang dampak 2 ke rentang dampak 4), itu dapat menunjukkan hal ini dengan mengatur RPM Maks untuk rentang dampak yang tidak digunakan sama dengan RPM maks untuk rentang dampak yang lebih rendah.

Contoh Pemetaan

Nilai Dikirim ke OS KIPAS RPM Pengalaman pengguna Langit-langit RPM

0 – Rendah

1-4000 RPM (<=25 dBA)

Kipas tidak aktif atau aktif dengan gangguan rendah

Impact1MaxRPM = 4000

1 – Sedang

4001-5000 RPM (25-30 dBA)

Kipas dengan gangguan sedang

Impact2MaxRPM = 5000

2 – Medium-High

5001-6000 RPM (30-36 dBA)

Kipas dengan gangguan sedang-tinggi

Impact3MaxRPM = 6000

3 – Tinggi

6001+ RPM (36+ dBA)

Kipas dengan gangguan tinggi

MaxRPM = 9000

Contoh Kode ASL

    ...
 
    // _DSM - Device Specific Method
    // Arg0: UUID Unique function identifier
    // Arg1: Integer Revision Level
    // Arg2: Integer Function Index (0 = Return Supported Functions)
    // Arg3: Package Parameters
    Method(_DSM, 0x4, NotSerialized) {
            If(LEqual(Arg0, ToUUID("A7611840-99FE-41ae-A488-35C75926C8EB"))) {
                Switch (ToInteger(Arg2)) {
                    Case(0) {
                        // _DSM functions 0 through 3 are supported
                        Return (Buffer() {0xf})
                    }
                    Case(1) {
                        // Report 200 RPM granularity for trip points
                        Return (\_SB.FAN0.GRAN)
                    }
                    Case(2) {
                        // Save lower RPM trip point
                        Store(DeRefOf(Index(Arg3, 0)), \_SB.FAN0.LRPM)
                        // Save upper RPM trip point
                        Store(DeRefOf(Index(Arg3, 1)), \_SB.FAN0.URPM)
                        // Configure hardware for the trip points, Tell EC to set fan speed trip point.
                        \_SB.FAN0.CRNF()
                        Return (0)
                    }
                    Case(3) {
                        Return (Package(4) { 
                            4000, // 1-4000 RPM is impact score 1
                            5000, // 4001-5000 RPM is impact score 2
                            6000, // 5001-6000 RPM is impact score 3
                            9000})// 6001-9000 RPM is impact score 4
                    }
                    Default {
                        Return(Buffer(One) { 0x00 }) // Guid mismatch
                    }
                }
            }
            Else {
                Return(Buffer(One) { 0x00 }) // Guid mismatch
            }
    }  
 
} // end of FAN0
}

Pengujian dan Pelacakan

Silakan referensikan langkah-langkah berikut untuk mengumpulkan log dan melihat di Windows Penganalisis Kinerja (WPA):

  1. Pengaturan -> Mencari Windows -> Pengaturan Pengindeks Pencarian Tingkat Lanjut -> Tingkat Lanjut -> Menghapus dan membangun ulang indeks (Membangun Ulang)
  2. wpr -boottrace -addboot AcpiFanNoiseImpact.wprp –filemode
  3. Menghidupkan ulang sistem
  4. Periksa Status indeks Pengaturan -> Mencari Windows (pastikan perangkat tersambung dengan sumber daya AC.)
  5. Ketika indeks selesai, hentikan jejak: wpr -boottrace -stopboot AcpiFanNoiseImpact.etl (Batalkan pelacakan tanpa menyimpan: wpr -boottrace –cancel)
  6. Buka AcpiFanNoiseImpact.etl melalui Windows Penganalisis Kinerja (WPA).

Opsi Pengindeksan

Unduh file di AcpiFanNoiseImpact.zip Atau, salin yang berikut ini dan simpan sebagai AcpiFanNoiseImpact.wprp

<?xml version="1.0" encoding="utf-8"?>
<WindowsPerformanceRecorder Version="1.0" Comments="Test" Company="Microsoft Corporation" Copyright="Microsoft Corporation">
    <Profiles>
        <!-- BufferSizes are in KB in WPRP -->
        <!-- System Collectors -->
        <SystemCollector Id="MySystemCollector" Name="NT Kernel Logger">
            <BufferSize Value="1024" />
            <Buffers Value="100" />
            <StackCaching BucketCount="2048" CacheSize="20480" />
            <FlushThreshold Value="70" />
        </SystemCollector>

        <!-- Event Collectors -->
        <EventCollector Id="MyEventCollector" Name="User Session Logger">
            <BufferSize Value="1024" />
            <Buffers Value="100" />
            <StackCaching BucketCount="2048" CacheSize="20480" />
            <FlushThreshold Value="70" />
        </EventCollector>

        <!-- System Providers for collecting kernel events. -->
        <SystemProvider Id="SP_AcpiFanNoiseImpactTrace">
            <Keywords Operation="Add">
                <Keyword Value="Loader" />
                <Keyword Value="Power" />
                <Keyword Value="ProcessThread" />
            </Keywords>
        </SystemProvider>
        <!-- System Providers for collecting kernel events. -->
        <!---->

        <EventProvider Id="EP_Microsoft-Windows-Kernel-Power" Name="Microsoft-Windows-Kernel-Power" Level="5" NonPagedMemory="true">
            <Keywords>
                <Keyword Value="0x2" />
            </Keywords>
            <CaptureStateOnStart>
                <Keyword Value="0x0" />
            </CaptureStateOnStart>
            <CaptureStateOnSave>
                <Keyword Value="0x0" />
            </CaptureStateOnSave>
        </EventProvider>
        <EventProvider Id="EP_Microsoft-Windows-Kernel-Acpi" Name="Microsoft-Windows-Kernel-Acpi" Level="5">
            <Keywords>
                <Keyword Value="0xffffffff" />
            </Keywords>
            <CaptureStateOnSave>
                <Keyword Value="0xffffffff" />
            </CaptureStateOnSave>
        </EventProvider>
        <EventProvider Id="CustomEventProvider_Microsoft.Windows.SRUM.Telemetry_TraceLogging" Name="7073707A-0587-4E03-B31F-6443EB1ACBCD" Level="5" />
        <EventProvider Id="CustomEventProvider_Microsoft.Windows.Kernel.Acpi_TraceLogging" Name="C42BBFDB-4140-4ada-81DF-2B9A18AC6A7B" Level="5" />
        <EventProvider Id="CustomEventProvider_Microsoft.Windows.Kernel.Power_TraceLogging" Name="63bca7a1-77ec-4ea7-95d0-98d3f0c0ebf7" Level="5" />
        <EventProvider Id="CustomEventProvider_AcpiTraceGuid_WPP" Name="03906A40-CCE8-447F-83F4-E2346215DB84" Level="7" />
        <EventProvider Id="CustomEventProvider_Microsoft.Windows.CentralResourceManager_TraceLogging" Name="8215e965-d26e-548e-af0e-940c1f06f250" Level="5" NonPagedMemory="true">
            <CaptureStateOnSave>
                <Keyword Value="0xFFFFFFFFFFFFFFFF" />
            </CaptureStateOnSave>
        </EventProvider>

        <Profile Id="PowerTrace.Verbose.File" LoggingMode="File" Name="PowerTrace" DetailLevel="Verbose" Description="Power trace logging">
            <Collectors>
                <SystemCollectorId Value="MySystemCollector">
                    <SystemProviderId Value="SP_AcpiFanNoiseImpactTrace" />
                </SystemCollectorId>
                <EventCollectorId Value="MyEventCollector">
                    <EventProviders>
                        <EventProviderId Value="EP_Microsoft-Windows-Kernel-Power" />
                        <EventProviderId Value="EP_Microsoft-Windows-Kernel-Acpi" />
                        <EventProviderId Value="CustomEventProvider_Microsoft.Windows.Kernel.Acpi_TraceLogging" />
                        <EventProviderId Value="CustomEventProvider_AcpiTraceGuid_WPP" />
                        <EventProviderId Value="CustomEventProvider_Microsoft.Windows.Kernel.Power_TraceLogging" />
                        <EventProviderId Value="CustomEventProvider_Microsoft.Windows.SRUM.Telemetry_TraceLogging" />
                        <EventProviderId Value="CustomEventProvider_Microsoft.Windows.CentralResourceManager_TraceLogging" />
                    </EventProviders>
                </EventCollectorId>
            </Collectors>
        </Profile>
    </Profiles>
    <TraceMergeProperties>
        <TraceMergeProperty Id="TraceMerge_Default" Name="TraceMerge_Default" Base="">
            <DeletePreMergedTraceFiles Value="true" />
            <FileCompression Value="true" />
            <CustomEvents>
                <CustomEvent Value="ImageId" />
                <CustomEvent Value="BuildInfo" />
                <CustomEvent Value="VolumeMapping" />
                <CustomEvent Value="EventMetadata" />
                <CustomEvent Value="PerfTrackMetadata" />
                <CustomEvent Value="WinSAT" />
                <CustomEvent Value="NetworkInterface" />
            </CustomEvents>
        </TraceMergeProperty>
    </TraceMergeProperties>
</WindowsPerformanceRecorder>

Gambar di bawah ini adalah contoh grafik WPA yang menunjukkan pekerjaan Pengindeks Pencarian mundur saat kipas keras.

Pekerjaan Latar Belakang WPA

Ada satu tingkat kipas angin yang akan membuat indeks pencarian mundur secara penuh (tertinggi, yang seharusnya berdampak pada skor 4), tetapi semua tingkat kipas lain harus dikurangi aktivitas dan bukan penangguhan. Misalnya, jika ACPI menyatakan Impact3MaxRPM = 4000 RPM dalam fungsi 3 (Dapatkan fungsi rentang operasi kipas), ketika Fan RPM > 4000 (4100RPM, 4500RPM), kita akan melihat SearchIndexer.exe dan SearchProtocalHost.exe Penggunaan CPU akan ditangguhkan.

Catatan

Untuk melihat Penggunaan CPU, Anda dapat menggunakan wpr -start power -filemode untuk mengumpulkan penggunaan runtime. Gunakan wpr -stop fan_noise.etl untuk berhenti mengumpulkan log.

Gambar di bawah ini menunjukkan contoh grafik WPA yang menunjukkan penangguhan SearchIndexer.exe dan SearchProtocolHost

Penangguhan WPA