Jaminan apa yang sebenarnya disediakan oleh sistem operasi "lunak" waktu nyata

Saya rasa saya tahu apa sistem operasi real-time yang "sulit". Ini adalah sistem operasi dengan penjadwal yang menyediakan kontrak dengan pemrogram aplikasi. Aplikasi menyediakan tenggat waktu dengan setiap permintaan alokasi sumber daya. Jika permintaan tenggat waktu layak , penjadwal menjamin bahwa setiap sumber daya akan dialokasikan untuk aplikasi yang meminta sebelum tenggat waktu. Jaminan cukup untuk memungkinkan pemrogram aplikasi untuk alasan tentang latensi maksimum dan throughput minimum permintaan tertentu.

Semua definisi yang saya temukan dari sistem waktu nyata "lunak" tampak kosong bagi saya. Wikipedia mengatakan

kegunaan hasil menurun setelah batas waktu, sehingga menurunkan kualitas layanan sistem.

Uhhhh. Baik. Dengan kriteria itu Windows 95 adalah sistem waktu nyata yang lunak dan begitu juga 3BSD dan begitu juga Linux. Wikipedia bukanlah sumber yang bagus, tetapi beberapa klik Google berikutnya tidak jauh lebih baik. Misalnya kata http://users.ece.cmu.edu/~koopman/des_s99/real_time/

Dalam sistem waktu nyata lunak, operasi terdegradasi dalam beban puncak yang jarang terjadi dapat ditoleransi.

Itu bukan kontrak, itu cara mewah untuk tidak mengatakan apa-apa.

Apa saja contoh jaminan / kontrak real-time lunak nyata yang ditawarkan oleh sistem operasi nyata?

Saya mencari jawaban dari formulir:

In (OS-name) jika programmer melakukan (what-programmer-needs-to-do) maka jaminan sistem operasi (what-the-system-guarantee).

Anda sudah melakukannya dengan benar, dan Wikipedia sama informatifnya seperti itu - soft real-time bukanlah karakterisasi formal, ini penilaian nilai. Cara lain untuk mengatakan "real-time lunak" adalah "Saya berharap itu real-time", atau mungkin lebih akurat "itu harus real-time tetapi itu terlalu sulit".

Jika Anda benar-benar ingin mengatakan dalam bentuk jaminan, itu adalah jaminan upaya terbaik daripada jaminan kinerja tertentu.

Atau, mengutip Erlang FAQ (Erlang adalah bahasa pemrograman yang awalnya dirancang untuk digunakan dalam telepon):

Apa arti soft realtime?

Sinis akan mengatakan "pada dasarnya tidak ada".

(...) Banyak sistem telekomunikasi memiliki persyaratan yang tidak terlalu ketat [daripada hard realtime], misalnya mereka mungkin memerlukan jaminan statistik sepanjang baris "pencarian database membutuhkan kurang dari 20 ms dalam 97% kasus". Sistem realtime lunak, seperti Erlang, memungkinkan Anda membuat jaminan semacam itu.

Dan ini memang memberikan definisi yang bermanfaat. Soft real-time menunjukkan desain yang dioptimalkan untuk setiap tugas individu yang mengambil tidak lebih dari jumlah waktu tertentu , daripada menuju mengoptimalkan total waktu yang dihabiskan untuk melakukan semua tugas. Misalnya, sistem waktu-nyata lunak akan bertujuan untuk menyelesaikan 99,9% dari permintaan dalam 10 ms dan memproses 100 permintaan per detik, di mana non-waktu-nyata mungkin bertujuan untuk memproses 200 permintaan per detik tetapi mengizinkan permintaan sesekali untuk memblokir untuk 50 ms atau lebih. Waktu-nyata yang sulit akan menjamin satu permintaan setiap 15 ms tidak peduli apa pun yang terjadi.

