Qualcuno capisce davvero come funziona la pianificazione HFSC in Linux / BSD?

Ho letto l'articolo SIGCOMM '97 PostScript originale su HFSC, è molto tecnico, ma capisco il concetto di base. Invece di fornire una curva di servizio lineare (come praticamente con qualsiasi altro algoritmo di pianificazione), è possibile specificare una curva di servizio convessa o concava e quindi è possibile disaccoppiare la larghezza di banda e il ritardo. Tuttavia, anche se questo documento menziona il tipo di algoritmi di pianificazione in uso (tempo reale e link-share), menziona sempre solo UNA curva per classe di pianificazione (il disaccoppiamento viene effettuato specificando questa curva, per tale motivo è necessaria solo una curva ).

Ora HFSC è stato implementato per BSD (OpenBSD, FreeBSD, ecc.) Usando il framework di pianificazione ALTQ ed è stato implementato Linux usando il framework di pianificazione TC (parte di iproute2). Entrambe le implementazioni hanno aggiunto due curve di servizio aggiuntive, che NON erano nel documento originale! Una curva di servizio in tempo reale e una curva di servizio con limite superiore. Ancora una volta, si noti che il documento originale menziona due algoritmi di pianificazione (in tempo reale e link-share), ma in quel documento entrambi funzionano con una singola curva di servizio. Non ci sono mai state due curve di servizio indipendenti per nessuno dei due come si trova attualmente in BSD e Linux.

