Bant Genişliğini Paylaşma ve HTB aracılığıyla Gerçek Zamanlı Trafiği Önceliklendirme, Hangi Senaryo Daha İyi Çalışır?


10

İnternet hattımıza bir tür trafik yönetimi eklemek istiyorum. Birçok belgeyi okuduktan sonra, HFSC'nin benim için çok karmaşık olduğunu düşünüyorum (tüm eğrileri bilmiyorum, korkarım ki asla doğru yapamayacağım), CBQ tavsiye edilmez ve temel olarak HTB çoğu insan için gitmek.

Dahili ağımızın üç "segmenti" vardır ve bant genişliğini bunlar arasında (en azından başlangıçta) az çok eşit olarak paylaşmak istiyorum. Ayrıca en az üç çeşit trafiğe (gerçek zamanlı trafik, standart trafik ve toplu trafik) göre trafiğe öncelik vermeliyim. Bant genişliği paylaşımı, gerçek zamanlı trafiğin her zaman mümkün olduğunda birinci sınıf trafik olarak ele alınması gerektiği kadar önemli değildir, ancak elbette başka hiçbir trafik sınıfı da açlıktan ölemez.

Soru, daha mantıklı olan ve aynı zamanda daha iyi gerçek zamanlı verimi garanti eden şey:

  1. Her segment için bir sınıf oluşturma, her biri aynı hıza sahip (HTB geliştiricisine göre yaprak olmayan sınıflar için öncelik önemli değil) ve bu sınıfların her birinde 3 öncelik seviyesi (farklı önceliklere sahip) için üç alt sınıf (yaprak) vardır ve farklı oranlar).

  2. Her öncelik seviyesi için bir sınıfa sahip olmak, her biri farklı bir orana sahip (yine öncelik önemli olmayacaktır) ve her biri segment başına bir tane olmak üzere 3 alt sınıfa sahipken, gerçek zamanlı sınıftaki her üçü de en yüksek prio, en düşük prio sınıf, vb.

Aşağıdaki ASCII sanat resmiyle bunu daha açık hale getirmeye çalışacağım:

Case 1:

root --+--> Segment A
       |       +--> High Prio
       |       +--> Normal Prio
       |       +--> Low Prio
       |
       +--> Segment B
       |       +--> High Prio
       |       +--> Normal Prio
       |       +--> Low Prio
       |
       +--> Segment C
               +--> High Prio
               +--> Normal Prio
               +--> Low Prio

Case 2:

root --+--> High Prio
       |        +--> Segment A
       |        +--> Segment B
       |        +--> Segment C
       |
       +--> Normal Prio
       |        +--> Segment A
       |        +--> Segment B
       |        +--> Segment C
       |
       +--> Low Prio
                +--> Segment A
                +--> Segment B
                +--> Segment C

Durum 1 Çoğu insanın yaptığı gibi görünüyor, ancak HTB uygulama ayrıntılarını doğru bir şekilde okumadığım sürece, Durum 2 daha iyi önceliklendirme sunabilir.

HTB el kitabı, bir sınıfın oranını vurması durumunda, ebeveyninden ödünç alabileceğini ve borç alırken, daha yüksek önceliğe sahip sınıfların her zaman ilk önce bant genişliğini aldığını söylüyor. Bununla birlikte, aynı zamanda, daha düşük bir ağaç düzeyinde kullanılabilir bant genişliğine sahip sınıfların , önceliğe bakılmaksızın, daha yüksek bir ağaç seviyesindeki sınıflara göre her zaman tercih edildiğini belirtmektedir .

Aşağıdaki durumu varsayalım: Segment C trafik göndermiyor. A Bölümü yalnızca olabildiğince hızlı (yalnızca bağlantıyı doyurmaya yetecek kadar) gerçek zamanlı trafik gönderiyor ve B Bölümü yalnızca olabildiğince hızlı (yine, yalnızca tam bağlantıyı doyurmaya yetecek kadar) toplu trafik gönderiyor. Ne olacak?

Dava 1:
Segment A-> Yüksek Prio ve Segment B-> Düşük Prio'nun her ikisi de gönderilecek pakete sahiptir, çünkü A-> Yüksek Prio daha yüksek önceliğe sahiptir, her zaman önce oranına ulaşana kadar programlanacaktır. Şimdi Segment A'dan borç almaya çalışır, ancak Segment A daha yüksek bir seviyede olduğundan ve Segment B-> Düşük Prio henüz oranına ulaşmadığından, bu sınıf şimdi, bu orana ulaşana ve Segment B Her ikisi de oranlarına ulaştığında, her ikisi de tekrar aynı seviyededir ve şimdi Segment A-> Yüksek Prio, Segment A oranına ulaşana kadar tekrar kazanacaktır. Segment C, garantili trafiğini kullanmadığı için bol miktarda trafik yedeği), ancak yine Segment B-> Düşük Prio'nun da kök seviyesine ulaşmasını beklemek zorundadır. Bu olduğunda,

