Adakah yang benar-benar mengerti bagaimana penjadwalan HFSC di Linux / BSD bekerja?

Saya membaca kertas PostScript asli SIGCOMM '97 tentang HFSC, ini sangat teknis, tapi saya mengerti konsep dasarnya. Alih-alih memberikan kurva layanan linier (seperti dengan hampir semua algoritma penjadwalan lainnya), Anda dapat menentukan kurva layanan cembung atau cekung dan dengan demikian dimungkinkan untuk memisahkan bandwidth dan penundaan. Namun, meskipun tulisan ini menyebutkan jenis algoritma penjadwalan yang digunakan (real-time dan link-share), itu selalu hanya menyebutkan SATU kurva per kelas penjadwalan (decoupling dilakukan dengan menentukan kurva ini, hanya satu kurva yang diperlukan untuk itu ).

Sekarang HFSC telah diimplementasikan untuk BSD (OpenBSD, FreeBSD, dll.) Menggunakan kerangka kerja penjadwalan ALTQ dan telah diimplementasikan Linux menggunakan kerangka kerja penjadwalan TC (bagian dari iproute2). Kedua implementasi menambahkan dua kurva layanan tambahan, yang TIDAK ada di kertas aslinya! Kurva layanan waktu nyata dan kurva layanan batas atas. Sekali lagi, harap dicatat bahwa makalah asli menyebutkan dua algoritma penjadwalan (real-time dan link-share), tetapi dalam makalah itu keduanya bekerja dengan satu kurva layanan tunggal. Tidak pernah ada dua kurva layanan independen untuk keduanya seperti yang saat ini Anda temukan di BSD dan Linux.

Lebih buruk lagi, beberapa versi ALTQ tampaknya menambahkan prioritas antrian tambahan untuk HSFC (tidak ada yang namanya prioritas dalam makalah asli juga). Saya menemukan beberapa BSD HowTo menyebutkan pengaturan prioritas ini (meskipun halaman manual rilis ALTQ terbaru tidak tahu parameter seperti itu untuk HSFC, jadi secara resmi bahkan tidak ada).

Ini semua membuat penjadwalan HFSC bahkan lebih kompleks daripada algoritma yang dijelaskan dalam makalah asli dan ada banyak tutorial di Internet yang sering saling bertentangan, satu mengklaim kebalikan dari yang lain. Ini mungkin alasan utama mengapa tampaknya tidak ada yang benar-benar memahami cara kerja penjadwalan HFSC. Sebelum saya dapat mengajukan pertanyaan, kami membutuhkan beberapa contoh pengaturan. Saya akan menggunakan yang sangat sederhana seperti terlihat pada gambar di bawah ini:

alt teks http://f.imagehost.org/0177/hfsc-test-setup.png

Berikut adalah beberapa pertanyaan yang tidak dapat saya jawab karena tutorialnya saling bertentangan:

1. Untuk apa saya perlu kurva waktu-nyata sama sekali? Dengan asumsi A1, A2, B1, B2 semuanya 128 kbit / s link-share (tidak ada kurva real-time untuk salah satu), maka masing-masing akan mendapatkan 128 kbit / s jika root memiliki 512 kbit / s untuk didistribusikan (dan A dan B keduanya 256 kbit / s tentu saja), kan? Mengapa saya juga akan memberi A1 dan B1 kurva waktu-nyata dengan 128 kbit / s? Apa gunanya ini? Untuk memberikan keduanya prioritas yang lebih tinggi? Menurut makalah asli saya bisa memberi mereka prioritas yang lebih tinggi dengan menggunakan kurva , itu adalah tentang HFSC. Dengan memberikan kedua kelas kurva [256kbit / s 20ms 128kbit / s] keduanya memiliki prioritas dua kali lipat daripada A2 dan B2 secara otomatis (masih hanya mendapatkan rata-rata 128 kbit / s)

2. Apakah bandwidth real-time diperhitungkan ke arah bandwidth link-share? Misalkan jika A1 dan B1 keduanya hanya memiliki bandwidth 64kbit / s real-time dan 64kbit / s, apakah itu berarti begitu mereka dilayani 64kbit / s melalui waktu-nyata, persyaratan tautan-bagi mereka juga terpenuhi (mereka mungkin dapatkan kelebihan bandwidth, tetapi mari abaikan itu sebentar) atau apakah itu berarti mereka mendapatkan 64 kbit / dtk melalui tautan-bagikan? Jadi, apakah setiap kelas memiliki "persyaratan" bandwidth real-time plus tautan-bagi? Atau apakah kelas hanya memiliki persyaratan lebih tinggi daripada kurva waktu-nyata jika kurva tautan-bagikan lebih tinggi dari kurva waktu-nyata (persyaratan tautan-bagikan saat ini sama dengan persyaratan tautan-bagikan yang ditentukan dikurangi bandwidth waktu nyata yang telah disediakan untuk ini kelas)?

