Penggunaan POSIX di Real-Time Sistem, Menaksir Efektivitas dan Performancenya

Sumber : http://testingimplementasi.wordpress.com/2008/12/12/penggunaan-posix-di-real-time-sistem/

POSIX, singkatan dari Portable Operating System Interface for UNIX, adalah sebuah standar yang dicetuskan oleh Institute of Electical and Electronics Engineers (IEEE) yang mendefinisikan sekumpulan layanan dalam sistem operasi. Program-program yang mendukung standar POSIX dapat secara mudah di-port dari satu sistem ke sistem lainnya. POSIX menjadi basis dalam layanan sistem operasi UNIX. Meskipun demikian, POSIX juga dibuat demikian agar sistem operasi lainnya dapat mengimplementasikan layanan POSIX. Standardisasi ini dilakukan sejak tahun 1985. Nomor standar formalnya adalah IEEE 1003 dan kemudian menjadi standar internasional menjadi ISO/IEC 9945. Istilah POSIX sendiri diusulkan oleh Richard Stallman, sebagai respons dari permintaan IEEE untuk nama yang mudah diingat.

POSIX menentukan antarmuka pengguna dan antarmuka perangkat lunak terhadap sistem operasi dalam 15 dokumen yang berbeda. Antarmuka pengguna standar dalam POSIX adalah Korn shell yang digunakan untuk memasukkan perintah command-line dan pembuatan skrip. Program-program pengguna lainnya juga dimasukkan ke dalam standar, seperti awk, echo, ed, dan ratusan program lainnya. POSIX juga mendefinisikan pustaka API standar untuk thread (POSIX Thread) yang banyak diimplementasikan di sistem operasi modern. Sementara itu, layanan-layanan level program yang dimasukkan ke dalam standar adalah input/output dasar (file, terminal, dan jaringan). POSIX juga mendefinisikan bagaimana melakukan pengujian terhadap sebuah aplikasi apakah mendukung POSIX atau tidak, yang disebut dengan POSIX Confirmance Test Suite (PCTS).

Berikut merupakan beberapa standar POSIX :

Standar-Posix

standar POSIX mempromosikan portabilitas aplikasi melalui platform sistem operasi yang berbeda. Ini penting untuk aplikasi yang dirancang untuk umur panjang, di mana infrastruktur perangkat keras dan lunak akan berubah sepanjang waktu. di dalam real-time sistem, di mana prediksi dan ongkos exploitasi rendah sangat penting, portabilitas sering dikorbankan. Di sini saya akan membahas penggunaan POSIX® di dalam real-time sistem, dan kemudian akan membahas testing performansi suatu real-time sistem operasi. kita menilai kegunaan POSIX di dalam real-time sistem dengan memperhatikan tiga faktor: ( functionality, performance, and availability) Sebab real-time sistem secara khas mempunyai batasan penekanan performansi ketat yang ditempatkan pada performansi implementasi POSIX. kita menggunakan benchmarks untuk mengukur performansi real-time sistem.

Real-time Systems

Suatu real-time sistem adalah satu di mana ketepatan waktu menyangkut hasil dari suatu kalkulasi itu penting. Contoh termasuk sistem senjata militer, sistem kontrol pabrik, dan Internet audio dan video streaming. Realtime sistem secara khas digolongkan ke dalam dua kelas: hard and soft. Di dalam suatu real-time sistem hard waktu deadline harus dijumpai atau hasil dari suatu kalkulasi invalid. . Internet audio/video streaming adalah suatu contoh dari suatu real-time sistem yang soft. Jika suatu paket data terlambat atau hilang audio/video mengalami degradasi, tetapi streaming mungkin tetap dapat didengar.

POSIX Real-time Related Standards

Posix-real-time-related-standard

dari standard 30 POSIX tujuh standard terdaftar di dalam Tabel 1 terutama relevan kepada pengembangan real-time dan embedded sistem. Dengan tiga standard yang pertama ( 1003.1a,1b,1c) disebut banyak support. Posix 1003.1a menggambarkan interface ke fungsi sistem operasi dasar, dan pertama untuk diadopsi pada 1990 . Real-Time extensions digambarkan dalam 1003.1b standard, 1003.1d, 1003.1j dan 1003.21 . Bagaimanapun, real-time extensions yang asli, digambarkan oleh 1003.1b, hanya standard biasanya diterapkan. Dukungan untuk multiple threads di dalam suatu proses disiapkan dalam bentuk suatu standard terpisah , POSIX 1003.1c. POSIX juga termasuk support untuk ketersediaan yang tinggi dalam standard 1003.1h .

Testing the Real-time Performance of Operating Systems

Benchmarks yang digunakan disini dibagi menjadi dua kategori: . yang mengukur determinisme OS dan . yang mengukur latency dari operasi yang penting tertentu. Benchmarks ini adalah termotivasi oleh real-time kebutuhan capaian. Benchmarks menguji inti kemampuan sistem operasi dan adalah tidak terikat pada manapun aplikasi yang nyata. Juga sebab kita tertarik di dalam menentukan kemungkinan terbaik real-time capaian itu, semua real-time menyusupkan adalah menabrak; menyerang yang maksimum real-time prioritas yang mungkin, dan memori sebetulnya yang digunakan oleh benchmarks dikunci ke dalam memori phisik.

Tabel dibawah ini meringkas enam benchmarks yang digunakan disini

Real-time benchmarks

Deterministic benchmarks

