Linux / BSD’de HFSC programlamanın nasıl çalıştığını gerçekten anlayan var mı?

Orijinal SIGCOMM '97 PostScript belgesini HFSC hakkında okudum, teknik olarak çok basit, ancak temel konsepti anlıyorum. Doğrusal bir servis eğrisi vermek yerine (hemen hemen tüm diğer programlama algoritmalarında olduğu gibi), bir dışbükey veya içbükey servis eğrisi belirleyebilirsiniz ve böylece bant genişliği ve gecikmeyi ayırmak mümkündür. Ancak, bu yazı kullanılan tür zamanlama algoritmalarından söz etse bile (gerçek zamanlı ve bağlantı paylaşımı), zamanlama sınıfı başına yalnızca bir eğriden bahseder (dekuplaj bu eğri belirtilerek yapılır, bunun için sadece bir eğri gerekir) ).

Şimdi HFSC, ALTQ zamanlama çerçevesini kullanarak BSD (OpenBSD, FreeBSD, vb.) İçin uygulandı ve TC zamanlama çerçevesini (iproute2'nin bir parçası) kullanarak Linux'u uyguladı . Her iki uygulama da, orijinal makalede OLMAYAN iki ek servis eğrisi ekledi ! Gerçek zamanlı bir servis eğrisi ve bir üst limit servis eğrisi. Yine, lütfen orijinal belgenin iki programlama algoritmasından (gerçek zamanlı ve bağlantı paylaşımı) bahsettiğini, ancak bu yazıda her ikisinin de tek bir servis eğrisi ile çalıştığını unutmayın. BSD ve Linux'ta şu anda bulduğunuzdan biri için hiçbiri iki bağımsız servis eğrisi olmamıştır.

Daha da kötüsü, ALTQ'nun bazı sürümlerinin HSFC'ye ek bir sıra önceliği eklediği görülüyor (orijinal belgede de öncelik diye bir şey yok). Birkaç BSD HowTo'nun bu öncelik ayarından bahsettiğini gördüm (en son ALTQ sürümünün man sayfası HSFC için böyle bir parametre bilmese de, resmi olarak bile yok).

Bunların hepsi HFSC çizelgelemesini orijinal belgede açıklanan algoritmadan bile daha karmaşık hale getirir ve internette sık sık birbiriyle çelişen, biri diğerinin tam tersini talep eden tonlarca ders vardır. Bu muhtemelen, HFSC çizelgelemenin gerçekte nasıl çalıştığını gerçekten kimsenin anlamadığını görmesinin temel nedenidir. Sorularımı sormadan önce bir çeşit örnek kurulum yapmalıyız. Aşağıdaki resimde görüldüğü gibi çok basit bir tane kullanacağım:

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

İşte size yanıtlayamadığım bazı sorular: Dersler birbiriyle çelişiyor:

1. Ne için gerçek zamanlı bir eğriye ihtiyacım var? A1, A2, B1, B2’nin hepsinin 128 kbit / s bağlantı payı olduğunu varsayalım (her ikisi için de gerçek zamanlı eğri yok), o zaman kökün dağıtmak için 512 kbit / s olması durumunda bunların her biri 128 kbit / s alır (ve A ve B elbette 256 kbit / s'dir). Neden ayrıca A1 ve B1'e 128 kbit / s ile gerçek zamanlı bir eğri vereyim? Bu ne için iyi olurdu? Bu ikisine daha yüksek öncelik vermek mi? Orijinal makaleye göre, eğri kullanarak onlara daha yüksek öncelik verebilirim , sonuçta HFSC'nin konusu budur. Her iki sınıfa [256kbit / s 20ms 128kbit / s] eğri vererek, her ikisi de otomatik olarak A2 ve B2'den iki kat önceliğe sahiptir (yine de ortalama olarak yalnızca 128 kbit / s elde edilir)

2. Gerçek zamanlı bant genişliği, bağlantı paylaşımı bant genişliğine göre sayılır mı? Örneğin, A1 ve B1, yalnızca 64kbit / s gerçek zamanlı ve 64kbit / s bağlantı paylaşım bant genişliğine sahipse, bu gerçek zamanlı olarak 64kbit / s bir kez servis yapıldığında, bağlantı paylaşımı gereksinimlerinin de karşılanabileceği anlamına gelir (olabilir; fazla bant genişliği elde edersiniz, fakat bunu bir saniye boyunca görmezden gelinelim mi? Öyleyse, her sınıfın gerçek zamanlı artı bağlantı paylaşımı bant genişliği "gereksinimi" var mı? Ya da bir sınıf, yalnızca bağlantı payı eğrisi gerçek zamanlı eğriden daha yüksekse, gerçek zamanlı eğriden daha yüksek bir gereksinime sahip midir? (Geçerli bağlantı paylaşımı gereksinimi, buna önceden sağlanan gerçek zamanlı bant genişliği eksi belirtilen bağlantı paylaşımı gereksinimine eşittir) sınıf)?

3. Üst limit eğrisi de gerçek zamanlı olarak mı, sadece bağlantı paylaşımında mı, yoksa her ikisinde mi uygulanıyor? Bazı dersler bir şekilde, bazıları ise diğer yolu söyler. Hatta bazılarının üst sınırının gerçek zamanlı bant genişliği + bağlantı paylaşımı bant genişliği için maksimum olduğunu iddia ediyor mu? Gerçek ne?

4. A2 ve B2’nin her ikisi de 128 kbit / s olduğu varsayılırsa, A1 ve B1’in yalnızca 128 kbit / s bağlantı payı veya 64 kbit / s gerçek zamanlı ve 128 kbit / s bağlantı payı olması durumunda fark yaratır mı? ne fark?

5. Sınıf önceliklerini artırmak için ayrı gerçek zamanlı eğri kullanırsam neden "eğrilere" ihtiyacım olsun ki? Neden gerçek zamanlı değil düz bir değer ve bağlantı paylaşımı da düz bir değer değil? Neden her ikisi de eğridir? Orijinal kağıtta eğrilere olan ihtiyaç açıktır, çünkü sınıf başına bu türden yalnızca bir özellik vardır. Fakat şimdi, üç özelliğe (gerçek zamanlı, bağlantı paylaşımı ve üst sınır) sahip olmak için, her biri için hala eğrilere ne ihtiyacım var? Neden eğrilerin şekli (ortalama bant genişliği değil, eğimleri) gerçek zamanlı ve bağlantı paylaşımlı trafik için farklı olsun isteyeyim ?

6. Mevcut küçük belgelere göre, gerçek zamanlı eğri değerleri iç sınıflar (A ve B sınıfı) için tamamen göz ardı edilir, sadece yaprak sınıflarına uygulanır (A1, A2, B1, B2). Eğer bu doğruysa, neden ALTQ HFSC örnek konfigürasyonu ( 3.3 Örnek konfigürasyonunu arayın ) iç sınıflarda gerçek zamanlı eğrileri ayarlıyor ve iç sınıfların garantili oranını belirlediklerini iddia ediyor? Bu tamamen anlamsız değil mi? (not: pshare, ALTQ'da link paylaşımı eğrisini ayarlar ve gerçek zamanlı eğriyi rendeleyin; bunu örnek konfigürasyonun üstündeki paragrafta görebilirsiniz).

7. Bazı dersler, tüm gerçek zamanlı eğrilerin toplamının hat hızının% 80'inden yüksek olmadığını, diğerlerinin hat hızının% 70'inden yüksek olmaması gerektiğini söylüyor. Hangisi doğru ya da ikisi de yanlış mı?

8. Bir öğretici tüm teoriyi unutacağınızı söyledi. İşlerin gerçekte nasıl çalıştığı (zamanlayıcılar ve bant genişliği dağılımı) ne olursa olsun, üç eğriyi aşağıdaki "basitleştirilmiş zihin modeline" göre hayal edin: gerçek zamanlı, bu sınıfın her zaman alacağı garantili bant genişliğidir. link-share, bu sınıfın tamamen tatmin olmak istediği bir bant genişliğidir, ancak memnuniyet garanti edilemez. Aşırı bant genişliği olması durumunda, sınıf tatmin olmak için gerekenden daha fazla bant genişliği önerebilir, ancak asla üst sınırdan daha fazlasını kullanamaz. Bütün bunların çalışması için, tüm gerçek zamanlı bant genişliklerinin toplamı hat hızının% xx'inin üzerinde olamaz (yukarıdaki soruya bakın, yüzde değişir). Soru: Bu az çok doğru mu, yoksa HSFC'nin yanlış anlaşılması mı?

9. Ve eğer yukarıdaki varsayım gerçekten doğruysa, bu modelde önceliklendirme nerededir? Örneğin, her sınıfın gerçek zamanlı bir bant genişliği (garantili), bir link-paylaşım bant genişliği (garanti edilmez) ve belki bir üst sınırı olabilir, ancak yine de bazı sınıfların diğer sınıflardan daha yüksek öncelikli ihtiyaçları olabilir. Bu durumda, yine de bir şekilde, bu sınıfların gerçek zamanlı trafiği arasında bile öncelik vermeliyim. Eğrilerin eğimine öncelik verir miyim? Ve eğer öyleyse, hangi eğri? Gerçek zamanlı eğri? Bağlantı payı eğrisi? Üst sınır eğrisi? Hepsi? Hepsine aynı eğimi ya da her birine farklı bir eğim verebilir miyim ve doğru eğimi nasıl bulabilirim?

HFSC'yi gerçekten anlayan ve tüm bu soruları doğru bir şekilde cevaplayabilen, bu dünyada insanlarla dolu bir el olduğuna dair hala bir ümidim yok. Ve cevaplarda birbirleriyle çelişmeden bunu yapmak gerçekten güzel olurdu ;-)

HFSC ve kuzenleriyle ilgili makaleleri okumak, onu anlamak için iyi bir yol değildir. HFSC makalesinin temel amacı, nasıl çalıştığını açıklamak yerine iddialarının kesin bir matematiksel kanıtını sağlamaktır. Aslında, yalnızca HFSC belgesinde nasıl çalıştığını anlayamazsınız, referans aldığı kağıtları da okumalısınız. Hak talebinde veya kanıtlarında bir sorun yaşarsanız, makalelerin yazarlarına başvurmanız iyi bir fikir olabilir, aksi takdirde sizden haber almakla ilgileneceklerinden şüpheliyim.

HFSC için bir ders yazdım . Aşağıdaki açıklamalarım net değilse, okuyun.

Ne için gerçek zamanlı bir eğriye ihtiyacım var? A1, A2, B1, B2’nin hepsinin 128 kbit / s bağlantı payı olduğunu varsayalım (her ikisi için de gerçek zamanlı eğri yok), o zaman kökün dağıtmak için 512 kbit / s olması durumunda bunların her biri 128 kbit / s alır (ve A ve B elbette 256 kbit / s'dir). Neden ayrıca A1 ve B1'e 128 kbit / s ile gerçek zamanlı bir eğri vereyim? Bu ne için iyi olurdu? Bu ikisine daha yüksek öncelik vermek mi? Orijinal makaleye göre, eğri kullanarak onlara daha yüksek öncelik verebilirim, sonuçta HFSC'nin konusu budur. Her iki sınıfa [256kbit / s 20ms 128kbit / s] eğri vererek, her ikisi de otomatik olarak A2 ve B2'den iki kat önceliğe sahiptir (yine de ortalama olarak sadece 128 kbit / s elde edilir)

Gerçek zaman eğrisi ve bağlantı paylaşım eğrisi farklı şekillerde değerlendirilir. Gerçek zaman eğrisi, bir sınıfın tüm tarihi boyunca neler yaptığını hesaba katar. Bunu doğru bant genişliği ve gecikme tahsisi sağlamak için yapmalıdır. Olumsuz tarafı çoğu insanın sezgisel olarak adil olduğunu düşündüğü şey değil . Gerçek zamanlı olarak, eğer başka bir kimse istemediği zaman bir sınıf bant genişliğini ödünç alırsa, bir başkası daha sonra tekrar istediğinde cezalandırılır. Bu, gerçek zamanlı garanti altında bir sınıfın uzun süre boyunca bant genişliği alamayacağı anlamına gelir; çünkü daha önce hiç kimse istemediğinde, onu kullandı.

Bağlantı paylaşımı adildir, çünkü yedek bant genişliğini kullanmak için bir sınıfı cezalandırmaz. Ancak bu, güçlü gecikme garantisi sağlayamayacağı anlamına gelir.

Bağlantı paylaşımının gecikme garantisi sağlamasından ayrılması, HFSC'nin masaya getirdiği yeni şeydir ve makale açılış cümlesinde olduğu kadar çok şey söylemektedir: Bu yazıda, hem bağlantı paylaşımını hem de garantili destekleyen hiyerarşik kaynak yönetimi modellerini ve algoritmaları inceliyoruz. Dekuplaj gecikmeli (öncelik) ve bant genişliği tahsisi ile gerçek zamanlı servisler. Bu cümlede anahtar kelime ayrıştırıldı. Tercüme edildiğinde, kullanılmayan bant genişliğinin ls ile nasıl paylaşılacağını söylemeniz beklenir ve rt ile hangi gerçek zaman garantilerinin (yani gecikme garantileri) gerektiğini belirtmeniz gerekir. İkisi ortogonal.

Gerçek zamanlı bant genişliği, bağlantı paylaşımı bant genişliğine göre sayılır mı?

Evet. HFSC yazısında, sınıfın geri çekilmesinden bu yana sınıfın ne gönderdiğini (ör. Gönderilmeyi bekleyen paketler) bant genişliği tanımlamaktadır. Rt ve ls arasındaki tek fark, rt, sınıfın geri döndüğü her zaman ileriye bakar ve garantili olan en düşük bant genişliğini hesaplar. Bu nedenle rt, ls'den daha fazla bayt dikkate alır, fakat dikkate alınan her byte, rt tarafından da değerlendirilir.

Üst limit eğrisi de gerçek zamanlı olarak mı, sadece bağlantı paylaşımında mı, yoksa her ikisinde mi uygulanıyor?

Üst sınır, gerçek zamanlı koşulu sağlamak için paketlerin gönderilmesini durdurmaz. Gerçek zaman koşulu altında gönderilen paketler hala üst sınıra sayılır ve bu nedenle gelecekte bağlantı paylaşma koşulu altında gönderilen bir paketi geciktirebilir. Bu, gerçek zamanlı ve bağlantı payı arasındaki başka bir farktır.

A2 ve B2’nin her ikisi de 128 kbit / s olduğu varsayılırsa, A1 ve B1’in yalnızca 128 kbit / s bağlantı payı veya 64 kbit / s gerçek zamanlı ve 128 kbit / s bağlantı payı olması durumunda fark yaratır mı? ne fark?

Evet, bir fark yaratıyor. Yukarıda açıklandığı gibi, gerçek zamanlı kullanırsanız, gecikmeler garanti edilir, ancak bağlantı adil bir şekilde paylaşılmaz (ve özellikle sınıf bant genişliğine açlık çekebilir) ve üst sınırlar zorlanmaz. Bağlantı paylaşımını kullanırsanız gecikme süresi garanti edilmez, ancak bağlantı paylaşımı adildir, açlık riski yoktur ve üst sınır uygulanır. Gerçek zamanlı bağlantı paylaşımından önce her zaman kontrol edilir, ancak bu bağlantı paylaşımının göz ardı edileceği anlamına gelmez. Çünkü paketler farklı sayılır. Tarih gerçek zamanlı olarak değerlendirildiğinden, gerçek zamanlı garantiyi karşılamak için bir pakete ihtiyaç duyulmayabilir (geçmişin içinde yer alan bir hesap nedeniyle) ancak tarihsel paketi göz ardı ettiği için bağlantı paylaşımını tatmin etmek için gerekli olabilir.

Sınıf önceliklerini artırmak için ayrı gerçek zamanlı eğri kullanırsam neden "eğrilere" ihtiyacım olsun ki? Neden gerçek zamanlı değil düz bir değer ve bağlantı paylaşımı da düz bir değer değil? Neden her ikisi de eğridir? Orijinal kağıtta eğrilere olan ihtiyaç açıktır, çünkü sınıf başına bu türden yalnızca bir özellik vardır. Fakat şimdi, üç özelliğe (gerçek zamanlı, bağlantı paylaşımı ve üst sınır) sahip olmak için, her biri için hala eğrilere ne ihtiyacım var? Neden eğrilerin şekli (ortalama bant genişliği değil, eğimleri) gerçek zamanlı ve bağlantı paylaşımlı trafik için farklı olsun isteyeyim?

Gerçek zamanlı kontrol eğrisi, diğer trafik sınıfları (örneğin, e-posta) için düşük gecikme süresi için belirli bir trafik sınıfı (örneğin, VOIP) için sıkı gecikme yapmanızı sağlar. Gerçek zamanlı kısıtlama altında hangi paketin gönderileceğine karar verirken HFSC, ilk göndermeyi tamamlayacak olanı seçer. Ancak, bunu hesaplamak için bağlantının bant genişliğini kullanmaz, gerçek zaman eğrisi tarafından tahsis edilen bant genişliğini kullanır. Dolayısıyla, aynı uzunlukta VOIP ve e-posta paketlerimiz varsa ve VOIP paketinde e-posta için içbükey eğri üzerinde 10 katlık bir artış olup olmadığını veren bir dışbükey eğri varsa, ilk e-posta paketinden önce 10 VOIP paketi gönderilir. Fakat bu sadece patlama süresi için olur, bu da birkaç paket göndermek için gereken zamandır - yani milli saniyedir. Bundan sonra VOIP eğrisi düzleşmeli, ve VOIP bir süre geri çekilmediği sürece gelecekteki bir artış elde edemez (VOIP düşük bant genişliği uygulaması olduğu için gerekir). Tüm bunların net sonucu, bu VOIP paketlerinin ilk çiftinin her şeyden daha hızlı gönderilmesini sağlamak, böylece e-posta masraflarının yüksek gecikme olması nedeniyle VOIP'e düşük gecikme süresi sağlamaktır.

Daha önce de söylediğim gibi, bağlantı paylaşımı tarihe bakmadığından gecikme garantisi veremez. VOIP gibi gerçek zamanlı trafik için gerekli olan sağlam bir garantidir. Bununla birlikte, ortalama olarak, bir bağlantı paylaşılan dışbükey eğrisi hala trafiğine bir gecikme sağlayacaktır. Sadece garanti değil. E-posta üzerinden web trafiği gibi çoğu şey için sorun değil.

Mevcut küçük belgelere göre, gerçek zamanlı eğri değerleri iç sınıflar (A ve B sınıfı) için tamamen göz ardı edilir, sadece yaprak sınıflarına uygulanır (A1, A2, B1, B2). Eğer bu doğruysa, neden ALTQ HFSC örnek konfigürasyonu (3.3 Örnek konfigürasyonunu arayın) iç sınıflarda gerçek zamanlı eğrileri ayarlıyor ve bu iç sınıfların garantili oranını belirlediğini iddia ediyor? Bu tamamen anlamsız değil mi? (not: pshare, ALTQ'da link paylaşımı eğrisini ayarlar ve gerçek zamanlı eğriyi rendeleyin; bunu örnek konfigürasyonun üstündeki paragrafta görebilirsiniz).

Belgeler doğru. Hiyerarşinin (ve böylece iç düğümlerin) gerçek zamanın hesaplanması üzerinde hiçbir etkisi yoktur. ALTQ’nun neden açıkça bunu düşündüğünü düşündüğünü söyleyemem.

Bazı dersler, tüm gerçek zamanlı eğrilerin toplamının hat hızının% 80'inden yüksek olmadığını, diğerlerinin hat hızının% 70'inden yüksek olmaması gerektiğini söylüyor. Hangisi doğru ya da ikisi de yanlış mı?

İkisi de yanlış. Trafiğinizin% 70'i veya% 80'i gerçek zamanlı olarak belirtilmesi gereken zor gecikme şartlarına sahipse, gerçekte sizleri kesinlikle kullandığınız link ile tatmin edemezsiniz. Daha hızlı bir bağlantıya ihtiyacınız var.

Birinin trafiğin% 80'ini belirtmenin tek yolu gerçek zamanlı olması gerektiğini düşünmesinin tek yolu, gerçek zamanı öncelikli bir destek olarak görüyor olmalarıdır. Evet, gecikme garantisi sağlamak için, bazı paketlerin önceliğini artırıyorsunuz. Ancak bu sadece milisaniye için olmalıdır. Hepsi bir bağlantının üstesinden gelebilir ve gecikme garantisi veriyor.

Gecikme garantisi gerektiren çok az trafik var. VOIP bir, NTP bir diğeridir. Gerisi bağlantı paylaşımı ile yapılmalıdır. Web'in hızlı olmasını istiyor, çoğu bağlantı kapasitesini tahsis ederek hızlı hale getiriyorsunuz. Bu pay edilir uzun vadede garantili. Düşük gecikme süresi olmasını (ortalama olarak), bağlantı paylaşımı altında dışbükey bir eğri vermesini istiyorsunuz.

Bir öğretici tüm teoriyi unutacağınızı söyledi. İşlerin gerçekte nasıl çalıştığı (zamanlayıcılar ve bant genişliği dağılımı) ne olursa olsun, üç eğriyi aşağıdaki "basitleştirilmiş zihin modeline" göre hayal edin: gerçek zamanlı, bu sınıfın her zaman alacağı garantili bant genişliğidir. link-share, bu sınıfın tamamen tatmin olmak istediği bir bant genişliğidir, ancak memnuniyet garanti edilemez. Aşırı bant genişliği olması durumunda, sınıf tatmin olmak için gerekenden daha fazla bant genişliği önerebilir, ancak asla üst sınırdan daha fazlasını kullanamaz. Bütün bunların çalışması için, tüm gerçek zamanlı bant genişliklerinin toplamı hat hızının% xx'inin üzerinde olamaz (yukarıdaki soruya bakın, yüzde değişir). Soru: Bu az çok doğru mu, yoksa HSFC'nin yanlış anlaşılması mı?

Bu iyi bir tanım üst sınırdır. Bağlantı paylaşım açıklaması kesinlikle doğru olsa da, yanıltıcıdır. Gerçek bağlantı payı gerçek gecikme gibi zor gecikme garantisi vermese de, sınıfa bant genişliğini CBQ ve HTB gibi rakiplerinden daha fazla vermesi daha iyi bir iş çıkarır. Bu nedenle, bağlantı payı "garanti sağlamıyor" demek, onu başka herhangi bir programcının sağlayabileceği bir standartta tutuyor.

Gerçek zamanın açıklaması her ikisinin de doğru olmasını başarır, ama bu yüzden yanıltıcı yanlış diyebilirim. Adından da anlaşılacağı gibi gerçek zamanın amacı garantili bant genişliği vermemek. Garantili gecikme sağlamaktır - yani paket, bağlantının nasıl kullanıldığına bağlı olarak rastgele bir süre değil, ŞİMDİ gönderilir. Trafiğin çoğu, garantili gecikmeye ihtiyaç duymaz.

Bununla birlikte, gerçek zamanlı da mükemmel gecikme garantisi vermez. Bağlantı, bağlantı payı tarafından da yönetilmezse, ancak çoğu kullanıcı her ikisine de sahip olmak için ek esneklik ister ve ücretsiz gelmez. Gerçek zamanlı, bir MTU paketi göndermek için geçen sürenin gecikme tarihini kaçırabilir. (Olursa, derhal gönderilmesi gereken kısa bir son teslim tarihine sahip bir paket verildiği takdirde, bağlantıyı boşta tutarken gerçek zamanlı olarak bağlantı sırasında bir MTU paket bağlantı paylaşımının kopması nedeniyle olacaktır. Bu, bağlantı paylaşımları arasındaki başka bir farktır.) ve gerçek zaman Garantilerini sağlamak için gerçek zaman, gönderilecek paketler olsa bile kasten rölantiyi boşta tutabilir, böylece% 100'den az bağlantı kullanımı sağlanır, Link payı her zaman% 100 bağlantı kullanılabilir kapasitenin% 100'ünü kullanır. ,

Gerçek gecikmenin zor gecikme garantisi sunabileceğinin söylenmesinin nedeni gecikmenin sınırlandırılmış olmasıdır. Yani, 1Mbit / sn bağlantıda 20ms gecikme garantisi sunmaya çalışıyorsanız ve bağlantı paylaşımı MTU boyutlu (1500 bayt) paketler gönderiyorsa, bu paketlerden birinin göndermesi 12ms alacağını biliyorsunuzdur. Böylece, gerçek zamanlı bir 8ms gecikme istediğinizi söylerseniz, 20ms son teslim tarihini yine de kesin bir garanti ile karşılayabilirsiniz.

Ve eğer yukarıdaki varsayım gerçekten doğruysa, bu modelde önceliklendirme nerededir? Örneğin, her sınıfın gerçek zamanlı bir bant genişliği (garantili), bir link-paylaşım bant genişliği (garanti edilmez) ve belki bir üst sınırı olabilir, ancak yine de bazı sınıfların diğer sınıflardan daha yüksek öncelikli ihtiyaçları olabilir. Bu durumda, yine de bir şekilde, bu sınıfların gerçek zamanlı trafiği arasında bile öncelik vermeliyim. Eğrilerin eğimine öncelik verir miyim? Ve eğer öyleyse, hangi eğri? Gerçek zamanlı eğri? Bağlantı payı eğrisi? Üst sınır eğrisi? Hepsi? Hepsine aynı eğimi ya da her birine farklı bir eğim verebilir miyim ve doğru eğimi nasıl bulabilirim?

Bir önceliklendirme modeli yok. Ciddi anlamda. Trafiğe mutlak öncelikler vermek istiyorsanız, pfifo kullanın. Bunun için var. Ama aynı zamanda araç web trafiği bağlantısını doyurmak izin ve böylece hiçbir e-posta paketleri yoluyla elde olduğunu, e-posta trafiği üzerinde web trafiği mutlak öncelik vermek eğer dikkat hiç . Tüm e-posta bağlantılarınız sonra ölür.

Gerçekte kimse bu tür bir önceliklendirmeyi istemez. İstedikleri şey HFSC'nin sağladığı şey. Gerçekten gerçek zamanlı trafiğiniz varsa, HFSC bunu sağlar. Ama hepsi bir şey olacak. HFSC, geri kalanı için "sıkışık bir bağlantıda, web’e% 90 tahsis et ve e-postaların% 10’a kadar damlatılmasını sağla" diyerek izin verir.

Eğrileri farklı isimlerle tanımlayabilirsiniz:

• rt, gerçek zamanlı eğri, bant genişliği / gecikme garantisi.
• ls, bağlantı paylaşımı eğrisi, bant genişliği / gecikme paylaşımı (komşu yaprakların yapılandırmasına bağlı olarak)
• ul, üst limit eğrisi, elde edebileceği maksimum bant genişliği / gecikme.

Ne için gerçek zamanlı bir eğriye ihtiyacım var? A1, A2, B1, B2’nin hepsinin 128 kbit / s bağlantı payı olduğunu varsayalım (her ikisi için de gerçek zamanlı eğri yok), o zaman kökün dağıtmak için 512 kbit / s olması durumunda bunların her biri 128 kbit / s alır (ve A ve B elbette 256 kbit / s'dir). Neden ayrıca A1 ve B1'e 128 kbit / s ile gerçek zamanlı bir eğri vereyim? Bu ne için iyi olurdu? Bu ikisine daha yüksek öncelik vermek mi? Orijinal makaleye göre, eğri kullanarak onlara daha yüksek öncelik verebilirim, sonuçta HFSC'nin konusu budur. Her iki sınıfa [256kbit / s 20ms 128kbit / s] eğri vererek, her ikisi de otomatik olarak A2 ve B2'den iki kat önceliğe sahiptir (yine de ortalama olarak sadece 128 kbit / s elde edilir)

HFSC'de yalnızca tarifelerle bir tanım yaptığınızda, otomatik olarak 'dmax' değerini 0'a ayarlar. Bu, temelde gecikmeyi hesaba katmadığı anlamına gelir. İyi bir HFSC yapılandırması, sınıfınız için kullanmak istediğiniz hem bant genişliğini hem de gecikme sınırlarını içermelidir, aksi halde algoritma, bir sınıfın ne kadar öncelik alması gerektiğini tam olarak çözemez.

Paketlere öncelik verdiğinizde, diğer paketlerin önceliğinde azaltılması gerekecektir. 'Dmax' ve 'rate' değerlerine bağlı olarak, tüm sınıflar sanal zamanlayıcılar kullanılarak çoğullanır. Daha fazla bilgi için tc-hfsc'ye (7) bakın.

Gerçek zamanlı bant genişliği, bağlantı paylaşımı bant genişliğine göre sayılır mı? Örneğin, A1 ve B1, yalnızca 64kbit / s gerçek zamanlı ve 64kbit / s bağlantı paylaşım bant genişliğine sahipse, bu gerçek zamanlı olarak 64kbit / s bir kez servis yapıldığında, bağlantı paylaşımı gereksinimlerinin de karşılanabileceği anlamına gelir (olabilir; fazla bant genişliği elde edersiniz, fakat bunu bir saniye boyunca görmezden gelinelim mi? Öyleyse, her sınıfın gerçek zamanlı artı bağlantı paylaşımı bant genişliği "gereksinimi" var mı? Ya da bir sınıf, yalnızca bağlantı payı eğrisi gerçek zamanlı eğriden daha yüksekse, gerçek zamanlı eğriden daha yüksek bir gereksinime sahip midir? (Geçerli bağlantı paylaşımı gereksinimi, buna önceden sağlanan gerçek zamanlı bant genişliği eksi belirtilen bağlantı paylaşımı gereksinimine eşittir) sınıf)?

Akış, sınıfın bağlantı payı tanımının sınırlarını aşmıyorsa, gerçek zamanlı eğri asla kullanılmaz. Bu durumda gerçek zamanlı bir eğri tanımlamak, örneğin: belirli bir 'dmax' garanti etmek için izin verir.

Bağlantı paylaşımı tanımlarınız kusursuzsa, gerçek zamanlı eğrilere ihtiyacınız olmaz. Yalnızca servis eğrilerini (sc) tanımlayabilirsiniz, ancak bu, yapılandırmanızı daha da zorlaştıracaktır.

Üst limit eğrisi de gerçek zamanlı olarak mı, sadece bağlantı paylaşımında mı, yoksa her ikisinde mi uygulanıyor? Bazı dersler bir şekilde, bazıları ise diğer yolu söyler. Hatta bazılarının üst sınırının gerçek zamanlı bant genişliği + bağlantı paylaşımı bant genişliği için maksimum olduğunu iddia ediyor mu? Gerçek ne?

Sınıfınızın üst sınır eğrisi yalnızca bağlantı paylaşımına uygulanır, bir üst sınır eğrisi tanımladığınızda bir bağlantı paylaşımı eğrisi tanımlamanız GEREKİR. Ancak ebeveyn sınıflarının üst limit eğrisi hala uygulanmaktadır.

A2 ve B2’nin her ikisi de 128 kbit / s olduğu varsayılırsa, A1 ve B1’in yalnızca 128 kbit / s bağlantı payı veya 64 kbit / s gerçek zamanlı ve 128 kbit / s bağlantı payı olması durumunda fark yaratır mı? ne fark?

Örneğin A2 = 0 kbit / s ve B2 = 256 kbit / s ise küçük bir fark vardır. O zaman A2'nin sanal zamanı maksimumda olacak. Paketler A2'de sınıflandırıldığında, anında işlenir. Bununla birlikte, B2'nin gerçek zamanlı eğrisi, bunun en az 64 kbit / sn iletebilmesini sağlar.

Sınıfların önceliklerini artırmak için ayrı gerçek zamanlı eğri kullanırsam neden "eğrilere" ihtiyacım olsun ki? Neden gerçek zamanlı değil düz bir değer ve bağlantı paylaşımı da düz bir değer değil? Neden her ikisi de eğridir? Orijinal kağıtta eğrilere olan ihtiyaç açıktır, çünkü sınıf başına bu türden yalnızca bir özellik vardır. Fakat şimdi, üç özelliğe (gerçek zamanlı, bağlantı paylaşımı ve üst sınır) sahip olmak için, her biri için hala eğrilere ne ihtiyacım var? Neden eğrilerin şekli (ortalama bant genişliği değil, eğimleri) gerçek zamanlı ve bağlantı paylaşımlı trafik için farklı olsun isteyeyim?

Gerçek zamanlı eğriler, komşu yapraklar arasındaki trafiği paylaşmaz, bağlantı paylaşımı eğrileri yapar.

Mevcut küçük belgelere göre, gerçek zamanlı eğri değerleri iç sınıflar (A ve B sınıfı) için tamamen göz ardı edilir, sadece yaprak sınıflarına uygulanır (A1, A2, B1, B2). Eğer bu doğruysa, neden ALTQ HFSC örnek konfigürasyonu (3.3 Örnek konfigürasyonunu arayın) iç sınıflarda gerçek zamanlı eğrileri ayarlıyor ve bu iç sınıfların garantili oranını belirlediğini iddia ediyor? Bu tamamen anlamsız değil mi? (not: pshare, ALTQ'da link paylaşımı eğrisini ayarlar ve gerçek zamanlı eğriyi rendeleyin; bunu örnek konfigürasyonun üstündeki paragrafta görebilirsiniz).

Gerçek zamanlı eğrilerin iç sınıflar için göz ardı edildiği, sadece yaprak sınıflarına uygulandığı doğrudur. Ancak, bu iç sınıflarda tanımlanan gerçek zamanlı eğriler, yaprak sınıflarındaki hesaplamalar için dikkate alınır.

Bazı dersler, tüm gerçek zamanlı eğrilerin toplamının hat hızının% 80'inden yüksek olmadığını, diğerlerinin hat hızının% 70'inden yüksek olmaması gerektiğini söylüyor. Hangisi doğru ya da ikisi de yanlış mı?

Demek istedikleri şudur: Tüm trafiğe öncelik veremezsiniz ... Paketlere öncelik verdiğinizde, diğer paketlerin öncelikli olarak azaltılması gerekecektir. Fazla garanti ederseniz, algoritma anlamsız hale gelir. Öncelik kazandırma sınıfını ve yaşayabilecek sınıfları tanımlayın.

Bir öğretici tüm teoriyi unutacağınızı söyledi. İşlerin gerçekte nasıl çalıştığı (zamanlayıcılar ve bant genişliği dağılımı) ne olursa olsun, üç eğriyi aşağıdaki "basitleştirilmiş zihin modeline" göre hayal edin: gerçek zamanlı, bu sınıfın her zaman alacağı garantili bant genişliğidir. link-share, bu sınıfın tamamen tatmin olmak istediği bir bant genişliğidir, ancak memnuniyet garanti edilemez. Aşırı bant genişliği olması durumunda, sınıf tatmin olmak için gerekenden daha fazla bant genişliği önerebilir, ancak asla üst sınırdan daha fazlasını kullanamaz. Bütün bunların çalışması için, tüm gerçek zamanlı bant genişliklerinin toplamı hat hızının% xx'inin üzerinde olamaz (yukarıdaki soruya bakın, yüzde değişir). Soru: Bu az çok doğru mu, yoksa HSFC'nin yanlış anlaşılması mı?

Doğru.

Ve eğer yukarıdaki varsayım gerçekten doğruysa, bu modelde önceliklendirme nerededir? Örneğin, her sınıfın gerçek zamanlı bir bant genişliği (garantili), bir link-paylaşım bant genişliği (garanti edilmez) ve belki bir üst sınırı olabilir, ancak yine de bazı sınıfların diğer sınıflardan daha yüksek öncelikli ihtiyaçları olabilir. Bu durumda, yine de bir şekilde, bu sınıfların gerçek zamanlı trafiği arasında bile öncelik vermeliyim. Eğrilerin eğimine öncelik verir miyim? Ve eğer öyleyse, hangi eğri? Gerçek zamanlı eğri? Bağlantı payı eğrisi? Üst sınır eğrisi? Hepsi? Hepsine aynı eğimi ya da her birine farklı bir eğim verebilir miyim ve doğru eğimi nasıl bulabilirim?

Örneğin, HFSC ve HTB arasındaki fark, HFSC'nin tam olarak ne kadar priorisation olmasını istediğinizi tanımlamanıza izin vermesidir. Bunu 'dmax' değerinde minimum ve maksimum sınırlar tanımlayarak yaparsınız.

Son olarak, tutarsızlıkların çoğunu ve mevcut uygulamanın orijinal belgeden ne kadar farklı olduğunu açıklayan bir rehber:

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

Bu rehbere göre, HFSC hakkındaki diğer birçok rehber ve forum yazısı tamamen saçmalıktır; sadece HFSC'nin ne kadar karmaşık olduğunu gösterir, çünkü uzman gibi görünen ve HFSC'yi tam anlamış gibi davranan birçok insan, aslında sadece kısmi bilgiye sahip ve kavramın yanlış anlaşılmasına ve tüm bu ayarların nasıl bir araya getirildiğine dayanan yanlış ifadeler yapmış gibi görünüyor.

Sanırım sonunda HFSC'den vazgeçeceğim. HFSC kurulumunuzu doğru bir şekilde yapabiliyorsanız, alabileceğiniz en iyi QoS olabilir, ancak tamamen karışıklık şansınız, başarma şansınızdan çok daha yüksektir.

Orijinal yazarların eline geçemiyorsanız, bundan sonra şunu deneyeceğim:

1. linux çekirdek kaynak ağacına gidin ve "TC çizelgeleme çerçevesini" uygulayan C dosyalarını bulun
2. Başlığa bak ve kodun yazarı bul.
3. "TC çizelgeleme çerçevesi" nin e-posta programcıları, uygulamalarıyla ilgili literatürü isterler.

Ayrıca, bunu alıntı yapan diğer makaleleri kontrol etmeyi deneyin. Bu alanda araştırmanın devamı olan ve sorduğunuz sorular hakkında daha fazla bilgi içeren daha yeni makaleler olabilir.