3. Apakah kurva batas atas juga berlaku untuk waktu-nyata, hanya untuk berbagi tautan, atau mungkin keduanya? Beberapa tutorial mengatakan satu cara, ada yang mengatakan sebaliknya. Beberapa bahkan mengklaim batas atas adalah maksimum untuk bandwidth waktu-nyata + bandwidth berbagi-tautan? Apa kebenarannya?

4. Dengan asumsi A2 dan B2 keduanya 128 kbit / s, apakah ada bedanya jika A1 dan B1 hanya 128 kbit / s hanya berbagi tautan, atau 64 kbit / s real-time dan 128 kbit / s tautan-bagi, dan jika demikian , perbedaan apa?

5. Jika saya menggunakan kurva real-time yang terpisah untuk meningkatkan prioritas kelas, mengapa saya perlu "kurva" sama sekali? Mengapa nilai real-time dan tautan-berbagi tidak real-time juga merupakan nilai tetap? Mengapa keduanya kurva? Kebutuhan akan kurva jelas dalam makalah aslinya, karena hanya ada satu atribut semacam itu per kelas. Tetapi sekarang, memiliki tiga atribut (real-time, berbagi tautan, dan batas atas) untuk apa saya masih perlu kurva pada masing-masing atribut? Mengapa saya ingin bentuk kurva (bukan bandwidth rata-rata, tetapi kemiringannya) berbeda untuk lalu lintas waktu-nyata dan tautan-bagikan?

6. Menurut sedikit dokumentasi yang tersedia, nilai-nilai kurva waktu nyata benar-benar diabaikan untuk kelas dalam (kelas A dan B), mereka hanya diterapkan pada kelas daun (A1, A2, B1, B2). Jika itu benar, mengapa konfigurasi sampel ALTQ HFSC (mencari 3,3 konfigurasi Sampel ) mengatur kurva real-time pada kelas dalam dan mengklaim bahwa mereka menetapkan tingkat dijamin dari kelas dalam itu? Bukankah itu sama sekali tidak ada gunanya? (catatan: pshare menetapkan kurva tautan berbagi di ALTQ dan memanggang kurva waktu-nyata; Anda dapat melihatnya di paragraf di atas konfigurasi sampel).

7. Beberapa tutorial mengatakan jumlah semua kurva waktu nyata mungkin tidak lebih tinggi dari 80% dari kecepatan garis, yang lain mengatakan itu tidak boleh lebih tinggi dari 70% dari kecepatan garis. Mana yang benar atau mereka mungkin salah?

8. Salah satu tutorial mengatakan Anda akan melupakan semua teorinya. Tidak peduli bagaimana hal itu benar-benar bekerja (penjadwal dan distribusi bandwidth), bayangkan tiga kurva sesuai dengan "model pikiran yang disederhanakan" sebagai berikut: waktu nyata adalah bandwidth yang dijamin yang akan selalu didapat oleh kelas ini. link-share adalah bandwidth yang ingin dipenuhi oleh kelas ini, tetapi kepuasan tidak dapat dijamin. Jika ada kelebihan bandwidth, kelas mungkin bahkan ditawarkan bandwidth lebih dari yang diperlukan untuk menjadi puas, tetapi mungkin tidak pernah menggunakan lebih dari batas atas kata. Agar semua ini berfungsi, jumlah semua bandwidth real-time mungkin tidak di atas xx% dari kecepatan jalur (lihat pertanyaan di atas, persentasenya bervariasi). Pertanyaan: Apakah ini lebih atau kurang akurat atau kesalahpahaman total HSFC?

9. Dan jika asumsi di atas benar-benar akurat, di mana prioritas dalam model itu? Misalnya setiap kelas mungkin memiliki bandwidth real-time (dijamin), bandwidth link-share (tidak dijamin) dan mungkin batas atas, tetapi masih beberapa kelas memiliki kebutuhan prioritas yang lebih tinggi daripada kelas lainnya. Dalam hal ini saya masih harus memprioritaskan, bahkan di antara lalu lintas waktu-nyata dari kelas-kelas itu. Apakah saya akan memprioritaskan kemiringan kurva? Dan jika demikian, kurva apa? Kurva waktu nyata? Kurva tautan-bagikan? Kurva batas atas? Mereka semua? Apakah saya akan memberi mereka semua lereng yang sama atau masing-masing lereng yang berbeda dan bagaimana cara mengetahui lereng yang tepat?

Saya masih belum kehilangan harapan bahwa setidaknya ada satu tangan penuh orang di dunia ini yang benar-benar memahami HFSC dan mampu menjawab semua pertanyaan ini secara akurat. Dan melakukannya tanpa saling bertentangan dalam jawaban akan sangat menyenangkan ;-)

