sched_setscheduler(2) dan teman-teman memungkinkan Anda untuk menggunakan dua penjadwal soft real-time yang berbeda, SCHED_FIFO SCHED_RR. Proses yang berjalan di bawah penjadwal ini diprioritaskan lebih tinggi daripada proses biasa. Jadi, selama Anda hanya memiliki beberapa proses ini, dan mengontrol prioritas di antara proses tersebut, Anda benar-benar bisa mendapatkan respons real-time yang bagus.
Seperti yang diminta dalam komentar, inilah perbedaan antara SCHED_FIFO dan SCHED_RR:
Dengan penjadwal "real-time", ada hingga 100 prioritas berbeda (POSIX hanya membutuhkan 32 level berbeda, jadi seseorang harus menggunakan sched_get_priority_min(2) dan sched_get_priority_max(2) untuk mendapatkan nomor aktual. Penjadwal keduanya bekerja dengan mendahului proses dan utas dengan prioritas lebih rendah, perbedaannya terletak pada cara mereka menangani tugas dengan prioritas yang sama.
SCHED_FIFO, adalah first in first out scheduler (sesuai namanya). Artinya, tugas yang mencapai antrean proses terlebih dahulu, diizinkan untuk dijalankan hingga selesai, secara sukarela memberikan ruangnya pada antrean proses, atau didahului oleh tugas dengan prioritas lebih tinggi.
SCHED_RR, adalah penjadwal round robin. Ini berarti bahwa tugas-tugas dengan prioritas yang sama hanya diperbolehkan berjalan untuk kuantum waktu tertentu. Jika tugas masih berjalan saat kuantum waktu ini habis, tugas akan didahului, dan tugas berikutnya dalam antrean proses (dengan prioritas yang sama) diizinkan berjalan hingga kuantum waktunya. Seperti SCHED_FIFO, tugas dengan prioritas lebih tinggi mendahului tugas dengan prioritas lebih rendah, namun, ketika tugas yang didahului oleh tugas berprioritas lebih tinggi diizinkan untuk dijalankan lagi, tugas tersebut hanya diizinkan untuk berjalan selama waktu yang tersisa dalam kuantumnya. Lihat bagian Noes di sched_rr_get_interval(2) untuk mengetahui cara menyetel kuantum waktu untuk suatu tugas.
MRG
Sub-milidetik akan sulit dijamin pada kernel non-RT. Saya tahu banyak pekerjaan yang sangat bagus telah terjadi selama beberapa tahun terakhir (mis. kunci kernel besar telah hilang), tetapi itu masih belum cukup untuk menjaminnya.
Anda dapat melihat Scientific Linux dari pengganggu atom yang ramah di CERN dan Fermilab. Itu dapat menginstal MRG (lihat tautan saya), yang memberi Anda pengaturan pra-paket patch PREEMPT_RT.
Atau jika Anda punya uang, Anda bisa mendapatkan Redhat MRG. Itu adalah distro Linux yang didukung penuh dengan patch PREEMPT-RT bawaan, sehingga akan menghilangkan masalah patching kernel.
Masalahnya, Redhat mengenakan biaya banyak untuk itu ($3000 PER TAHUN PER INSTALASI). Saya pikir mereka telah jatuh bahwa salah satu pelanggan terbesar untuk itu adalah investor perdagangan kecepatan tinggi yang masih mendapat $lots-and-lots sehingga tidak akan melihat $3000/kotak/tahun keluar pintu.
Bagaimana Saya Bekerja dengan MRG
Saya telah melakukan sedikit pekerjaan dengan MRG (menggunakan kedua hal di atas), dan itu cukup bagus. Ini menggantikan rutinitas layanan interupsi di kernel stok dengan utas untuk melayani interupsi. Itu berarti Anda dapat menjalankan perangkat lunak Anda dengan prioritas lebih tinggi daripada utas IRQ! Itulah hal yang harus Anda lakukan jika ingin mendekati penjaminan latensi sub-milidetik pada aplikasi Anda.
Tampaknya ada pergeseran bertahap dari hal-hal MRG ke dalam kernel arus utama, yang merupakan hal yang baik menurut saya. Mungkin suatu hari itu akan menjadi hal utama.
Gotcha lainnya
Manajemen termal CPU modern bisa sangat menyebalkan. Saya memiliki sistem yang terkunci selama 0,3 detik saat Interupsi Manajemen Sistem sedang diservis (oleh BIOS, bukan OS), hanya karena CPU memanas sedikit. Lihat ini. Jadi, Anda harus berhati-hati terhadap apa yang dilakukan perangkat keras dasar Anda. Umumnya Anda harus mulai khawatir tentang membuang pendinginan PC modern yang terkelola dan kembali ke kipas besar yang berputar cepat sepanjang waktu.
Anda bisa mendapatkan cukup jauh dengan Linux dengan menghapus 'gangguan' dari proses lain ke proses realtime. Saya bermain dengan hal yang sama di Windows, yang merupakan horor yang jauh lebih besar untuk dilakukan dengan benar, tetapi ini menunjukkan arahnya. Jadi semacam daftar periksa:
- Paling penting (aneh tapi nyata):perangkat keras. Jangan menggunakan laptop, ini akan dioptimalkan untuk melakukan hal-hal aneh selama interupsi SMM. Tidak ada yang dapat Anda lakukan.
- Driver:Linux (dan Windows) memiliki driver yang buruk dan driver yang baik. Terkait dengan perangkat keras. Dan hanya ada satu cara untuk mengetahuinya:pembandingan.
Isolasi dari sisa sistem, nonaktifkan semua berbagi:
- Isolasi satu CPU (
man cpuset). Buat dua set CPU, satu untuk proses normal, dan satu lagi untuk proses waktu nyata Anda. - Kurangi bagian waktu nyata dari kode Anda seminimal mungkin. Berkomunikasi dengan buffer besar dengan bagian lain dari sistem. Kurangi IO menjadi minimal (karena IO memiliki jaminan buruk).
- Jadikan proses memiliki prioritas waktu nyata (lunak) tertinggi.
- Nonaktifkan HyperThreading (Anda tidak ingin berbagi)
- alokasikan terlebih dahulu memori yang Anda perlukan, dan mlock() memori.
- Isolasi perangkat yang Anda gunakan. Mulailah dengan mengalokasikan IRQ khusus ke perangkat (pindahkan perangkat lain ke IRQ lain, atau hapus perangkat/driver lain).
- Isolasi IO yang Anda gunakan.
Kurangi aktivitas sisa sistem:
- hanya memulai proses yang benar-benar Anda butuhkan.
- hapus perangkat keras yang tidak Anda perlukan seperti disk dan perangkat keras lainnya.
- nonaktifkan pertukaran.
- jangan menggunakan modul kernel Linux atau memuatnya di depan. Init modul tidak dapat diprediksi.
- sebaiknya hapus pengguna juga :)
Jadikan itu stabil dan dapat direproduksi:
- nonaktifkan semua penghematan energi. Anda menginginkan kinerja yang sama sepanjang waktu.
- tinjau semua pengaturan BIOS, dan hapus semua 'eventing' dan 'sharing' darinya. Jadi, tidak ada speedsteps yang mewah, manajemen termal, dll. Pilih latensi rendah, jangan memilih hal-hal dengan nama 'meledak' karena umumnya memperdagangkan throughput untuk kinerja yang lebih buruk.
- tinjau setelan driver Linux, dan latensi lebih rendah (jika berlaku).
- gunakan kernel terbaru yang mencoba terlihat seperti kernel realtime setiap hari.
Dan kemudian benchmark, menggunakan stress testing dan membiarkan mesin menyala selama berhari-hari sambil merekam maks. latensi.
Jadi:semoga berhasil :)