Tiga yang pertama benchmarks ditunjukkan di dalam diatas, ( Pengatur Waktu Jitter, Tanggapan, dan Bintime) dirancang untuk mengukurlah determinisme dari suatu sistem operasi . Sebab determinisme menyiratkan bahwa waktu melaksanakan suatu operasi yang diketahui, kita secara khas melaporkan yang terburuk waktu kasus untuk ini benchmarks.

Latency benchmarks

Tiga test sinkronisasi berbeda ditunjukkan di dalam Gambar dibawah. Dalam test pertama isyarat thread tunggal ( S) dan kemudian menunggu ( W) pada suatu semaphor. Test ini mengukur latency sistem semaphor panggil. Yang Kedua menguji semaphor penggunaan isyarat antara dua thread. thread adalah salah satu di dalam tunggal, atau dua berbeda proses. Pengukuran dari permulaan dua test dapat digunakan untuk menentukan konteks yang menswitch waktu oleh pengurangan mulai sistem panggil ongkos exploitasi, memperoleh di dalam test, dari separuh roundtrip waktu pemberian isyarat, yang diperoleh di dalam test dua.

Latency-Benchmark

Pesan menghantar benchmark menggunakan POSIX pesan antri untuk mengukur latency dan throughput perpindahan data antara dua thread dalam proses sama atau di dalam proses yang berbeda. Benchmark yang terakhir mengukurlah latency Posix real-time signal.

Benchmark Results

Benchmarks menggambarkan dalam bagian sebelumnya adalah dimajukan dua sistem operasi yang berbeda: Lynxos dan Solaris 8. Tabel dibawah mengidentifikasi tiga Solaris bentuk yang berbeda. Bentuk yang berbeda ini mengijinkan untuk memeriksa dampak dalam menggunakan berbagai CPUS. Bentuk wujud pertama menggunakan dua pengolah seperti halnya Ultra 60. Karena bentuk wujud salah satu dari CPUS yang kedua dilumpuhkan. Dalam bentuk wujud akhir salah satu dari CPUS adalah yang dipesan dan real-time benchmarks adalah dimajukan itu.. Juga untuk ini bentuk wujud pengolah dipesan dinaungi dari semua unbound interrupts.

Benchmark-Result

Non real-time external load

Tabel dibawah menunjukan jenis dalam memproses digunakan untuk menghasilkan beban yang non-real-time. Beban beristilah CPU aplikasi intensive seperti halnya aplikasi yang menggunakan menyela Sarana I/O seperti file dan subsistem jaringan.

Non-real-time-external-load

5.2 Timer Jitter

Gambar dibawah menunjukan hasil menyangkut pengatur waktu jitter tes run pada empat platform. Tanpa suatu beban, menunjukkan di dalam Gambar (a), semua jitter platform bisa diterima di bawah 200 ì detik. Solaris ( 1 rt) bentuk wujud mempunyai jumlah paling sedikit jitter. Jitter untuk Lynx bentuk wujud adalah juga rendah. Di bawah suatu muatan berat, menunjukkan di dalam Gambar (b), jitter untuk Solaris bentuk wujud yang tidak mencadangkan suatu real-processor lewat batas. Yang terburuk kasus jitter, karena bentuk wujud ini, lebih besar dari sepuluh detik/second

Timer-jitter

Application Response

Tabel dibawah menunjukan kasus yang terburuk menanggapi hasil untuk semua bentuk wujud. Tanpa suatu beban semua bentuk wujud mempunyai suatu tanggapan menghasilkan sangat dekat dengan nilai dikalibrasi 10 seperseribu detik. Dengan suatu beban hanya Lynx dan Solaris ( 1 rt) bentuk wujud datang dekat dengan 10 nilai seperseribu detik. Yang terburuk hasil kasus untuk standard itu Solaris platform ( Solaris 2 proses) apakah tiga order lebih buruk dibanding nilai yang dikalibrasi itu.

Application-Response

Synchronization

Gambar dibawah menunjukkanlah rata-rata latencies untuk mekanisme sinkronisasi yang sama. Karena Lynx the lynx semaphor memperlihatkan latency yang paling tinggi, hampir bisa dipastikan kepada fakta warisan prioritas yang diterapkan untuk/karena semaphor ini. Karena Solaris latency menyangkut POSIX menamai semaphor adalah jauh lebih tinggi dibanding latency menyangkut mekanisme yang lain itu. Suatu penjelasan untuk ini adalah bahwa semaphor menyebut bertahan sistem file.

Sync Test 1 : Lynx and solaris (1rt)

Sync test 1 : lynx and solaris

Sync Test 2 : Lynx and solaris (1rt)

Sync test 2 : lynx and solaris

Sync Test 3 : Lynx and solaris (1rt)

Sync test 3 : lynx and solaris

Context switching times

Context Switching Times

Communication

Real-time signals

Gambar dibawah menunjukan hasil menyangkut signal real-time benchmark untuk semua bentuk wujud. Lynx mempunyai suatu isyarat latency yang lebih rendah dibanding Solaris bentuk wujud yang manapun . Juga Solaris 1 proses dan 2 bentuk wujud proses sungguh dipengaruh oleh penambahan dari suatu beban yang non-real-time.

Real Time Signals

Pesan antri Latency dan throughput POSIX antrian pesan untuk semua bentuk wujud ditunjukkan di dalam Tabel dibawah The latency untuk Lynx platform menjadi lebih baik dibanding Solaris platform, tetapi Solaris platform mempunyai throughput yang lebih baik. Throughput yang lebih baik ini adalah hampir bisa dipastikan ke perangkat keras lebih cepat pada Solaris platform.