Membaca makalah tentang HFSC dan sepupunya bukanlah cara yang baik untuk memahaminya. Tujuan utama dari makalah HFSC adalah untuk memberikan bukti matematis yang kuat dari klaimnya, tidak menjelaskan cara kerjanya. Memang Anda tidak dapat memahami cara kerjanya dari kertas HFSC saja, Anda harus membaca makalah itu referensi juga. Jika Anda memiliki masalah dengan klaim atau buktinya maka menghubungi penulis surat kabar itu mungkin ide yang bagus, jika tidak, saya ragu mereka akan tertarik untuk mendengar dari Anda.

Saya telah menulis tutorial untuk HFSC . Bacalah jika penjelasan saya di bawah tidak jelas.

Untuk apa saya perlu kurva waktu-nyata sama sekali? Dengan asumsi A1, A2, B1, B2 semuanya adalah 128 kbit / s link-share (tidak ada kurva waktu nyata untuk salah satu), maka masing-masing akan mendapatkan 128 kbit / s jika root memiliki 512 kbit / s untuk didistribusikan (dan A dan B keduanya 256 kbit / s tentu saja), kan? Mengapa saya juga akan memberi A1 dan B1 kurva waktu-nyata dengan 128 kbit / s? Apa gunanya ini? Untuk memberikan keduanya prioritas yang lebih tinggi? Menurut makalah asli saya bisa memberi mereka prioritas yang lebih tinggi dengan menggunakan kurva, itu adalah tentang HFSC. Dengan memberikan kedua kelas kurva [256kbit / s 20ms 128kbit / s] keduanya memiliki prioritas dua kali lipat daripada A2 dan B2 secara otomatis (masih hanya mendapatkan rata-rata 128 kbit / s)

Kurva waktu nyata dan kurva berbagi tautan dievaluasi dengan berbagai cara. Kurva waktu nyata memperhitungkan apa yang telah dilakukan kelas sepanjang seluruh sejarahnya. Itu harus melakukan itu untuk menyediakan alokasi bandwidth dan latensi yang akurat. Kelemahannya bukan apa yang secara intuitif dianggap adil oleh kebanyakan orang . Di bawah waktu nyata, jika suatu kelas meminjam bandwidth ketika tidak ada orang lain yang menginginkannya, itu dihukum ketika orang lain menginginkannya kembali nanti. Ini berarti di bawah jaminan waktu nyata suatu kelas tidak bisa mendapatkan bandwidth untuk waktu yang lama karena menggunakannya lebih awal, ketika tidak ada yang menginginkannya.

Berbagi tautan itu adil, karena tidak menghukum kelas karena menggunakan bandwidth cadangan. Namun ini berarti tidak dapat memberikan jaminan latensi yang kuat.

Pemisahan pembagian tautan dari pemberian jaminan latensi adalah hal baru yang dibawa HFSC ke meja, dan makalah ini mengatakan sebanyak mungkin dalam kalimat pembukaannya: Dalam makalah ini, kami mempelajari model dan algoritma manajemen sumber daya hierarkis yang mendukung berbagi tautan dan dijamin layanan real-time dengan penundaan (prioritas) terpisah dan alokasi bandwidth. Kata kunci dalam kalimat itu dipisahkan. Diterjemahkan, itu berarti Anda diharapkan mengatakan bagaimana bandwidth yang tidak digunakan dibagi dengan ls, dan tentukan jaminan waktu nyata (alias jaminan latensi) yang diperlukan dengan rt. Keduanya orthogonal.

Apakah bandwidth real-time diperhitungkan ke arah bandwidth link-share?

Iya nih. Dalam makalah HFSC mereka mendefinisikan bandwidth dalam hal apa yang telah dikirim kelas sejak kelas menjadi backlog (yaitu memiliki paket yang menunggu untuk dikirim). Satu-satunya perbedaan antara rt dan ls adalah rt melihat ke depan dari setiap kali kelas menjadi backlog dan menghitung bandwidth dijamin terendah dari set itu, sedangkan berbagi tautan hanya terlihat dari terakhir kali kelas menjadi backlog. Jadi rt mempertimbangkan lebih banyak byte daripada ls, tetapi setiap byte yang dianggap juga dianggap oleh rt.

Apakah kurva batas atas juga berlaku untuk waktu-nyata, hanya untuk berbagi tautan, atau mungkin keduanya?

Batas atas tidak menghentikan paket dari yang dikirim untuk memenuhi kondisi waktu nyata. Paket yang dikirim dalam kondisi waktu nyata masih diperhitungkan ke batas atas, dan dengan demikian dapat menunda paket yang dikirim di bawah kondisi berbagi tautan di masa mendatang. Ini adalah perbedaan lain antara waktu nyata dan berbagi tautan.