Ancora peggio, alcune versioni di ALTQ sembrano aggiungere una priorità di coda aggiuntiva a HSFC (non esiste nemmeno una priorità nel documento originale). Ho trovato diversi BST HowTo che menzionano questa impostazione di priorità (anche se la pagina man dell'ultima versione ALTQ non conosce tale parametro per HSFC, quindi ufficialmente non esiste nemmeno).

Tutto ciò rende la programmazione HFSC ancora più complessa dell'algoritmo descritto nel documento originale e ci sono tonnellate di tutorial su Internet che spesso si contraddicono a vicenda, sostenendo il contrario dell'altro. Questo è probabilmente il motivo principale per cui nessuno sembra davvero capire come funziona davvero la programmazione HFSC. Prima di poter porre le mie domande, abbiamo bisogno di una configurazione di esempio di qualche tipo. Ne userò uno molto semplice come mostrato nell'immagine qui sotto:

testo alternativo http://f.imagehost.org/0177/hfsc-test-setup.png

Ecco alcune domande alle quali non posso rispondere perché i tutorial si contraddicono a vicenda:

1. Per cosa ho bisogno di una curva in tempo reale? Supponendo che A1, A2, B1, B2 siano tutti 128 kbit / s link-share (nessuna curva in tempo reale per uno dei due), ognuno di questi otterrà 128 kbit / s se il root ha 512 kbit / s da distribuire (e A e B sono entrambi 256 kbit / s ovviamente), giusto? Perché dovrei fornire ad A1 e B1 una curva in tempo reale con 128 kbit / s? Per cosa sarebbe utile? Per dare a quei due una priorità più alta? Secondo il documento originale, posso dare loro una priorità più alta usando una curva , dopo tutto questo è l'HFSC. Assegnando ad entrambe le classi una curva di [256kbit / s 20ms 128kbit / s] entrambe hanno una priorità doppia rispetto a A2 e B2 automaticamente (ottenendo comunque solo 128 kbit / s in media)

2. La larghezza di banda in tempo reale conta ai fini della larghezza di banda di link-share? Ad esempio, se A1 e B1 hanno entrambi solo 64 kbit / s in tempo reale e 64 kbit / s di larghezza di banda per la condivisione dei collegamenti, ciò significa che una volta che vengono serviti a 64 kbit / s in tempo reale, anche il loro requisito di condivisione dei collegamenti è soddisfatto (potrebbero ottenere una larghezza di banda in eccesso, ma ignoriamolo per un secondo) o significa che ottengono altri 64 kbit / s tramite link-share? Quindi ogni classe ha un "requisito" di larghezza di banda in tempo reale più link-share? Oppure una classe ha un requisito più elevato rispetto alla curva in tempo reale se la curva di condivisione del collegamento è superiore alla curva in tempo reale (il requisito di condivisione del collegamento corrente è uguale al requisito di condivisione del collegamento specificato meno la larghezza di banda in tempo reale già fornita a questo classe)?

3. La curva del limite superiore viene applicata anche in tempo reale, solo al link-share o forse ad entrambi? Alcuni tutorial dicono in un modo, altri dicono nell'altro modo. Alcuni sostengono addirittura che il limite superiore sia il massimo per larghezza di banda in tempo reale + larghezza di banda di condivisione link? Qual'è la verità?

4. Supponendo che A2 e B2 siano entrambi 128 kbit / s, fa differenza se A1 e B1 sono solo 128 kbit / s link-share o 64 kbit / s in tempo reale e 128 kbit / s link-share, e in tal caso , che differenza?

5. Se uso la curva separata in tempo reale per aumentare le priorità delle classi, perché avrei bisogno di "curve"? Perché il real-time non è un valore fisso e la condivisione link anche un valore fisso? Perché entrambe le curve? La necessità di curve è chiara nel documento originale, perché esiste un solo attributo di quel tipo per classe. Ma ora, avendo tre attributi (tempo reale, link-share e limite superiore), per cosa ho ancora bisogno di curve su ognuno? Perché dovrei desiderare che la forma delle curve (non la larghezza di banda media, ma le loro pendenze) sia diversa per il traffico in tempo reale e per la condivisione dei collegamenti?

6. Secondo la scarsa documentazione disponibile, i valori della curva in tempo reale vengono totalmente ignorati per le classi interne (classe A e B), vengono applicati solo alle classi foglia (A1, A2, B1, B2). Se questo è vero, perché la configurazione di esempio ALTQ HFSC (cerca la configurazione di esempio 3.3 ) imposta curve in tempo reale su classi interne e afferma che quelle impostano il tasso garantito di quelle classi interne? Non è del tutto inutile? (nota: pshare imposta la curva di condivisione del collegamento in ALTQ e gratta la curva in tempo reale; puoi vederla nel paragrafo sopra la configurazione di esempio).

7. Alcuni tutorial dicono che la somma di tutte le curve in tempo reale potrebbe non essere superiore all'80% della velocità della linea, altri sostengono che non deve essere superiore al 70% della velocità della linea. Qual è quello giusto o forse entrambi hanno torto?

8. Un tutorial ha detto che dovresti dimenticare tutta la teoria. Non importa come funzionano veramente le cose (programmatori e distribuzione della larghezza di banda), immagina le tre curve secondo il seguente "modello mentale semplificato": il tempo reale è la larghezza di banda garantita che questa classe otterrà sempre. link-share è la larghezza di banda che questa classe vuole diventare pienamente soddisfatta, ma la soddisfazione non può essere garantita. Nel caso in cui vi sia una larghezza di banda in eccesso, la classe potrebbe persino ricevere più larghezza di banda del necessario per accontentarsi, ma potrebbe non usare mai più di quanto dice il limite superiore. Perché tutto ciò funzioni, la somma di tutte le larghezze di banda in tempo reale potrebbe non essere superiore al xx% della velocità della linea (vedere la domanda sopra, la percentuale varia). Domanda: è più o meno accurato o un equivoco totale di HSFC?

9. E se il presupposto di cui sopra è davvero accurato, dov'è la priorità in quel modello? Ad esempio, ogni classe potrebbe avere una larghezza di banda in tempo reale (garantita), una larghezza di banda di condivisione link (non garantita) e forse un limite superiore, ma alcune classi hanno esigenze di priorità più elevate rispetto ad altre. In tal caso, devo comunque dare la priorità in qualche modo, anche al traffico in tempo reale di quelle classi. Darei la priorità in base alla pendenza delle curve? E se sì, quale curva? La curva in tempo reale? La curva di link-share? La curva del limite superiore? Tutti loro? Darei a tutti loro la stessa pendenza o ognuna una diversa e come scoprire la pendenza giusta?

Non ho ancora perso la speranza che esista almeno una mano piena di persone in questo mondo che hanno veramente capito HFSC e sono in grado di rispondere a tutte queste domande in modo accurato. E farlo senza contraddirsi a vicenda nelle risposte sarebbe davvero bello ;-)