Durum 2:
Yüksek Prio-> Segment A ve Düşük Prio-> Segment B'nin gönderilecek paketleri vardır, yine Yüksek Prio-> Segment A daha yüksek önceliğe sahip olduğu için kazanacaktır. Oranına ulaştığında, bant genişliği yedeklemesi olan Yüksek Prio'dan borç almayı dener, ancak daha yüksek bir seviyede olmak, düşük Prio-> Segment B'nin de oranına ulaşmasını beklemek zorundadır. Her ikisi de oranlarına ulaştığında ve her ikisi de borç almak zorunda kaldığında, Yüksek Prio-> Segment A, Yüksek Prio sınıfının oranına ulaşana kadar tekrar kazanacaktır. Bu gerçekleştiğinde, yine bol miktarda bant genişliği kalan (Normal Prio'nun tüm bant genişliği şu anda kullanılmıyor) olan kökten borç almaya çalışır, ancak Düşük Prio-> Segment B, hız sınırına ulaşana kadar tekrar beklemek zorundadır. Düşük Prio sınıfı ve aynı zamanda kökten borç almaya çalışır. Son olarak her iki sınıf da kökten borç almaya çalışır, öncelik dikkate alınır ve Yüksek Prio->

Her iki durumda da gerçek zamanlı trafik bazen toplu trafiği beklemek zorunda olduğundan, en az optimal görünmektedir, ancak çok fazla bant genişliği kalsa bile ödünç alabilir. Bununla birlikte, 2 durumunda, gerçek zamanlı trafik, durum 1'den daha az beklemek zorunda gibi görünüyor, çünkü sadece toplu trafik oranına ulaşılıncaya kadar beklemek zorunda, ki bu büyük olasılıkla bir tüm segmentin oranından daha düşüktür (ve 1 beklemek zorunda oranıdır). Yoksa burada tamamen yanlış mıyım?

Öncelikli bir qdisc kullanarak daha basit kurulumları düşündüm. Ancak öncelik sıraları, bir şekilde sınırlı olmadıkları takdirde açlığa neden olmaları gibi büyük bir soruna sahiptir. Açlık kabul edilemez. Tabii ki, hızı sınırlamak ve böylece açlıktan kaçınmak için her öncelik sınıfına bir TBF (Token Kova Filtresi) koyabilir, ancak bunu yaparken, tek bir öncelik sınıfı, diğer tüm öncelik sınıfları olsa bile, bağlantıyı artık kendi başına doyuramaz TBF boşsa, bunun olmasını engeller. Ve bu da en uygunudur, çünkü şu anda başka hiçbir sınıfa ihtiyaç duyulmuyorsa sınıf neden satırın bant genişliğinin% 100'ünü alamaz?

Bu kurulumla ilgili herhangi bir yorumunuz veya fikriniz var mı? Standart tc qdiscs kullanarak yapmak çok zor görünüyor. Bir programcı olarak sadece kendi zamanlayıcımı yazabilseydim (ki yapmama izin verilmiyor) bu kadar kolay bir işti.

Yanıtlar:


1

Ben htb doğru anlamak, o zaman oranı "garanti edilir". Bu araçlar size sahip "gerçek zamanlı" trafik oranı hakkında fikir. Ancak bu oran aşılırsa borçlanır. Birkaç sınıf ödünç almak istiyorsa, prio devreye girmelidir. Garantili oranlar fiziksel sınırı arttırmalıdır. Aksi takdirde çok fazla güçlük var.

IMHO, Durum A, kök düzeyinde öncelik veya hız sınırlamanız olması gerektiğinden hiçbir zaman gerçekten çalışmaz. Farklı segmentteki öncelikler / oranlar birbirinden hiçbir şey bilmiyor ve eşit olarak ele alınacak.

Muhtemelen istediğiniz şey: Düşük ve normal prio için "oranı" 0'a veya yakınına koyun ve bant genişliğinin geri kalanı için "tavan" ekleyin, yüksek prio için fizikselin% ​​100'ünü garanti edersiniz.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.