Dengan asumsi A2 dan B2 keduanya 128 kbit / s, apakah ada bedanya jika A1 dan B1 hanya 128 kbit / s hanya berbagi tautan, atau 64 kbit / s real-time dan 128 kbit / s tautan-bagi, dan jika demikian , perbedaan apa?

Ya, itu membuat perbedaan. Seperti dijelaskan di atas jika Anda menggunakan waktu nyata, latensi dijamin tetapi tautannya tidak dibagikan secara adil (dan khususnya kelas dapat menderita kelaparan bandwidth), dan batas atas tidak diberlakukan. Jika Anda menggunakan tautan berbagi, latensi tidak dijamin, tetapi berbagi tautan itu adil, tidak ada risiko kelaparan, dan batas atas diberlakukan. Waktu nyata selalu dicek sebelum berbagi tautan, namun ini tidak berarti berbagi tautan akan diabaikan. Itu karena paket dihitung secara berbeda. Karena sejarah dianggap secara real time, sebuah paket mungkin tidak diperlukan untuk memenuhi jaminan real-time (karena satu dihitung termasuk dari sejarah) tetapi diperlukan untuk memuaskan berbagi tautan karena mengabaikan paket historis.

Jika saya menggunakan kurva real-time yang terpisah untuk meningkatkan prioritas kelas, mengapa saya perlu "kurva" sama sekali? Mengapa nilai real-time dan tautan-berbagi tidak real-time juga merupakan nilai tetap? Mengapa keduanya kurva? Kebutuhan akan kurva jelas dalam makalah aslinya, karena hanya ada satu atribut semacam itu per kelas. Tetapi sekarang, memiliki tiga atribut (real-time, berbagi tautan, dan batas atas) untuk apa saya masih perlu kurva pada masing-masing atribut? Mengapa saya ingin bentuk kurva (bukan bandwidth rata-rata, tetapi kemiringannya) berbeda untuk lalu lintas waktu-nyata dan tautan-bagikan?

Kurva untuk kontrol waktu nyata memungkinkan Anda memperdagangkan latensi ketat untuk satu kelas lalu lintas tertentu (mis. VOIP) dengan latensi buruk untuk kelas lalu lintas lainnya (mis. Email). Ketika memutuskan paket mana yang akan dikirim di bawah batasan waktu nyata HFSC memilih paket yang akan menyelesaikan pengiriman terlebih dahulu. Namun, itu tidak menggunakan bandwidth tautan untuk menghitung ini, ia menggunakan bandwidth yang dialokasikan oleh kurva waktu nyata. Jadi jika kita memiliki paket VOIP dan email dengan panjang yang sama, dan paket VOIP memiliki kurva cembung yang memberikan jika 10 kali lipat lebih dari kurva cekung untuk email, maka 10 paket VOIP akan dikirim sebelum paket email pertama. Tetapi ini hanya terjadi untuk waktu burst, yang seharusnya paling banyak waktu yang diperlukan untuk mengirim beberapa paket - yaitu mili detik. Setelah itu kurva VOIP akan rata, dan VOIP tidak akan mendapatkan peningkatan di masa depan kecuali jika mundur untuk sementara waktu (yang seharusnya VOIP adalah aplikasi bandwidth rendah). Hasil bersih dari semua ini adalah untuk memastikan pasangan paket VOIP pertama tersebut dikirim lebih cepat daripada yang lain, sehingga memberikan VOIP latensi rendah dengan mengorbankan email mendapatkan latensi tinggi.

Seperti yang saya katakan sebelumnya, karena berbagi tautan tidak melihat riwayat, itu tidak dapat memberikan jaminan latensi. Jaminan yang solid adalah yang dibutuhkan untuk lalu lintas waktu nyata seperti VOIP. Namun, rata-rata kurva tautan bersama cembung masih akan memberikan peningkatan latensi terhadap lalu lintasnya. Itu tidak dijamin. Itu bagus untuk sebagian besar hal, seperti lalu lintas web melalui email.

Menurut sedikit dokumentasi yang tersedia, nilai-nilai kurva waktu nyata benar-benar diabaikan untuk kelas dalam (kelas A dan B), mereka hanya diterapkan pada kelas daun (A1, A2, B1, B2). Jika itu benar, mengapa konfigurasi sampel ALTQ HFSC (mencari 3,3 konfigurasi Sampel) mengatur kurva real-time pada kelas dalam dan mengklaim bahwa mereka menetapkan tingkat dijamin dari kelas dalam itu? Bukankah itu sama sekali tidak ada gunanya? (catatan: pshare menetapkan kurva tautan berbagi di ALTQ dan memanggang kurva waktu-nyata; Anda dapat melihatnya di paragraf di atas konfigurasi sampel).