Leggere i documenti su HFSC e i suoi cugini non è un buon modo per capirlo. L'obiettivo principale del documento HFSC è quello di fornire una rigorosa prova matematica delle sue affermazioni, non spiegando come funziona. In effetti non puoi capire come funziona dal solo documento HFSC, devi leggere anche i documenti a cui fa riferimento. Se hai qualche problema con il reclamo o le loro prove, contattare gli autori degli articoli potrebbe essere una buona idea, altrimenti dubito che saranno interessati a sentirti.

Ho scritto un tutorial per HFSC . Leggilo se le mie spiegazioni di seguito non sono chiare.

Per cosa ho bisogno di una curva in tempo reale? Supponendo che A1, A2, B1, B2 siano tutti 128 kbit / s link-share (nessuna curva in tempo reale per uno dei due), ognuno di questi otterrà 128 kbit / s se il root ha 512 kbit / s da distribuire (e A e B sono entrambi 256 kbit / s ovviamente), giusto? Perché dovrei fornire ad A1 e B1 una curva in tempo reale con 128 kbit / s? Per cosa sarebbe utile? Per dare a quei due una priorità più alta? Secondo il documento originale, posso dare loro una priorità più alta usando una curva, dopo tutto questo è l'HFSC. Assegnando ad entrambe le classi una curva di [256kbit / s 20ms 128kbit / s] entrambe hanno una priorità doppia rispetto a A2 e B2 automaticamente (ottenendo comunque solo 128 kbit / s in media)

La curva in tempo reale e la curva di condivisione dei collegamenti vengono valutate in diversi modi. La curva del tempo reale tiene conto di ciò che una classe ha fatto durante la sua intera storia. Deve farlo per fornire un'accurata allocazione della larghezza di banda e della latenza. Il rovescio della medaglia non è ciò che la maggior parte delle persone considera intuitivamente equo . In tempo reale, se una classe prende in prestito la larghezza di banda quando nessun altro la desidera, viene penalizzata quando qualcun altro la vuole più tardi. Ciò significa che con la garanzia in tempo reale una classe non può ottenere larghezza di banda per un lungo periodo perché l'ha utilizzata in precedenza, quando nessuno lo voleva.

La condivisione dei collegamenti è corretta, in quanto non penalizza una classe per l'utilizzo della larghezza di banda di riserva. Tuttavia, ciò significa che non può fornire forti garanzie di latenza.

La separazione della condivisione dei collegamenti dal fornire garanzie di latenza è la nuova cosa che HFSC mette in campo, e il documento dice altrettanto nella frase di apertura: in questo documento, studiamo modelli gerarchici di gestione delle risorse e algoritmi che supportano sia la condivisione dei collegamenti che la garanzia servizi in tempo reale con ritardo disaccoppiato (priorità) e allocazione della larghezza di banda. La parola chiave in quella frase è disaccoppiata. Tradotto, significa che dovresti dire quanto larghezza di banda inutilizzata deve essere condivisa con ls e specificare quali garanzie in tempo reale (ovvero garanzie di latenza) sono necessarie con rt. I due sono ortogonali.

La larghezza di banda in tempo reale conta ai fini della larghezza di banda di link-share?

Sì. Nel documento HFSC definiscono la larghezza di banda in termini di ciò che la classe ha inviato da quando la classe è diventata backlog (ovvero ha pacchetti in attesa di essere inviati). L'unica differenza tra rt e ls è rt non vede l'ora ogni volta che la classe diventa backlog e calcola la larghezza di banda minima garantita da quel set, mentre la condivisione dei collegamenti sembra solo dall'ultima volta che la classe è stata backlog. Quindi rt prende in considerazione più byte di ls, ma ogni byte che ls considera è anche considerato da rt.

La curva del limite superiore viene applicata anche in tempo reale, solo al link-share o forse ad entrambi?

Il limite superiore non impedisce l'invio dei pacchetti per soddisfare la condizione in tempo reale. I pacchetti inviati in condizioni di tempo reale contano comunque ai fini del limite superiore e pertanto potrebbero ritardare l'invio di un pacchetto in condizioni di condivisione dei collegamenti in futuro. Questa è un'altra differenza tra condivisione in tempo reale e link.