Soft real-time digunakan untuk aplikasi di mana tenggat waktu yang terlewat berarti penurunan layanan, tetapi tidak kritis terhadap kinerja. Multimedia dan telepon adalah beberapa kasus penggunaan yang umum. Setiap bingkai audio atau video harus diberikan waktu, atau harus dilewati; tetapi melewatkan bingkai bukanlah akhir dari dunia. Para perancang Erlang memiliki tujuan yang sama pada keandalan dalam hal-hal lain: mereka mengamati bahwa lebih baik bagi pertukaran telepon untuk sesekali menelpon, tetapi untuk benar-benar yakin bahwa pertukaran secara keseluruhan akan tetap bekerja apa pun yang terjadi, daripada untuk pernah menghadapi risiko kegagalan besar dalam mencoba mempertahankan koneksi dengan cara apa pun.

Sebaliknya, sesuatu seperti mengendalikan motor mengharuskan perangkat lunak tidak pernah melewatkan tenggat waktu. Ini berbiaya: kinerja keseluruhan biasanya lebih lambat, dan hanya perilaku yang relatif sederhana yang dapat dicapai. Di sisi lain spektrum, aplikasi angka-angka biasanya hanya peduli pada kinerja keseluruhan - yang penting adalah seberapa cepat matriks 1000x1000 dikalikan, bukan seberapa cepat setiap kolom dihitung.

Linux dengan patch -rt (real time) menyediakan penjadwal yang memberikan jaminan menarik yang tampaknya tidak kosong. (Meskipun saya tidak jelas tentang bagaimana jaminan dapat digunakan secara nyata.)