Dokumentasinya benar. Hirarki (dan dengan demikian node batin) tidak berpengaruh pada perhitungan waktu nyata apa pun. Saya tidak bisa memberi tahu Anda mengapa ALTQ ternyata berpikir demikian.

Beberapa tutorial mengatakan jumlah semua kurva waktu nyata mungkin tidak lebih tinggi dari 80% dari kecepatan garis, yang lain mengatakan itu tidak boleh lebih tinggi dari 70% dari kecepatan garis. Mana yang benar atau mereka mungkin salah?

Keduanya salah. Jika 70% atau 80% dari lalu lintas Anda memiliki persyaratan latensi keras yang harus ditentukan secara real time, kenyataannya adalah Anda hampir pasti tidak dapat memuaskan mereka dengan tautan yang Anda gunakan. Anda memerlukan tautan yang lebih cepat.

Satu-satunya cara seseorang bisa berpikir menentukan 80% dari lalu lintas harus real time adalah jika mereka menapaki real time sebagai pendorong prioritas. Ya, untuk memberikan jaminan latensi Anda berlaku meningkatkan prioritas beberapa paket. Tapi itu hanya untuk milidetik. Itu semua yang dapat diatasi oleh tautan dan masih memberikan jaminan latensi.

Ada sangat sedikit lalu lintas yang membutuhkan jaminan latensi. VOIP adalah satu, NTP yang lain. Selebihnya semua harus dilakukan dengan berbagi tautan. Jika Anda ingin web menjadi cepat, Anda membuatnya cepat dengan mengalokasikan sebagian besar kapasitas tautan. Share yang ini dijamin dalam jangka panjang. Jika Anda ingin latensi rendah (rata-rata), berikan kurva cembung di bawah berbagi tautan.

Salah satu tutorial mengatakan Anda akan melupakan semua teorinya. Tidak peduli bagaimana hal itu benar-benar bekerja (penjadwal dan distribusi bandwidth), bayangkan tiga kurva sesuai dengan "model pikiran yang disederhanakan" sebagai berikut: waktu nyata adalah bandwidth yang dijamin yang akan selalu didapat oleh kelas ini. link-share adalah bandwidth yang ingin dipenuhi oleh kelas ini, tetapi kepuasan tidak dapat dijamin. Jika ada kelebihan bandwidth, kelas mungkin bahkan ditawarkan bandwidth lebih dari yang diperlukan untuk menjadi puas, tetapi mungkin tidak pernah menggunakan lebih dari batas atas kata. Agar semua ini berfungsi, jumlah semua bandwidth real-time mungkin tidak di atas xx% dari kecepatan jalur (lihat pertanyaan di atas, persentasenya bervariasi). Pertanyaan: Apakah ini lebih atau kurang akurat atau kesalahpahaman total HSFC?

Ini adalah deskripsi batas atas yang baik. Meskipun uraian berbagi tautan benar-benar akurat, namun menyesatkan. Meskipun memang benar berbagi tautan tidak memberikan jaminan latensi keras seperti waktu nyata, ia melakukan pekerjaan yang lebih baik dengan memberikan bandwidth pada kelasnya alokasi daripada pesaing, seperti CBQ dan HTB. Jadi dengan mengatakan tautan berbagi "tidak memberikan jaminan" itu memegangnya ke standar yang lebih tinggi yang dapat disediakan oleh penjadwal lain.

Deskripsi waktu nyata mengatur keduanya akurat, tetapi sangat menyesatkan sehingga saya menyebutnya salah. Seperti namanya tujuan real time bukan untuk memberikan bandwidth yang terjamin. Ini untuk memberikan latensi yang dijamin - yaitu paket dikirim SEKARANG, bukan beberapa waktu acak tergantung pada bagaimana tautan digunakan. Sebagian besar lalu lintas tidak memerlukan latensi yang terjamin.