Supponendo che A2 e B2 siano entrambi 128 kbit / s, fa differenza se A1 e B1 sono solo 128 kbit / s link-share o 64 kbit / s in tempo reale e 128 kbit / s link-share, e in tal caso , che differenza?

Sì, fa la differenza. Come spiegato sopra se si utilizza il tempo reale, le latenze sono garantite ma il collegamento non è condiviso in modo equo (e in particolare la classe potrebbe soffrire la fame di larghezza di banda) e i limiti superiori non vengono applicati. Se si utilizza la condivisione dei collegamenti, la latenza non è garantita, ma la condivisione dei collegamenti è corretta, non vi è alcun rischio di fame e viene applicato il limite superiore. Il tempo reale viene sempre controllato prima della condivisione del collegamento, tuttavia ciò non significa che la condivisione del collegamento verrà ignorata. Questo perché i pacchetti vengono contati in modo diverso. Poiché la cronologia viene considerata in tempo reale, un pacchetto potrebbe non essere necessario per soddisfare la garanzia in tempo reale (a causa di un conteggio incluso nella cronologia), ma è necessario per soddisfare la condivisione del collegamento perché ignora il pacchetto storico.

Se uso la curva separata in tempo reale per aumentare le priorità delle classi, perché avrei bisogno di "curve"? Perché il real-time non è un valore fisso e la condivisione link anche un valore fisso? Perché entrambe le curve? La necessità di curve è chiara nel documento originale, perché esiste un solo attributo di quel tipo per classe. Ma ora, avendo tre attributi (tempo reale, link-share e limite superiore), per cosa ho ancora bisogno di curve su ognuno? Perché dovrei desiderare che la forma delle curve (non la larghezza di banda media, ma le loro pendenze) sia diversa per il traffico in tempo reale e per la condivisione dei collegamenti?

La curva per i controlli in tempo reale consente di scambiare una latenza ridotta per una particolare classe di traffico (ad esempio VOIP) con una latenza scarsa per altre classi di traffico (ad esempio e-mail). Quando si decide quale pacchetto inviare sotto il vincolo in tempo reale, HFSC sceglie quello che completerà per primo l'invio. Tuttavia, non utilizza la larghezza di banda del collegamento per calcolare questo, utilizza la larghezza di banda allocata dalla curva in tempo reale. Pertanto, se abbiamo pacchetti VOIP ed e-mail della stessa lunghezza e il pacchetto VOIP ha una curva convessa che dà se un aumento di 10 volte sulla curva concava dell'email, allora verranno inviati 10 pacchetti VOIP prima del pacchetto di posta elettronica pugno. Ma questo accade solo per il tempo di scoppio, che dovrebbe essere al massimo il tempo necessario per inviare alcuni pacchetti, ad esempio milli secondi. Successivamente la curva VOIP dovrebbe appiattirsi, e VOIP non avrà alcun impulso futuro a meno che non si arresti per un po '(che, dato che VOIP è un'applicazione a bassa larghezza di banda, dovrebbe). Il risultato netto di tutto ciò è garantire che i primi due pacchetti VOIP vengano inviati più velocemente di ogni altra cosa, garantendo così una bassa latenza VOIP a spese della posta alta.

Come ho detto prima, poiché la condivisione dei collegamenti non esamina la cronologia, non può fornire garanzie di latenza. Una solida garanzia è ciò che è necessario per il traffico in tempo reale come VOIP. Tuttavia, in media una curva convessa condivisa da link fornirà comunque un aumento di latenza al suo traffico. Non è garantito. Va bene per la maggior parte delle cose, come il traffico web via e-mail.

Secondo la scarsa documentazione disponibile, i valori della curva in tempo reale vengono totalmente ignorati per le classi interne (classe A e B), vengono applicati solo alle classi fogliari (A1, A2, B1, B2). Se questo è vero, perché la configurazione di esempio ALTQ HFSC (cerca la configurazione di esempio 3.3) imposta curve in tempo reale su classi interne e afferma che quelle impostano il tasso garantito di quelle classi interne? Non è del tutto inutile? (nota: pshare imposta la curva di condivisione del collegamento in ALTQ e gratta la curva in tempo reale; puoi vederla nel paragrafo sopra la configurazione di esempio).