SCHED_FIFOKebijakan penjadwalan Linux-rt berfungsi sebagai berikut: Pengguna menetapkan prioritas untuk setiap proses. (Angka prioritas untuk proses "waktu nyata" adalah 0-99, dan nilai Unix tradisional nice-20 hingga 19 memetakan ke prioritas 100 hingga 139. (Jadi "0" adalah prioritas "tertinggi" dan "139" adalah "terendah" "prioritas.)

Jaminannya adalah bahwa setiap saat scheduler akan menjadwalkan Npekerjaan runnable prioritas tertinggi pada Nmesin prosesor. Rasa sakit telah diambil untuk menghindari masalah inversi prioritas di dalam kernel. Ketika proses Amenjadi runnable dan memiliki prioritas yang lebih tinggi daripada beberapa proses yang berjalan lainnya B, Aakan segera mendahului B.

Namun, perlu diketahui bahwa tidak ada jaminan waktu ketat yang diberikan. Waktu yang dihabiskan untuk melakukan preemption secara teoritis bisa lama. Juga, tampaknya ada beberapa cara di mana pekerjaan prioritas rendah dapat memulai sekelompok latensi panjang i / o. Ketika i / o menyelesaikan penangan interupsi untuk pekerjaan berprioritas rendah dapat mengganggu pekerjaan berprioritas lebih tinggi, yang, bisa dibilang, merupakan bentuk inversi prioritas.

Jadi jaminan terbatas yang diberikan adalah: jika ada satu proses dengan prioritas tertinggi, setiap kali dijalankan, itu akan mendapatkan semua sumber daya prosesor yang OS dapat berikan secara realistis. Jika Anda memiliki batas atas yang baik pada jumlah sumber daya prosesor yang dikonsumsi oleh proses prioritas tertinggi, Anda dapat menghitung perkiraan sumber daya yang cukup akurat yang akan tersedia untuk proses prioritas tertinggi kedua, dan seterusnya.

Artikel mendalam yang menggambarkan penjadwal waktu-nyata Linux adalah http://www.linuxjournal.com/magazine/real-time-linux-kernel-scheduler .

Untuk mendefinisikan "real-time lunak," paling mudah untuk membandingkannya dengan "real-time keras".

Berbicara dengan santai, kebanyakan orang secara implisit memiliki model mental informal yang menganggap informasi atau peristiwa sebagai "waktu nyata"

• jika, atau sejauh itu, itu nyata bagi mereka dengan penundaan (latensi) yang dapat terkait dengan mata uang yang dirasakannya

• yaitu, dalam kerangka waktu bahwa informasi atau peristiwa memiliki nilai memuaskan yang dapat diterima bagi mereka.

Ada banyak definisi ad hoc yang berbeda tentang "real-time yang sulit," tetapi dalam model mental itu, real-time yang keras diwakili oleh istilah "jika". Secara khusus, dengan asumsi bahwa tindakan waktu nyata (seperti tugas) memiliki tenggat waktu penyelesaian, nilai memuaskan yang memuaskan dari semua tugas yang diselesaikan terbatas pada kasus khusus di mana semua tugas memenuhi tenggat waktu mereka.

Sistem real-time yang sulit membuat asumsi yang sangat kuat bahwa segala sesuatu tentang aplikasi dan sistem dan lingkungan adalah statis dan dikenal sebagai 'apriori — misalnya, yang tugasnya, periodik, waktu kedatangan, periode, tenggat waktu, yang mereka menangkan tidak memiliki konflik sumber daya, dan keseluruhan evolusi waktu sistem. Dalam sistem kontrol penerbangan pesawat terbang atau sistem pengereman otomotif dan banyak kasus lainnya, asumsi tersebut biasanya dapat dipenuhi sehingga semua tenggat waktu dapat dipenuhi.

Model mental ini sengaja dan sangat berguna cukup umum untuk mencakup baik waktu nyata maupun keras - lunak diakomodasikan oleh frasa "sejauh" itu. Misalnya, anggap bahwa acara penyelesaian tugas memiliki nilai suboptimal tetapi dapat diterima jika

• tidak lebih dari 10% tugas yang melewati tenggat waktu
• atau tidak ada tugas yang lebih dari 20% terlambat
• atau keterlambatan rata-rata semua tugas tidak lebih dari 15%
• atau keterlambatan maksimum di antara semua tugas kurang dari 10%

Ini semua adalah contoh umum soft case waktu nyata dalam banyak sekali aplikasi.

Pertimbangkan aplikasi tugas tunggal untuk menjemput anak Anda sepulang sekolah. Itu mungkin tidak memiliki tenggat waktu yang sebenarnya, tetapi ada beberapa nilai untuk Anda dan anak Anda berdasarkan kapan peristiwa itu terjadi. Terlalu dini menyia-nyiakan sumber daya (seperti waktu Anda) dan terlambat memiliki nilai negatif karena anak Anda mungkin dibiarkan sendirian dan berpotensi membahayakan (atau setidaknya tidak nyaman).

Berbeda dengan hard case khusus statis real-time, soft real-time hanya membuat asumsi spesifik aplikasi minimum yang diperlukan tentang tugas dan sistem, dan ketidakpastian diharapkan. Untuk menjemput anak Anda, Anda harus pergi ke sekolah, dan waktu untuk melakukan itu dinamis tergantung pada cuaca, kondisi lalu lintas, dll. Anda mungkin tergoda untuk terlalu-menyediakan sistem Anda (yaitu, biarkan apa yang Anda harapkan adalah waktu mengemudi terburuk) tetapi sekali lagi ini adalah pemborosan sumber daya (waktu Anda, dan menempati kendaraan keluarga, mungkin menyangkal penggunaan oleh anggota keluarga lainnya).

Contoh itu mungkin tampaknya tidak mahal dalam hal sumber daya yang terbuang, tetapi pertimbangkan contoh lain. Semua sistem tempur militer lunak real-time. Misalnya, pertimbangkan untuk melakukan serangan pesawat pada kendaraan darat yang bermusuhan menggunakan rudal yang dipandu dengan pembaruan sebagai manuver target. Kepuasan maksimum untuk menyelesaikan tugas pembaruan kursus dicapai dengan serangan destruktif langsung pada target. Tetapi upaya untuk menyediakan sumber daya secara berlebihan untuk memastikan hasil ini biasanya terlalu mahal dan bahkan tidak mungkin dilakukan. Dalam hal ini, Anda mungkin kurang tetapi cukup puas jika rudal menyerang cukup dekat dengan target untuk menonaktifkannya.

Jelas skenario pertempuran memiliki banyak ketidakpastian dinamis yang mungkin harus diakomodasi oleh manajemen sumber daya. Sistem lunak real-time juga sangat umum di banyak sistem sipil, seperti otomasi industri, walaupun jelas sistem militer adalah yang paling berbahaya dan mendesak untuk mencapai nilai memuaskan yang dapat diterima di Indonesia.

Kunci dari sistem waktu nyata adalah "dapat diprediksi". Kasus sulit waktu nyata hanya tertarik pada satu kasus khusus yang dapat diprediksi - yaitu, bahwa semua tugas akan memenuhi tenggat waktu mereka dan nilai maksimum yang mungkin akan dicapai oleh peristiwa itu. Kasus khusus itu bernama "deterministik."

Ada spektrum prediktabilitas; sebagian besar sistem real-time (yaitu, yang lunak) memiliki prediktabilitas non-deterministik, misalnya, waktu penyelesaian tugas dan karenanya nilai yang diperoleh dari peristiwa tersebut. Secara umum, prediktabilitas, dan karenanya bernilai, dapat dibuat sedekat mungkin dengan titik akhir deterministik sebagaimana diperlukan tetapi dengan harga yang mungkin secara fisik tidak mungkin atau terlalu mahal (seperti dalam pertempuran atau mungkin bahkan dalam menjemput anak Anda dari sekolah).

Soft real-time membutuhkan pilihan spesifik aplikasi dari model probabilitas (bukan model frequentist umum) dan karenanya model prediktabilitas untuk alasan tentang latensi peristiwa dan nilai yang dihasilkan.

Mengacu kembali ke daftar peristiwa di atas yang memberikan nilai yang dapat diterima, sekarang kita dapat menambahkan kasus-kasus non-deterministik, seperti

• probabilitas bahwa tidak ada tugas yang akan melewati tenggat waktu lebih dari 5% lebih besar dari 0,87.

Dalam aplikasi pertahanan rudal, mengingat fakta bahwa dalam pertempuran pelanggaran selalu memiliki keunggulan dibandingkan pertahanan, yang mana dari dua skenario komputasi real-time yang akan Anda pilih:

• karena penghancuran sempurna dari semua rudal bermusuhan sangat tidak mungkin atau tidak mungkin, tetapkan sumber daya pertahanan Anda untuk memaksimalkan probabilitas bahwa banyak dari rudal bermusuhan yang paling mengancam (misalnya berdasarkan target mereka) akan berhasil dicegat (jumlah intersepsi dekat karena itu dapat memindahkan rudal bermusuhan di luar jalur);

• mengeluh bahwa ini bukan masalah komputasi waktu-nyata karena sifatnya dinamis bukan statis, dan konsep serta teknik waktu-nyata tradisional tidak berlaku, sehingga Anda tidak tertarik melakukan R&D untuk waktu-nyata lunak.

Terlepas dari berbagai kesalahpahaman tentang waktu nyata lunak dalam komunitas komputasi waktu nyata (tetapi tidak dalam bidang non-komputasi lainnya), waktu nyata lunak sangat umum dan kuat, dan berpotensi sangat kompleks dibandingkan dengan waktu nyata yang sulit.

Untuk langsung menjawab pertanyaan OP:

• sistem waktu-nyata yang keras dapat memberikan jaminan deterministik — paling umum bahwa semua tugas akan memenuhi tenggat waktu, interupsi atau waktu respons panggilan sistem akan selalu kurang dari x, dll. — JIKA DAN HANYA JIKA asumsi yang sangat kuat dibuat dan benar bahwa semua yang penting adalah statis dan dikenal sebagai 'apriori (secara umum, jaminan seperti itu untuk sistem waktu nyata yang sulit adalah masalah penelitian terbuka kecuali untuk kasus yang agak sederhana)

• sistem waktu nyata lunak tidak membuat jaminan deterministik, sistem ini dimaksudkan untuk memberikan ketepatan waktu probabilistik yang ditentukan secara analitis sebaik mungkin dan dapat diprediksi ketepatan waktu yang layak dalam keadaan dinamis saat ini, sesuai dengan kriteria spesifik aplikasi. Jelas real-time yang sulit adalah kasus khusus sederhana real-time yang lunak. Jaminan analitis non-deterministik real-time yang lunak dapat menjadi sangat kompleks untuk disediakan, tetapi wajib dalam kasus waktu-nyata yang paling umum (termasuk yang paling kritis terhadap keselamatan seperti pertempuran) karena kebanyakan kasus bersifat dinamis bukan statis.

Saya memiliki diskusi rinci yang jauh lebih tepat tentang waktu nyata, waktu nyata sulit, waktu nyata lunak, dapat diprediksi, determinisme, dan topik terkait di situs web saya real-time.org .