Yang mengatakan, real time juga tidak memberikan jaminan latensi yang sempurna. Bisa, jika tautan tidak dikelola oleh tautan juga, tetapi sebagian besar pengguna menginginkan fleksibilitas tambahan untuk memiliki keduanya dan itu tidak datang secara gratis. Waktu nyata dapat melewatkan tenggat waktu latensi saat mengirim satu paket MTU. (Jika itu terjadi, itu akan menjadi karena itu adalah berbagi tautan paket MTU yang menyelinap masuk sementara waktu tetap menjaga tautan tetap siaga seandainya diberi paket dengan tenggat waktu pendek yang harus segera dikirim. Ini adalah perbedaan lain antara berbagi tautan dan waktu nyata. Untuk memberikan jaminannya, waktu nyata dapat dengan sengaja membuat saluran tetap siaga meskipun ada paket yang akan dikirim, sehingga menyediakan kurang dari 100% pemanfaatan tautan. Berbagi tautan selalu menggunakan 100% kapasitas tautan yang tersedia. Tidak seperti waktu nyata ,

Alasan real time dapat dikatakan menawarkan jaminan latensi yang sulit adalah penundaan dibatasi. Jadi jika Anda mencoba untuk menawarkan jaminan latensi 20 ms pada tautan 1Mbit / detik, dan berbagi tautan mengirim paket ukuran MTU (1500 byte), Anda tahu salah satu dari paket itu akan membutuhkan 12ms untuk mengirim. Jadi, jika Anda memberi tahu waktu nyata Anda menginginkan latensi 8 ms, Anda masih bisa memenuhi tenggat 20 ms - dengan jaminan mutlak.

Dan jika asumsi di atas benar-benar akurat, di mana prioritas dalam model itu? Misalnya setiap kelas mungkin memiliki bandwidth real-time (dijamin), bandwidth link-share (tidak dijamin) dan mungkin batas atas, tetapi masih beberapa kelas memiliki kebutuhan prioritas yang lebih tinggi daripada kelas lainnya. Dalam hal ini saya masih harus memprioritaskan, bahkan di antara lalu lintas waktu-nyata dari kelas-kelas itu. Apakah saya akan memprioritaskan kemiringan kurva? Dan jika demikian, kurva apa? Kurva waktu nyata? Kurva tautan-bagikan? Kurva batas atas? Mereka semua? Apakah saya akan memberi mereka semua lereng yang sama atau masing-masing lereng yang berbeda dan bagaimana cara mengetahui lereng yang tepat?

Tidak ada model prioritas. Serius. Jika Anda ingin memberikan prioritas mutlak lalu lintas, gunakan pfifo. Itu untuk apa. Tetapi juga berhati-hatilah bahwa jika Anda memberikan lalu lintas web prioritas mutlak atas lalu lintas email, itu berarti membiarkan lalu lintas web memenuhi tautan dan karenanya tidak ada paket email yang melewatinya, sama sekali . Semua koneksi email Anda kemudian mati.

Pada kenyataannya tidak ada yang menginginkan prioritas semacam itu. Apa yang mereka inginkan adalah apa yang HFSC sediakan. Jika Anda benar-benar memiliki lalu lintas waktu nyata, HFSC menyediakan itu. Tapi itu akan menjadi segalanya. Selebihnya, HFSC memungkinkan Anda untuk mengatakan "pada tautan yang macet, mengalokasikan 90% ke web dan membiarkan email mengalir bersama pada 10%, dan oh mengirim paket DNS aneh dengan cepat, tetapi jangan biarkan seseorang DOS saya dengan itu."

Anda bisa mendefinisikan kurva dengan nama yang berbeda:

• rt, kurva waktu nyata, bandwidth / jaminan keterlambatan.
• ls, tautan tautan berbagi, berbagi bandwidth / penundaan (berdasarkan konfigurasi daun tetangga)
• ul, kurva batas atas, bandwidth maksimum / penundaan yang mungkin dicapai.

Untuk apa saya perlu kurva waktu-nyata sama sekali? Dengan asumsi A1, A2, B1, B2 semuanya adalah 128 kbit / s link-share (tidak ada kurva waktu nyata untuk salah satu), maka masing-masing akan mendapatkan 128 kbit / s jika root memiliki 512 kbit / s untuk didistribusikan (dan A dan B keduanya 256 kbit / s tentu saja), kan? Mengapa saya juga akan memberi A1 dan B1 kurva waktu-nyata dengan 128 kbit / s? Apa gunanya ini? Untuk memberikan keduanya prioritas yang lebih tinggi? Menurut makalah asli saya bisa memberi mereka prioritas yang lebih tinggi dengan menggunakan kurva, itu adalah tentang HFSC. Dengan memberikan kedua kelas kurva [256kbit / s 20ms 128kbit / s] keduanya memiliki prioritas dua kali lipat daripada A2 dan B2 secara otomatis (masih hanya mendapatkan rata-rata 128 kbit / s)

Ketika Anda membuat definisi dalam HFSC hanya dengan kurs, ia secara otomatis menetapkan 'dmax' ke 0. Yang pada dasarnya berarti tidak memperhitungkan keterlambatan. Konfigurasi HFSC yang baik harus mencakup bandwidth dan batas-batas keterlambatan yang ingin Anda gunakan untuk kelas Anda, jika tidak algoritma tidak dapat mengetahui dengan tepat seberapa banyak prioritas yang harus diperoleh kelas.

Setiap kali Anda memberikan prioritas paket, paket lain harus dikurangi prioritasnya. Berdasarkan nilai 'dmax' dan 'rate' semua kelas akan digandakan menggunakan penghitung waktu virtual. Lihat tc-hfsc (7) untuk informasi lebih lanjut.

Apakah bandwidth real-time diperhitungkan ke arah bandwidth link-share? Misalkan jika A1 dan B1 keduanya hanya memiliki bandwidth 64kbit / s real-time dan 64kbit / s, apakah itu berarti begitu mereka dilayani 64kbit / s melalui waktu-nyata, persyaratan tautan-bagi mereka juga terpenuhi (mereka mungkin dapatkan kelebihan bandwidth, tetapi mari abaikan itu sebentar) atau apakah itu berarti mereka mendapatkan 64 kbit / dtk melalui tautan-bagikan? Jadi, apakah setiap kelas memiliki "persyaratan" bandwidth real-time plus tautan-bagi? Atau apakah kelas hanya memiliki persyaratan lebih tinggi daripada kurva waktu-nyata jika kurva tautan-bagikan lebih tinggi dari kurva waktu-nyata (persyaratan tautan-bagikan saat ini sama dengan persyaratan tautan-bagikan yang ditentukan dikurangi bandwidth waktu nyata yang telah disediakan untuk ini kelas)?

Jika aliran tidak melewati batas definisi tautan-bagikan kelas, maka kurva waktu-nyata tidak pernah digunakan. Menentukan kurva waktu-nyata dalam kasus ini memungkinkan Anda misalnya: untuk menjamin 'dmax' tertentu.

Jika definisi tautan-bagikan Anda sempurna, maka Anda tidak perlu kurva waktu-nyata. Anda bisa mendefinisikan kurva layanan (sc), tetapi itu akan membuat konfigurasi Anda bekerja lebih keras.

Apakah kurva batas atas juga berlaku untuk waktu-nyata, hanya untuk berbagi tautan, atau mungkin keduanya? Beberapa tutorial mengatakan satu cara, ada yang mengatakan sebaliknya. Beberapa bahkan mengklaim batas atas adalah maksimum untuk bandwidth waktu-nyata + bandwidth berbagi-tautan? Apa kebenarannya?

Kurva batas atas kelas Anda diterapkan hanya untuk berbagi tautan, ketika Anda menetapkan kurva batas atas, Anda HARUS mendefinisikan kurva tautan berbagi. Namun kurva batas atas kelas induk masih diterapkan.

Dengan asumsi A2 dan B2 keduanya 128 kbit / s, apakah ada bedanya jika A1 dan B1 hanya 128 kbit / s hanya berbagi tautan, atau 64 kbit / s real-time dan 128 kbit / s tautan-bagi, dan jika demikian , perbedaan apa?

Ada sedikit perbedaan, jika misalnya A2 = 0 kbits / s dan B2 = 256 kbits / s. Maka waktu virtual untuk A2 akan mencapai batas maksimal. Setiap kali paket diklasifikasikan dalam A2, mereka akan langsung diproses. Namun kurva real-time B2 masih akan memastikan bahwa mampu mengirimkan setidaknya 64 kbit / s

Jika saya menggunakan kurva waktu-nyata yang terpisah untuk meningkatkan prioritas kelas, mengapa saya perlu "kurva" sama sekali? Mengapa nilai real-time dan tautan-berbagi tidak real-time juga merupakan nilai tetap? Mengapa keduanya kurva? Kebutuhan akan kurva jelas dalam makalah aslinya, karena hanya ada satu atribut semacam itu per kelas. Tetapi sekarang, memiliki tiga atribut (real-time, berbagi tautan, dan batas atas) untuk apa saya masih perlu kurva pada masing-masing atribut? Mengapa saya ingin bentuk kurva (bukan bandwidth rata-rata, tetapi kemiringannya) berbeda untuk lalu lintas waktu-nyata dan tautan-bagikan?

Kurva waktu nyata tidak berbagi lalu lintas antara daun tetangga, kurva tautan berbagi lakukan.

Menurut sedikit dokumentasi yang tersedia, nilai-nilai kurva waktu nyata benar-benar diabaikan untuk kelas dalam (kelas A dan B), mereka hanya diterapkan pada kelas daun (A1, A2, B1, B2). Jika itu benar, mengapa konfigurasi sampel ALTQ HFSC (mencari 3,3 konfigurasi Sampel) mengatur kurva real-time pada kelas dalam dan mengklaim bahwa mereka menetapkan tingkat dijamin dari kelas dalam itu? Bukankah itu sama sekali tidak ada gunanya? (catatan: pshare menetapkan kurva tautan berbagi di ALTQ dan memanggang kurva waktu-nyata; Anda dapat melihatnya di paragraf di atas konfigurasi sampel).

Memang benar bahwa kurva waktu nyata diabaikan untuk kelas dalam, mereka hanya diterapkan pada kelas daun. Namun kurva real-time yang didefinisikan pada kelas-kelas dalam tersebut diperhitungkan untuk perhitungan pada kelas daun.

Beberapa tutorial mengatakan jumlah semua kurva waktu nyata mungkin tidak lebih tinggi dari 80% dari kecepatan garis, yang lain mengatakan itu tidak boleh lebih tinggi dari 70% dari kecepatan garis. Mana yang benar atau mereka mungkin salah?

Apa yang mereka maksudkan adalah: Anda tidak dapat memprioritaskan semua lalu lintas ... Setiap kali Anda memberikan prioritas paket, paket lain harus dikurangi dalam prioritas. Jika Anda memberikan terlalu banyak jaminan, algoritme menjadi tidak ada gunanya. Tentukan kelas yang mendapatkan prioritas dan menentukan kelas yang mungkin menderita.

Salah satu tutorial mengatakan Anda akan melupakan semua teorinya. Tidak peduli bagaimana hal itu benar-benar bekerja (penjadwal dan distribusi bandwidth), bayangkan tiga kurva sesuai dengan "model pikiran yang disederhanakan" sebagai berikut: waktu nyata adalah bandwidth yang dijamin yang akan selalu didapat oleh kelas ini. link-share adalah bandwidth yang ingin dipenuhi oleh kelas ini, tetapi kepuasan tidak dapat dijamin. Jika ada kelebihan bandwidth, kelas mungkin bahkan ditawarkan bandwidth lebih dari yang diperlukan untuk menjadi puas, tetapi mungkin tidak pernah menggunakan lebih dari batas atas kata. Agar semua ini berfungsi, jumlah semua bandwidth real-time mungkin tidak di atas xx% dari kecepatan jalur (lihat pertanyaan di atas, persentasenya bervariasi). Pertanyaan: Apakah ini lebih atau kurang akurat atau kesalahpahaman total HSFC?

Ini benar.

Dan jika asumsi di atas benar-benar akurat, di mana prioritas dalam model itu? Misalnya setiap kelas mungkin memiliki bandwidth real-time (dijamin), bandwidth link-share (tidak dijamin) dan mungkin batas atas, tetapi masih beberapa kelas memiliki kebutuhan prioritas yang lebih tinggi daripada kelas lainnya. Dalam hal ini saya masih harus memprioritaskan, bahkan di antara lalu lintas waktu-nyata dari kelas-kelas itu. Apakah saya akan memprioritaskan kemiringan kurva? Dan jika demikian, kurva apa? Kurva waktu nyata? Kurva tautan-bagikan? Kurva batas atas? Mereka semua? Apakah saya akan memberi mereka semua lereng yang sama atau masing-masing lereng yang berbeda dan bagaimana cara mengetahui lereng yang tepat?

Perbedaan antara misalnya HFSC dan HTB adalah bahwa HFSC akan memungkinkan Anda untuk menentukan dengan tepat berapa banyak priorosasi yang Anda inginkan. Anda melakukan ini dengan mendefinisikan batas minimum dan maksimum dengan nilai 'dmax'.

Akhirnya panduan yang tampaknya menjelaskan sebagian besar ketidakkonsistenan dan juga bagaimana implementasi saat ini berbeda dari makalah aslinya:

http://manpages.ubuntu.com/manpages/precise/man7/tc-hfsc.7.html

Menurut panduan ini, banyak panduan lain dan posting forum tentang HFSC sepenuhnya omong kosong; itu hanya menunjukkan betapa rumitnya HFSC, karena banyak orang yang tampaknya ahli dan berpura-pura sepenuhnya memahami HFSC, pada kenyataannya hanya memiliki pengetahuan parsial dan membuat pernyataan palsu berdasarkan kesalahpahaman konsep dan bagaimana semua pengaturan itu bermain bersama.

Saya pikir saya akhirnya akan menyerah pada HFSC. Jika Anda bisa mendapatkan pengaturan HFSC Anda dengan benar, itu mungkin QoS terbaik yang bisa Anda dapatkan, tetapi kemungkinan Anda benar-benar kacau jauh lebih tinggi daripada peluang Anda berhasil.

Jika Anda tidak dapat menghubungi penulis asli maka saya akan mencoba ini selanjutnya:

1. masuk ke pohon sumber kernel linux dan temukan file C yang mengimplementasikan "kerangka kerja penjadwalan TC"
2. Lihatlah tajuk dan temukan pembuat kode.
3. Pemrogram E-Mail dari "kerangka kerja penjadwalan TC" meminta mereka untuk literatur tentang implementasi mereka.

Coba juga periksa makalah baru lainnya yang mengutip yang ini. Mungkin ada makalah yang lebih baru di luar sana yang merupakan kelanjutan dari penelitian di bidang ini dan mungkin termasuk informasi lebih lanjut tentang pertanyaan yang Anda ajukan.