La documentazione è corretta La gerarchia (e quindi i nodi interni) non ha alcun effetto sul calcolo del tempo reale di sorta. Non posso dirti perché ALTQ evidentemente pensa di si.

Alcuni tutorial dicono che la somma di tutte le curve in tempo reale potrebbe non essere superiore all'80% della velocità della linea, altri sostengono che non deve essere superiore al 70% della velocità della linea. Qual è quello giusto o forse entrambi hanno torto?

Entrambi hanno torto. Se il 70% o l'80% del tuo traffico ha requisiti di latenza rigida che devono essere specificati in tempo reale, la realtà è che quasi sicuramente non puoi soddisfarli con il link che stai utilizzando. Hai bisogno di un collegamento più veloce.

L'unico modo in cui qualcuno potrebbe pensare che la specifica dell'80% del traffico dovrebbe essere in tempo reale è se stessero percorrendo il tempo reale come una spinta prioritaria. Sì, al fine di fornire garanzie di latenza si sta effettivamente aumentando la priorità di alcuni pacchetti. Ma dovrebbe essere solo per millisecondi. Questo è tutto ciò che un collegamento può far fronte e fornire comunque le garanzie di latenza.

C'è pochissimo traffico che necessita di garanzie di latenza. VOIP è uno, NTP un altro. Il resto dovrebbe essere fatto con la condivisione dei link. Se vuoi che il web sia veloce, lo rendi veloce allocando la maggior parte della capacità dei collegamenti. Quella quota è garantita a lungo termine. Se vuoi che sia a bassa latenza (in media), dagli una curva convessa sotto la condivisione dei collegamenti.

Un tutorial ha detto che dovresti dimenticare tutta la teoria. Non importa come funzionano veramente le cose (programmatori e distribuzione della larghezza di banda), immagina le tre curve secondo il seguente "modello mentale semplificato": il tempo reale è la larghezza di banda garantita che questa classe otterrà sempre. link-share è la larghezza di banda che questa classe vuole diventare pienamente soddisfatta, ma la soddisfazione non può essere garantita. Nel caso in cui vi sia una larghezza di banda in eccesso, la classe potrebbe persino ricevere più larghezza di banda del necessario per accontentarsi, ma potrebbe non usare mai più di quanto dice il limite superiore. Perché tutto ciò funzioni, la somma di tutte le larghezze di banda in tempo reale potrebbe non essere superiore al xx% della velocità della linea (vedere la domanda sopra, la percentuale varia). Domanda: è più o meno accurato o un equivoco totale di HSFC?

È una buona descrizione limite superiore. Mentre la descrizione della condivisione del collegamento è rigorosamente accurata, è fuorviante. Mentre la vera condivisione dei collegamenti non offre le garanzie di latenza dura come fa in tempo reale, fa un lavoro migliore nel dare alla classe la sua larghezza di banda la sua allocazione rispetto ai suoi concorrenti, come CBQ e HTB. Quindi, nel dire che la condivisione di link "non fornisce garanzie", la sta mantenendo a uno standard superiore che qualsiasi altro programmatore può fornire.

La descrizione in tempo reale riesce ad essere sia accurata, ma così fuorviante la definirei sbagliata. Come suggerisce il nome, lo scopo del tempo reale non è quello di garantire una larghezza di banda garantita. Serve a garantire una latenza garantita, ovvero il pacchetto viene inviato ORA, non in modo casuale dopo un certo periodo di tempo, a seconda dell'utilizzo del collegamento. La maggior parte del traffico non richiede latenza garantita.

Detto questo, il tempo reale non offre nemmeno garanzie di latenza perfette. Potrebbe, se anche il collegamento non fosse gestito dalla condivisione del collegamento, ma la maggior parte degli utenti desidera l'ulteriore flessibilità di avere entrambi e non viene fornito gratuitamente. Il tempo reale può mancare alla scadenza di latenza entro il tempo necessario per inviare un pacchetto MTU. (Se succede, sarà perché si trattava di una condivisione del collegamento del pacchetto MTU bloccata mentre in tempo reale manteneva il collegamento inattivo nel caso in cui fosse stato assegnato un pacchetto con una scadenza breve che doveva essere inviato immediatamente. Questa è un'altra differenza tra la condivisione del collegamento e tempo reale. Al fine di fornire le sue garanzie, il tempo reale può deliberatamente mantenere la linea inattiva anche se ci sono pacchetti da inviare, fornendo quindi un utilizzo del collegamento inferiore al 100%. La condivisione collegamento utilizza sempre il 100% della capacità disponibile dei collegamenti. A differenza del tempo reale ,

