Solusi 1:
Membaca makalah tentang HFSC dan sepupunya bukanlah cara yang baik untuk memahaminya. Tujuan utama dari makalah HFSC adalah untuk memberikan bukti matematis yang ketat dari klaimnya, bukan menjelaskan cara kerjanya. Memang Anda tidak dapat memahami cara kerjanya dari makalah HFSC saja, Anda harus membaca makalah yang dirujuknya juga. Jika Anda memiliki masalah dengan klaim atau buktinya, menghubungi penulis makalah mungkin merupakan 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 ini tidak jelas.
Untuk apa saya memerlukan kurva waktu nyata sama sekali? Dengan asumsi A1, A2, B1, B2 semuanya 128 kbit/s link-share (tidak ada kurva real-time untuk keduanya), 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 memberikan A1 dan B1 kurva real-time dengan 128 kbit/s? Apa manfaatnya? Untuk memberikan keduanya prioritas yang lebih tinggi? Menurut makalah asli saya dapat memberi mereka prioritas yang lebih tinggi dengan menggunakan kurva, bagaimanapun juga itulah 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/son)
Kurva waktu nyata dan kurva berbagi tautan dievaluasi dengan cara yang berbeda. Kurva waktu nyata memperhitungkan apa yang telah dilakukan kelas sepanjang sejarahnya. Itu harus melakukan itu untuk menyediakan alokasi bandwidth dan latensi yang akurat. Kelemahannya bukanlah apa yang secara intuitif dianggap oleh kebanyakan orang sebagai adil . Dalam waktu nyata, jika suatu kelas meminjam bandwidth ketika tidak ada orang lain yang menginginkannya, itu akan dihukum ketika orang lain menginginkannya kembali nanti. Ini berarti di bawah jaminan waktu nyata, sebuah kelas tidak akan mendapatkan bandwidth untuk waktu yang lama karena telah menggunakannya lebih awal, saat 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 berbagi tautan dari penyediaan jaminan latensi adalah hal baru yang dibawa HFSC, dan makalah tersebut mengatakan sebanyak itu dalam kalimat pembukanya:Dalam makalah ini, kami mempelajari model dan algoritme manajemen sumber daya hierarkis yang mendukung kedua tautan- berbagi dan menjamin layanan real-time dengan delay terpisah (prioritas) dan alokasi bandwidth. Kata kunci dalam kalimat itu dipisahkan. Diterjemahkan, itu berarti Anda diharapkan mengatakan bagaimana bandwidth yang tidak terpakai akan dibagi dengan ls, dan menentukan jaminan waktu nyata (alias jaminan latensi) apa yang diperlukan dengan rt. Keduanya ortogonal.
Apakah bandwidth real-time diperhitungkan dalam bandwidth link-share?
Ya. Dalam kertas HFSC mereka mendefinisikan bandwidth dalam hal apa kelas telah dikirim sejak kelas menjadi backlogged (yaitu paket menunggu untuk dikirim). Satu-satunya perbedaan antara rt dan ls adalah rt melihat ke depan dari setiap kali kelas menjadi backlogged dan menghitung bandwidth terjamin terendah dari set itu, sedangkan berbagi tautan hanya melihat dari terakhir kali kelas menjadi backlogged. Jadi rt mempertimbangkan lebih banyak byte daripada ls, tetapi setiap byte yang dianggap ls juga dipertimbangkan oleh rt.
Apakah kurva batas atas juga berlaku untuk waktu nyata, hanya untuk berbagi tautan, atau mungkin keduanya?
Batas atas tidak menghentikan pengiriman paket untuk memenuhi kondisi real time. Paket yang dikirim dalam kondisi real time masih diperhitungkan dalam batas atas, dan dengan demikian dapat menunda pengiriman paket dalam kondisi berbagi tautan di masa mendatang. Ini adalah perbedaan lain antara waktu nyata dan berbagi tautan.
Dengan asumsi A2 dan B2 sama-sama 128 kbit/s, apakah ada bedanya jika A1 dan B1 hanya 128 kbit/s link-share saja, atau 64 kbit/s real-time dan 128 kbit/s link-share, dan jika ya, apa perbedaan?
Ya, itu membuat perbedaan. Seperti yang dijelaskan di atas jika Anda menggunakan waktu nyata, latensi dijamin tetapi tautan tidak dibagikan secara adil (dan khususnya kelas dapat mengalami kelaparan bandwidth), dan batas atas tidak diberlakukan. Jika Anda menggunakan berbagi tautan, latensi tidak dijamin, tetapi berbagi tautan adil, tidak ada risiko kelaparan, dan batas atas diberlakukan. Waktu nyata selalu diperiksa sebelum berbagi tautan, namun ini tidak berarti bahwa berbagi tautan akan diabaikan. Itu karena paket dihitung secara berbeda. Karena sejarah dianggap secara real time, sebuah paket mungkin tidak diperlukan untuk memenuhi jaminan waktu nyata (karena satu dihitung termasuk dari riwayat) tetapi diperlukan untuk memenuhi berbagi tautan karena mengabaikan paket historis.
Jika saya menggunakan kurva real-time terpisah untuk meningkatkan prioritas kelas, mengapa saya membutuhkan "kurva" sama sekali? Mengapa real-time bukan nilai tetap dan berbagi tautan juga merupakan nilai tetap? Mengapa keduanya kurva? Perlunya kurva sudah jelas di makalah aslinya, karena hanya ada satu atribut semacam itu per kelas. Tapi sekarang, memiliki tiga atribut (real-time, link-share, dan upper-limit) untuk apa saya masih membutuhkan kurva pada masing-masing atribut? Mengapa saya ingin bentuk kurva (bukan bandwidth rata-rata, tetapi kemiringannya) berbeda untuk lalu lintas waktu nyata dan berbagi tautan?
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). Saat memutuskan paket mana yang akan dikirim di bawah batasan waktu nyata, HFSC memilih salah satu 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 peningkatan 10 kali lipat dari kurva cekung untuk email, maka 10 paket VOIP akan dikirim sebelum paket email pertama. Tapi ini hanya terjadi untuk burst time, yang seharusnya paling lama waktu yang dibutuhkan untuk mengirim beberapa paket - yaitu mili detik. Setelah itu kurva VOIP akan mendatar, dan VOIP tidak akan mendapatkan peningkatan di masa mendatang kecuali jika mundur untuk sementara waktu (yang, mengingat VOIP adalah aplikasi bandwidth rendah, seharusnya). Hasil bersih dari semua ini adalah untuk memastikan beberapa paket VOIP pertama dikirim lebih cepat daripada yang lainnya, sehingga memberikan VOIP latensi rendah dengan mengorbankan email yang mendapatkan latensi tinggi.
Seperti yang saya katakan sebelumnya, karena berbagi tautan tidak melihat riwayat, itu tidak dapat memberikan jaminan latensi. Jaminan yang kokoh adalah yang dibutuhkan untuk lalu lintas waktu nyata seperti VOIP. Namun, rata-rata kurva cembung tautan bersama masih akan memberikan peningkatan latensi pada lalu lintasnya. Itu tidak dijamin. Itu bagus untuk sebagian besar hal, seperti lalu lintas web melalui email.
Menurut sedikit dokumentasi yang tersedia, nilai kurva real-time 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 konfigurasi 3.3 Sampel) mengatur kurva real-time pada kelas-kelas dalam dan mengklaim bahwa mereka menetapkan tingkat jaminan dari kelas-kelas dalam tersebut? Bukankah itu sama sekali tidak ada gunanya? (catatan:pshare menyetel kurva tautan-berbagi di ALTQ dan memarut kurva waktu nyata; Anda dapat melihatnya di paragraf di atas contoh konfigurasi).
Dokumentasinya benar. Hirarki (dan dengan demikian simpul dalam) tidak berpengaruh pada perhitungan waktu nyata apa pun. Saya tidak dapat memberi tahu Anda mengapa ALTQ tampaknya berpikir demikian.
Beberapa tutorial mengatakan bahwa jumlah semua kurva waktu nyata tidak boleh lebih tinggi dari 80% dari kecepatan garis, yang lain mengatakan itu tidak boleh lebih dari 70% dari kecepatan garis. Mana yang benar atau mungkin keduanya salah?
Keduanya salah. Jika 70% atau 80% lalu lintas Anda memiliki persyaratan latensi keras yang harus ditentukan dengan waktu nyata, kenyataannya Anda hampir pasti tidak dapat memuaskan mereka dengan tautan yang Anda gunakan. Anda memerlukan tautan yang lebih cepat.
Satu-satunya cara seseorang dapat berpikir untuk menentukan 80% lalu lintas harus waktu nyata adalah jika mereka menginjak waktu nyata sebagai peningkatan prioritas. Ya, untuk memberikan jaminan latensi, Anda sebenarnya meningkatkan prioritas beberapa paket. Tapi seharusnya hanya untuk milidetik. Hanya itu yang dapat diatasi oleh tautan dan tetap memberikan jaminan latensi.
Ada sangat sedikit lalu lintas yang membutuhkan jaminan latensi. VOIP adalah satu, NTP lainnya. Sisanya semua harus dilakukan dengan berbagi tautan. Jika Anda ingin web menjadi cepat, Anda membuatnya cepat dengan mengalokasikan sebagian besar kapasitas tautannya. Bagian itu adalah dijamin dalam jangka panjang. Jika Anda menginginkan latensi rendah (rata-rata), berikan kurva cembung di bawah berbagi tautan.
Satu tutorial mengatakan Anda akan melupakan semua teorinya. Tidak peduli bagaimana semuanya bekerja (penjadwal dan distribusi bandwidth), bayangkan tiga kurva menurut "model pikiran yang disederhanakan" berikut:real-time adalah bandwidth terjamin yang akan selalu didapat kelas ini. link-share adalah bandwidth yang diinginkan kelas ini sepenuhnya puas, tetapi kepuasan tidak dapat dijamin. Jika ada kelebihan bandwidth, kelas bahkan mungkin akan ditawarkan lebih banyak bandwidth daripada yang diperlukan untuk menjadi puas, tetapi mungkin tidak pernah menggunakan lebih dari batas atas. Agar semua ini berfungsi, jumlah semua bandwidth waktu-nyata mungkin tidak di atas xx% dari kecepatan jalur (lihat pertanyaan di atas, persentasenya bervariasi). Pertanyaan:Apakah ini kurang lebih akurat atau kesalahpahaman total tentang HSFC?
Ini adalah batas atas deskripsi yang bagus. Meskipun deskripsi berbagi tautan sangat akurat, itu menyesatkan. Meskipun benar berbagi tautan tidak memberikan jaminan latensi keras seperti waktu nyata, itu melakukan pekerjaan yang lebih baik dalam memberikan alokasi bandwidth kelasnya daripada pesaingnya, seperti CBQ dan HTB. Jadi dengan mengatakan berbagi tautan "tidak memberikan jaminan", itu memegangnya pada standar yang lebih tinggi yang dapat disediakan oleh penjadwal lainnya.
Deskripsi waktu nyata berhasil akurat, tetapi sangat menyesatkan sehingga saya salah menyebutnya. Seperti namanya, tujuan real time bukan untuk memberikan jaminan bandwidth. Ini untuk memberikan latensi yang dijamin - yaitu paket dikirim SEKARANG, bukan beberapa waktu acak nanti tergantung pada bagaimana tautan digunakan. Sebagian besar lalu lintas tidak memerlukan jaminan latensi.
Meskipun demikian, waktu nyata juga tidak memberikan jaminan latensi yang sempurna. Itu bisa, jika tautannya tidak dikelola oleh berbagi tautan juga, tetapi sebagian besar pengguna menginginkan fleksibilitas tambahan untuk memiliki keduanya dan itu tidak gratis. Waktu nyata dapat melewatkan batas waktu latensi pada waktu yang diperlukan untuk mengirim satu paket MTU. (Jika itu terjadi, itu karena itu adalah pembagian tautan paket MTU yang menyelinap masuk sementara tautan tetap diam jika diberikan paket dengan tenggat waktu pendek yang harus segera dikirim. Ini adalah perbedaan lain antara berbagi tautan dan real time. Untuk memberikan jaminannya real time mungkin dengan sengaja membiarkan saluran tidak aktif meskipun ada paket yang akan dikirim, sehingga penggunaan tautan disediakan kurang dari 100%. Link share selalu menggunakan 100% dari kapasitas tautan yang tersedia. Tidak seperti waktu nyata , bisa dikatakan sebagai "pelestarian kerja".)
Alasan waktu nyata dapat dikatakan menawarkan jaminan latensi keras adalah penundaan itu terbatas. Jadi, jika Anda mencoba menawarkan jaminan latensi 20ms pada tautan 1Mbit/detik, dan pembagian tautan mengirimkan paket berukuran MTU (1500 byte), Anda tahu salah satu dari paket tersebut akan membutuhkan waktu 12ms untuk dikirim. Jadi, jika Anda mengatakan secara real time bahwa Anda menginginkan latensi 8 md, Anda masih dapat memenuhi batas waktu 20 md - dengan jaminan mutlak.
Dan jika asumsi di atas benar-benar akurat, di manakah prioritas model tersebut? Misalnya. setiap kelas mungkin memiliki bandwidth real-time (dijamin), bandwidth link-share (tidak dijamin) dan mungkin batas atas, tetapi masih ada beberapa kelas yang memiliki kebutuhan prioritas lebih tinggi daripada kelas lainnya. Dalam hal ini saya masih harus memprioritaskan entah bagaimana, bahkan di antara lalu lintas real-time dari kelas-kelas itu. Apakah saya akan memprioritaskan dengan kemiringan kurva? Dan jika ya, kurva yang mana? Kurva waktu nyata? Kurva link-share? Kurva batas atas? Mereka semua? Apakah saya akan memberi mereka semua kemiringan yang sama atau masing-masing kemiringan yang berbeda dan bagaimana cara mengetahui kemiringan yang tepat?
Tidak ada model prioritas. Dengan serius. Jika Anda ingin memberikan lalu lintas prioritas mutlak, gunakan pfifo. Untuk itulah. Namun berhati-hatilah juga bahwa jika Anda memberikan prioritas absolut lalu lintas web daripada lalu lintas email, itu berarti membiarkan lalu lintas web memenuhi tautan dan dengan demikian tidak ada paket email yang masuk, sama sekali . Semua koneksi email Anda kemudian mati.
Pada kenyataannya tidak ada yang menginginkan prioritas semacam itu. Apa yang mereka inginkan adalah apa yang disediakan HFSC. Jika Anda benar-benar memiliki lalu lintas waktu nyata, HFSC menyediakannya. Tapi itu akan menjadi segalanya. Selebihnya, HFSC memungkinkan Anda untuk mengatakan "pada tautan yang padat, alokasikan 90% ke web dan biarkan email mengalir sepanjang 10%, dan oh kirim paket DNS aneh dengan cepat tetapi jangan biarkan seseorang DOS saya dengan itu."
Solusi 2:
Anda dapat menentukan kurva dengan nama yang berbeda:
- rt, kurva waktu nyata, jaminan lebar pita/penundaan.
- ls, kurva berbagi tautan, berbagi bandwidth/penundaan (berdasarkan konfigurasi tetangga yang keluar)
- ul, kurva batas atas, bandwidth/penundaan maksimum yang mungkin dicapai.
Untuk apa saya memerlukan kurva waktu nyata sama sekali? Dengan asumsi A1, A2, B1, B2 semuanya 128 kbit/s link-share (tidak ada kurva real-time untuk keduanya), 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 memberikan A1 dan B1 kurva real-time dengan 128 kbit/s? Apa manfaatnya? Untuk memberikan keduanya prioritas yang lebih tinggi? Menurut makalah asli saya dapat memberi mereka prioritas yang lebih tinggi dengan menggunakan kurva, bagaimanapun juga itulah 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/son)
Ketika Anda membuat definisi di HFSC dengan tarif saja, secara otomatis menetapkan 'dmax' ke 0. Yang pada dasarnya berarti tidak memperhitungkan keterlambatan. Konfigurasi HFSC yang baik harus menyertakan batas bandwidth DAN penundaan yang ingin Anda gunakan untuk kelas Anda, jika tidak, algoritme tidak dapat menentukan dengan tepat berapa banyak prioritas yang harus didapatkan kelas.
Setiap kali Anda memberikan prioritas paket, paket lain harus diturunkan prioritasnya. Berdasarkan nilai 'dmax' dan 'rate' semua kelas akan dimultipleks menggunakan pengatur waktu virtual. Lihat tc-hfsc(7) untuk informasi selengkapnya.
Apakah bandwidth real-time dihitung terhadap bandwidth link-share? E.g. jika A1 dan B1 keduanya hanya memiliki bandwidth real-time 64kbit/s dan 64kbit/slink-share, apakah itu berarti setelah mereka dilayani 64kbit/s melalui real-time, persyaratan link-share mereka juga terpenuhi (mereka mungkin mendapatkan kelebihan bandwidth, tetapi mari kita abaikan itu sebentar) atau apakah itu berarti mereka mendapatkan 64 kbit/s lagi melalui berbagi tautan? Jadi, apakah setiap kelas memiliki "persyaratan" bandwidth real-time plus berbagi tautan? Atau apakah kelas hanya memiliki persyaratan yang lebih tinggi daripada kurva waktu nyata jika kurva berbagi tautan lebih tinggi daripada kurva waktu nyata (persyaratan berbagi tautan saat ini sama dengan persyaratan berbagi tautan yang ditentukan dikurangi bandwidth waktu nyata yang sudah disediakan untuk kelas ini)?
Jika aliran tidak melewati batas definisi link-share kelas, maka kurva real-time tidak pernah digunakan. Menentukan kurva real-time dalam hal ini memungkinkan Anda misalnya:untuk menjamin 'dmax' tertentu.
Jika definisi berbagi tautan Anda sempurna, maka Anda tidak memerlukan kurva waktu nyata. Anda bisa saja menentukan 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, beberapa mengatakan sebaliknya. Beberapa bahkan mengklaim batas atas maksimum untuk bandwidth waktu-nyata + bandwidth berbagi-tautan? Apa kebenarannya?
Kurva batas atas kelas Anda diterapkan hanya untuk link-share, ketika Anda menentukan kurva batas atas, Anda HARUS menentukan kurva link-share. Namun kurva batas atas kelas induk masih diterapkan.
Dengan asumsi A2 dan B2 sama-sama 128 kbit/s, apakah ada bedanya jika A1 dan B1 hanya 128 kbit/s link-share saja, atau 64 kbit/s real-time dan 128 kbit/s link-share, dan jika ya, apa perbedaan?
Ada sedikit perbedaan, jika mis. A2 =0 kbits/s dan B2 =256 kbits/s. Maka waktu virtual untuk A2 akan maksimal. Setiap kali paket diklasifikasikan dalam A2, mereka akan langsung diproses. Namun kurva waktu-nyata B2 masih akan memastikan bahwa ia dapat mengirimkan setidaknya 64 kbit/dtk
Jika saya menggunakan kurva real-time terpisah untuk meningkatkan prioritas kelas, mengapa saya membutuhkan "kurva" sama sekali? Mengapa real-time bukan nilai tetap dan berbagi tautan juga merupakan nilai tetap? Mengapa keduanya kurva? Perlunya kurva sudah jelas di makalah aslinya, karena hanya ada satu atribut semacam itu per kelas. Tapi sekarang, memiliki tiga atribut (real-time, link-share, dan upper-limit) untuk apa saya masih membutuhkan kurva pada masing-masing atribut? Mengapa saya ingin bentuk kurva (bukan bandwidth rata-rata, tetapi kemiringannya) berbeda untuk lalu lintas waktu nyata dan berbagi tautan?
Kurva real-time tidak berbagi lalu lintas antara daun tetangga, tetapi kurva berbagi tautan.
Menurut sedikit dokumentasi yang tersedia, nilai kurva real-time 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 konfigurasi 3.3 Sampel) mengatur kurva real-time pada kelas-kelas dalam dan mengklaim bahwa mereka menetapkan tingkat jaminan dari kelas-kelas dalam tersebut? Bukankah itu sama sekali tidak ada gunanya? (catatan:pshare menyetel kurva tautan-berbagi di ALTQ dan memarut kurva waktu nyata; Anda dapat melihatnya di paragraf di atas contoh konfigurasi).
Benar bahwa kurva real-time diabaikan untuk kelas dalam, mereka hanya diterapkan pada kelas daun. Namun kurva real-time yang ditentukan pada kelas dalam tersebut diperhitungkan untuk perhitungan pada kelas daun.
Beberapa tutorial mengatakan bahwa jumlah semua kurva waktu nyata tidak boleh lebih tinggi dari 80% dari kecepatan garis, yang lain mengatakan itu tidak boleh lebih dari 70% dari kecepatan garis. Mana yang benar atau mungkin keduanya salah?
Yang mereka maksud adalah:Anda tidak dapat memprioritaskan semua lalu lintas ... Setiap kali Anda memberikan prioritas paket, paket lain harus dikurangi prioritasnya. Jika Anda terlalu menjamin, algoritme menjadi tidak berguna. Tentukan kelas yang mendapatkan prioritas dan tentukan kelas yang mungkin menderita.
Satu tutorial mengatakan Anda akan melupakan semua teorinya. Tidak peduli bagaimana semuanya bekerja (penjadwal dan distribusi bandwidth), bayangkan tiga kurva menurut "model pikiran yang disederhanakan" berikut:real-time adalah bandwidth terjamin yang akan selalu didapat kelas ini. link-share adalah bandwidth yang diinginkan kelas ini sepenuhnya puas, tetapi kepuasan tidak dapat dijamin. Jika ada kelebihan bandwidth, kelas bahkan mungkin akan ditawarkan lebih banyak bandwidth daripada yang diperlukan untuk menjadi puas, tetapi mungkin tidak pernah menggunakan lebih dari batas atas. Agar semua ini berfungsi, jumlah semua bandwidth waktu-nyata mungkin tidak di atas xx% dari kecepatan jalur (lihat pertanyaan di atas, persentasenya bervariasi). Pertanyaan:Apakah ini kurang lebih akurat atau kesalahpahaman total tentang HSFC?
Ini benar.
Dan jika asumsi di atas benar-benar akurat, di manakah prioritas model tersebut? Misalnya. setiap kelas mungkin memiliki bandwidth real-time (dijamin), bandwidth link-share (tidak dijamin) dan mungkin batas atas, tetapi masih ada beberapa kelas yang memiliki kebutuhan prioritas lebih tinggi daripada kelas lainnya. Dalam hal ini saya masih harus memprioritaskan entah bagaimana, bahkan di antara lalu lintas real-time dari kelas-kelas itu. Apakah saya akan memprioritaskan dengan kemiringan kurva? Dan jika ya, kurva yang mana? Kurva waktu nyata? Kurva link-share? Kurva batas atas? Mereka semua? Apakah saya akan memberi mereka semua kemiringan yang sama atau masing-masing kemiringan yang berbeda dan bagaimana cara mengetahui kemiringan yang tepat?
Perbedaan antara mis. HFSC dan HTB adalah bahwa HFSC akan memungkinkan Anda untuk menentukan dengan tepat berapa banyak prioritas yang Anda inginkan. Anda melakukannya dengan menentukan batas minimum dan maksimum dengan nilai 'dmax'.
Solusi 3:
Akhirnya sebuah 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 dan posting forum lain tentang HFSC yang sepenuhnya tidak masuk akal; itu hanya menunjukkan betapa rumitnya HFSC, karena banyak orang yang tampaknya ahli dan berpura-pura memahami sepenuhnya HFSC, sebenarnya hanya memiliki sebagian pengetahuan dan membuat pernyataan salah berdasarkan kesalahpahaman konsep dan bagaimana semua pengaturan itu bermain bersama.
Saya pikir saya akhirnya akan menyerah pada HFSC. Jika Anda bisa mengatur HFSC dengan benar, ini mungkin QoS terbaik yang bisa Anda dapatkan, tetapi kemungkinan Anda benar-benar kacau jauh lebih tinggi daripada kemungkinan Anda berhasil.