Il motivo per cui si può dire che il tempo reale offre garanzie di latenza è il ritardo è limitato. Quindi, se stai cercando di offrire una garanzia di latenza di 20 ms su un collegamento da 1 Mbit / sec e la condivisione del collegamento sta inviando pacchetti di dimensioni MTU (1500 byte), sai che uno di quei pacchetti richiederà 12 ms per l'invio. Pertanto, se dici in tempo reale che desideri una latenza di 8 ms, puoi comunque rispettare la scadenza di 20 ms - con una garanzia assoluta.

E se il presupposto di cui sopra è davvero accurato, dov'è la priorità in quel modello? Ad esempio, ogni classe potrebbe avere una larghezza di banda in tempo reale (garantita), una larghezza di banda di condivisione link (non garantita) e forse un limite superiore, ma alcune classi hanno esigenze di priorità più elevate rispetto ad altre. In tal caso, devo comunque dare la priorità in qualche modo, anche al traffico in tempo reale di quelle classi. Darei la priorità in base alla pendenza delle curve? E se sì, quale curva? La curva in tempo reale? La curva di link-share? La curva del limite superiore? Tutti loro? Darei a tutti loro la stessa pendenza o ognuna una diversa e come scoprire la pendenza giusta?

Non esiste un modello di definizione delle priorità. Sul serio. Se vuoi dare priorità assolute al traffico, usa pfifo. Questo è quello che serve. Ma anche stare attenti che se si dà il traffico web priorità assoluta rispetto traffico e-mail, che significa lasciare il traffico web saturare il link e quindi nessun pacchetto e-mail ottenere attraverso, affatto . Tutte le tue connessioni e-mail quindi muoiono.

In realtà nessuno vuole quel tipo di priorità. Quello che vogliono è ciò che HFSC fornisce. Se effettivamente disponi di traffico in tempo reale, HFSC lo fornisce. Ma sarà tutto roba. Per il resto, HFSC ti permette di dire "su un collegamento congestionato, alloca il 90% al web e lascia che la posta goccioli al 10%, e oh invia rapidamente il pacchetto DNS dispari ma non lasciare che qualcuno mi DOS con esso".

È possibile definire le curve con nomi diversi:

• RT, curva in tempo reale, larghezza di banda / ritardo di garanzia.
• ls, curva di condivisione link, condivisione larghezza di banda / ritardo (basata sulla configurazione delle foglie vicine)
• ul, curva limite superiore, massima larghezza di banda / ritardo che può raggiungere.

Per cosa ho bisogno di una curva in tempo reale? Supponendo che A1, A2, B1, B2 siano tutti 128 kbit / s link-share (nessuna curva in tempo reale per uno dei due), ognuno di questi otterrà 128 kbit / s se il root ha 512 kbit / s da distribuire (e A e B sono entrambi 256 kbit / s ovviamente), giusto? Perché dovrei fornire ad A1 e B1 una curva in tempo reale con 128 kbit / s? Per cosa sarebbe utile? Per dare a quei due una priorità più alta? Secondo il documento originale, posso dare loro una priorità più alta usando una curva, dopo tutto questo è l'HFSC. Assegnando ad entrambe le classi una curva di [256kbit / s 20ms 128kbit / s] entrambe hanno una priorità doppia rispetto a A2 e B2 automaticamente (ottenendo comunque solo 128 kbit / s in media)

Quando si effettua una definizione in HFSC con solo le tariffe, imposta automaticamente 'dmax' su 0. Il che significa sostanzialmente che non tiene conto del ritardo. Una buona configurazione HFSC dovrebbe includere sia la larghezza di banda che i limiti di ritardo che si desidera utilizzare per la propria classe, altrimenti l'algoritmo non può capire esattamente quanta priorità dovrebbe avere una classe.

Ogni volta che dai la priorità ai pacchetti, gli altri pacchetti dovranno essere diminuiti in via prioritaria. In base ai valori "dmax" e "rate", tutte le classi verranno multiplexate utilizzando timer virtuali. Fare riferimento a tc-hfsc (7) per ulteriori informazioni.

La larghezza di banda in tempo reale conta ai fini della larghezza di banda di link-share? Ad esempio, se A1 e B1 hanno entrambi solo 64 kbit / s in tempo reale e 64 kbit / s di larghezza di banda per la condivisione dei collegamenti, ciò significa che una volta che vengono serviti a 64 kbit / s in tempo reale, anche il loro requisito di condivisione dei collegamenti è soddisfatto (potrebbero ottenere una larghezza di banda in eccesso, ma ignoriamolo per un secondo) o significa che ottengono altri 64 kbit / s tramite link-share? Quindi ogni classe ha un "requisito" di larghezza di banda in tempo reale più link-share? Oppure una classe ha un requisito più elevato rispetto alla curva in tempo reale se la curva di condivisione del collegamento è superiore alla curva in tempo reale (il requisito di condivisione del collegamento corrente è uguale al requisito di condivisione del collegamento specificato meno la larghezza di banda in tempo reale già fornita a questo classe)?

Se il flusso non supera i limiti della definizione di link-share della classe, la curva in tempo reale non viene mai utilizzata. La definizione di una curva in tempo reale in questo caso consente ad es .: di garantire un certo "dmax".

Se le definizioni di condivisione dei collegamenti sono impeccabili, non avresti bisogno di curve in tempo reale. Potresti semplicemente definire le curve di servizio (sc), ma ciò renderebbe più difficile la tua configurazione.

La curva del limite superiore viene applicata anche in tempo reale, solo al link-share o forse ad entrambi? Alcuni tutorial dicono in un modo, altri dicono nell'altro modo. Alcuni sostengono addirittura che il limite superiore sia il massimo per larghezza di banda in tempo reale + larghezza di banda di condivisione link? Qual'è la verità?

La curva del limite superiore della classe viene applicata solo alla condivisione del collegamento, quando si definisce una curva del limite superiore DEVE definire una curva della condivisione del collegamento. Tuttavia, la curva del limite superiore delle classi principali viene comunque applicata.

Supponendo che A2 e B2 siano entrambi 128 kbit / s, fa differenza se A1 e B1 sono solo 128 kbit / s link-share o 64 kbit / s in tempo reale e 128 kbit / s link-share, e in tal caso , che differenza?

C'è una leggera differenza, ad esempio A2 = 0 kbit / se B2 = 256 kbit / s. Quindi il tempo virtuale per A2 sarà al massimo. Ogni volta che i pacchetti vengono classificati in A2, verranno immediatamente elaborati. Tuttavia, la curva in tempo reale di B2 garantirà comunque che sia in grado di trasmettere almeno 64 kbit / s

Se uso la curva separata in tempo reale per aumentare le priorità delle classi, perché dovrei avere bisogno di "curve"? Perché il real-time non è un valore fisso e la condivisione link anche un valore fisso? Perché entrambe le curve? La necessità di curve è chiara nel documento originale, perché esiste un solo attributo di quel tipo per classe. Ma ora, avendo tre attributi (tempo reale, link-share e limite superiore), per cosa ho ancora bisogno di curve su ognuno? Perché dovrei desiderare che la forma delle curve (non la larghezza di banda media, ma le loro pendenze) sia diversa per il traffico in tempo reale e per la condivisione dei collegamenti?

Le curve in tempo reale non condividono il traffico tra le foglie vicine, come fanno le curve link-share.

Secondo la scarsa documentazione disponibile, i valori della curva in tempo reale vengono totalmente ignorati per le classi interne (classe A e B), vengono applicati solo alle classi fogliari (A1, A2, B1, B2). Se questo è vero, perché la configurazione di esempio ALTQ HFSC (cerca la configurazione di esempio 3.3) imposta curve in tempo reale su classi interne e afferma che quelle impostano il tasso garantito di quelle classi interne? Non è del tutto inutile? (nota: pshare imposta la curva di condivisione del collegamento in ALTQ e gratta la curva in tempo reale; puoi vederla nel paragrafo sopra la configurazione di esempio).

È vero che le curve in tempo reale vengono ignorate per le classi interne, vengono applicate solo alle classi foglia. Tuttavia, le curve in tempo reale definite su tali classi interne vengono prese in considerazione per i calcoli sulle classi fogliari.

Alcuni tutorial dicono che la somma di tutte le curve in tempo reale potrebbe non essere superiore all'80% della velocità della linea, altri sostengono che non deve essere superiore al 70% della velocità della linea. Qual è quello giusto o forse entrambi hanno torto?

Ciò che significano è: non puoi dare la priorità a tutto il traffico ... Ogni volta che dai la priorità ai pacchetti, gli altri pacchetti dovranno essere diminuiti in via prioritaria. Se la garanzia è eccessiva, l'algoritmo diventa inutile. Definire la classe che ottiene la priorità e definire le classi che possono soffrire.

Un tutorial ha detto che dovresti dimenticare tutta la teoria. Non importa come funzionano veramente le cose (programmatori e distribuzione della larghezza di banda), immagina le tre curve secondo il seguente "modello mentale semplificato": il tempo reale è la larghezza di banda garantita che questa classe otterrà sempre. link-share è la larghezza di banda che questa classe vuole diventare pienamente soddisfatta, ma la soddisfazione non può essere garantita. Nel caso in cui vi sia una larghezza di banda in eccesso, la classe potrebbe persino ricevere più larghezza di banda del necessario per accontentarsi, ma potrebbe non usare mai più di quanto dice il limite superiore. Perché tutto ciò funzioni, la somma di tutte le larghezze di banda in tempo reale potrebbe non essere superiore al xx% della velocità della linea (vedere la domanda sopra, la percentuale varia). Domanda: è più o meno accurato o un equivoco totale di HSFC?

Questo è corretto.

E se il presupposto di cui sopra è davvero accurato, dov'è la priorità in quel modello? Ad esempio, ogni classe potrebbe avere una larghezza di banda in tempo reale (garantita), una larghezza di banda di condivisione link (non garantita) e forse un limite superiore, ma alcune classi hanno esigenze di priorità più elevate rispetto ad altre. In tal caso, devo comunque dare la priorità in qualche modo, anche al traffico in tempo reale di quelle classi. Darei la priorità in base alla pendenza delle curve? E se sì, quale curva? La curva in tempo reale? La curva di link-share? La curva del limite superiore? Tutti loro? Darei a tutti loro la stessa pendenza o ognuna una diversa e come scoprire la pendenza giusta?

La differenza tra ad es. HFSC e HTB è che HFSC ti permetterà di definire esattamente la priorità che vuoi avere. Puoi farlo definendo i limiti minimo e massimo con il valore 'dmax'.

Finalmente una guida che sembra spiegare la maggior parte delle incoerenze e anche come l'attuale implementazione sia diversa dall'articolo originale:

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

Secondo questa guida, molte altre guide e post di forum su HFSC sono del tutto privi di senso; mostra solo quanto sia complicato l'HFSC, come molte persone che sembrano essere esperti e fingono di aver compreso appieno l'HFSC, in realtà hanno solo una conoscenza parziale e fanno false dichiarazioni basate sull'incomprensione del concetto e su come tutte queste impostazioni giocano insieme.

Penso che finalmente rinuncerò a HFSC. Se riesci a ottenere correttamente la tua configurazione HFSC, potrebbe essere il miglior QoS che puoi ottenere, ma le probabilità che tu sbagli completamente sono molto più alte delle possibilità che tu abbia successo.

Se non sei in grado di ottenere una sospensione degli autori originali, proverei questo dopo:

1. vai nell'albero dei sorgenti del kernel linux e trova i file C che implementano il "framework di pianificazione TC"
2. Guarda l'intestazione e trova l'autore del codice.
3. Programmatori e-mail del "framework di programmazione TC" chiedendo loro documentazione sulla loro implementazione.

Prova anche a controllare altri documenti più recenti che citano questo. Potrebbero esserci nuovi documenti là fuori che sono una continuazione della ricerca in questo settore e potrebbero includere ulteriori informazioni sulle domande che stai ponendo.