Soluzione 1:
Leggere i giornali su HFSC e sui suoi cugini non è un buon modo per capirlo. L'obiettivo principale del documento HFSC è fornire una rigorosa prova matematica delle sue affermazioni, non spiegare come funziona. In effetti non puoi capire come funziona solo dal documento HFSC, devi leggere anche i documenti a cui fa riferimento. Se hai qualche problema con l'affermazione 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 qui sotto non sono chiare.
Per cosa ho bisogno di una curva in tempo reale? Supponendo che A1, A2, B1, B2 siano tutti a 128 kbit/s di link-share (nessuna curva in tempo reale per nessuno dei due), ognuno di essi otterrà 128 kbit/s se la radice ha 512 kbit/s da distribuire (e A e B sono entrambi a 256 kbit/s ovviamente), giusto? Perché dovrei inoltre dare ad A1 e B1 una curva in tempo reale con 128 kbit/s? A cosa servirebbe? Per dare a questi 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 a entrambe le classi una curva di [256kbit/s 20ms 128kbit/s] entrambe hanno automaticamente il doppio della priorità rispetto ad A2 e B2 (ottenendo comunque solo 128 kbit/son in media)
La curva in tempo reale e la curva di condivisione dei collegamenti vengono valutate in modi diversi. La curva in tempo reale tiene conto di ciò che una classe ha fatto nel corso della sua intera storia. Deve farlo per fornire un'allocazione accurata della larghezza di banda e della latenza. Il rovescio della medaglia non è ciò che la maggior parte delle persone pensa intuitivamente come giusto . In tempo reale, se una classe prende in prestito la larghezza di banda quando nessun altro la vuole, viene penalizzata quando qualcun altro la vuole indietro in seguito. 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 prima, quando nessuno la voleva.
La condivisione del collegamento è giusta, in quanto non penalizza una classe per l'utilizzo della larghezza di banda di riserva. Tuttavia, ciò significa che non può fornire solide garanzie di latenza.
La separazione della condivisione dei collegamenti dal fornire garanzie di latenza è la novità che HFSC porta sul tavolo, e il documento lo dice nella sua frase di apertura:In questo documento, studiamo i modelli e gli algoritmi di gestione delle risorse gerarchiche che supportano entrambi i link- condivisione e servizi in tempo reale garantiti con ritardo disaccoppiato (priorità) e allocazione della larghezza di banda. La parola chiave in quella frase è disaccoppiata. Tradotto, significa che devi dire come la 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 per la larghezza di banda di condivisione del collegamento?
Sì. Nel documento HFSC definiscono la larghezza di banda in termini di ciò che la classe ha inviato da quando la classe è diventata backlog (cioè ha pacchetti in attesa di essere inviati). L'unica differenza tra rt e ls è che rt guarda avanti ogni volta che la classe è diventata arretrata e calcola la larghezza di banda garantita più bassa da quel set, mentre la condivisione del collegamento guarda solo dall'ultima volta che la classe è stata arretrata. Sort prende in considerazione più byte di ls, ma ogni byte considerato da ls viene considerato anche da rt.
La curva del limite superiore viene applicata anche al tempo reale, solo alla condivisione tramite link o forse a entrambe?
Il limite superiore non impedisce l'invio di pacchetti per soddisfare la condizione di tempo reale. I pacchetti inviati nella condizione di tempo reale vengono comunque conteggiati ai fini del limite superiore e quindi potrebbero ritardare l'invio di un pacchetto nella condizione di condivisione del collegamento in futuro. Questa è un'altra differenza tra il tempo reale e la condivisione tramite link.
Supponendo che A2 e B2 siano entrambi a 128 kbit/s, fa alcuna differenza se A1 e B1 sono solo link-share a 128 kbit/s o 64 kbit/s in tempo reale e link-share a 128 kbit/s, e se sì, cosa 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 di carenza di larghezza di banda) e i limiti massimi non vengono applicati. Se utilizzi la condivisione del collegamento, la latenza non è garantita, ma la condivisione del collegamento è equa, non vi è alcun rischio di fame e viene applicato il limite massimo. Il tempo reale viene sempre controllato prima della condivisione del collegamento, tuttavia ciò non significa necessariamente che la condivisione del collegamento verrà ignorata. Questo perché i pacchetti vengono conteggiati in modo diverso. Poiché la cronologia è considerata in tempo reale, un pacchetto potrebbe non essere necessario per soddisfare la garanzia in tempo reale (a causa di uno conteggiato incluso dalla cronologia) ma è necessario per soddisfare la condivisione del collegamento perché ignora il pacchetto storico.
Se uso la curva in tempo reale separata per aumentare le priorità delle classi, perché avrei bisogno di "curve"? Perché il tempo reale non è un valore fisso e anche la condivisione dei collegamenti non è un valore fisso? Perché entrambe le curve? La necessità delle curve è chiara nel documento originale, perché esiste un solo attributo di quel tipo per classe. Ma ora, avendo tre attributi (tempo reale, condivisione link e limite superiore) a cosa mi servono ancora le curve su ognuno? Perché dovrei volere che la forma delle curve (non la larghezza di banda media, ma le loro pendenze) fosse diversa per il traffico in tempo reale e di condivisione dei collegamenti?
La curva per i controlli in tempo reale consente di scambiare una latenza ridotta per una particolare classe di traffico (ad es. VOIP) con una latenza scarsa per altre classi di traffico (ad es. e-mail). Quando si decide quale pacchetto inviare in base al vincolo di tempo reale, HFSC sceglie quello che completerà l'invio per primo. Tuttavia, non utilizza la larghezza di banda del collegamento per calcolarlo, utilizza la larghezza di banda assegnata dalla curva in tempo reale. Pertanto, se disponiamo di pacchetti VOIP ed e-mail della stessa lunghezza e il pacchetto VOIP ha una curva convessa che aumenta di 10 volte la curva concava per l'e-mail, verranno inviati 10 pacchetti VOIP prima del primo pacchetto e-mail. Ma questo accade solo per il tempo di burst, che dovrebbe essere al massimo il tempo necessario per inviare alcuni pacchetti, ovvero milli secondi. Successivamente la curva VOIP dovrebbe appiattirsi e il VOIP non riceverà alcun impulso futuro a meno che non si ritiri per un po '(cosa che, dato che VOIP è un'applicazione a bassa larghezza di banda, dovrebbe). Il risultato netto di tutto ciò è garantire che quei primi due pacchetti VOIP vengano inviati più velocemente di qualsiasi altra cosa, dando così al VOIP una bassa latenza a scapito dell'e-mail che ottiene un'elevata latenza.
Come ho detto prima, poiché la condivisione dei collegamenti non guarda alla cronologia non può dare garanzie di latenza. Una garanzia solida come una roccia è ciò che serve per il traffico in tempo reale come il VOIP. Tuttavia, in media una curva convessa condivisa da un collegamento fornirà comunque un aumento della latenza al suo traffico. Non è solo garantito. Va bene per la maggior parte delle cose, come il traffico web tramite email.
Secondo la poca documentazione disponibile, i valori delle curve in tempo reale sono totalmente ignorati per le classi interne (classe A e B), sono applicati solo alle classi foglia (A1, A2, B1, B2). Se questo è vero, perché la configurazione di esempio ALTQ HFSC (cercare 3.3 Sampleconfiguration) imposta le curve in tempo reale sulle classi interne e afferma che quelle impostano il tasso garantito di quelle classi interne? Non è del tutto inutile? (nota:pshare imposta la curva link-share in ALTQ e gratta la curva in tempo reale; puoi vederlo 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. Non posso dirti perché ALTQ evidentemente pensa di sì.
Alcuni tutorial dicono che la somma di tutte le curve in tempo reale potrebbe non essere superiore all'80% della velocità della linea, altri dicono che non deve essere superiore al 70% della velocità della linea. Quale ha ragione o forse hanno torto entrambi?
Entrambi sono sbagliati. 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 collegamento che stai utilizzando. Hai bisogno di un collegamento più veloce.
L'unico modo in cui qualcuno potrebbe pensare di specificare l'80% del traffico dovrebbe essere in tempo reale è se stesse calpestando il tempo reale come un aumento prioritario. Sì, al fine di fornire garanzie di latenza, in effetti stai aumentando la priorità di alcuni pacchetti. Ma dovrebbe essere solo per millisecondi. Questo è tutto ciò che un collegamento può affrontare 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 assegnandogli la maggior parte della capacità dei link. Quella condivisione è garantito a lungo termine. Se vuoi che sia a bassa latenza (in media), dagli una curva convessa sotto la condivisione dei link.
Un tutorial ha detto che devi dimenticare tutta la teoria. Non importa come funzionino realmente le cose (schedulatori 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 soddisfatti, ma la soddisfazione non può essere garantita. Nel caso in cui ci sia larghezza di banda in eccesso, alla classe potrebbe anche essere offerta più larghezza di banda del necessario per essere soddisfatta, ma potrebbe non utilizzare mai più del limite superiore indicato. Affinché 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 si tratta di un totale fraintendimento di HSFC?
È una buona descrizione del limite superiore. Sebbene la descrizione della condivisione del collegamento sia rigorosamente accurata, è fuorviante. Sebbene sia vero che la condivisione dei collegamenti non offre le garanzie di latenza rigida come fa il 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 dire che la condivisione dei link "non fornisce garanzie" significa mantenerla su uno standard più alto che qualsiasi altro programmatore può fornire.
La descrizione del tempo reale riesce ad essere sia accurata, ma così fuorviante che la definirei sbagliata. Come suggerisce il nome, lo scopo del tempo reale non è quello di fornire una larghezza di banda garantita. Serve per fornire una latenza garantita, ovvero il pacchetto viene inviato ADESSO, non un periodo di tempo casuale dopo, a seconda di come viene utilizzato il collegamento. La maggior parte del traffico non necessita di latenza garantita.
Detto questo, neanche il tempo reale offre garanzie di latenza perfette. Potrebbe, se il collegamento non fosse gestito anche dalla condivisione del collegamento, ma la maggior parte degli utenti desidera la flessibilità aggiuntiva di avere entrambi e non è gratuito. Il tempo reale può perdere la sua scadenza di latenza per il tempo necessario per inviare un pacchetto MTU. (Se succede, sarà perché si è intrufolata una condivisione di collegamento a pacchetto MTU mentre in tempo reale manteneva il collegamento inattivo nel caso in cui fosse stato fornito un pacchetto con una scadenza breve che doveva essere inviato immediatamente. Questa è un'altra differenza tra la condivisione di collegamento e in tempo reale. Per dare le sue garanzie il tempo reale può deliberatamente mantenere la linea inattiva anche se ci sono pacchetti da inviare, a condizione quindi di utilizzare meno del 100% del collegamento. La condivisione del collegamento utilizza sempre il 100% della capacità dei collegamenti disponibili. A differenza del tempo reale , si può dire che sia "preservazione del lavoro".)
Il motivo per cui si può affermare che il tempo reale offre garanzie di latenza rigida è che 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 impiegherà 12 ms per essere inviato. 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 l'ipotesi di cui sopra è davvero accurata, dov'è la priorità in quel modello? Per esempio. ogni classe potrebbe avere una larghezza di banda in tempo reale (garantita), una larghezza di banda di condivisione del collegamento (non garantita) e forse un limite superiore, ma comunque alcune classi hanno esigenze di priorità più elevate rispetto ad altre classi. In tal caso devo ancora dare la priorità in qualche modo, anche tra il traffico in tempo reale di quelle classi. Darei la priorità alla pendenza delle curve? E se sì, quale curva? La curva in tempo reale? La curva link-share? La curva limite superiore? Tutti loro? Darei a tutti la stessa pendenza o a ciascuno una diversa e come scoprire la giusta pendenza?
Non esiste un modello di priorità. Sul serio. Se vuoi dare priorità assoluta al traffico, usa pfifo. Ecco a cosa serve. Ma fai anche attenzione che se dai al traffico web la priorità assoluta rispetto al traffico email, ciò significa lasciare che il traffico web saturi il collegamento e quindi nessun pacchetto email possa passare, per niente . Tutte le tue connessioni e-mail si interrompono.
In realtà nessuno vuole quel tipo di priorità. Quello che vogliono è ciò che fornisce HFSC. Se hai effettivamente traffico in tempo reale, HFSC lo fornisce. Ma sarà roba tutta. Per il resto, HFSC ti consente di dire "su un collegamento congestionato, alloca il 90% al Web e lascia che l'e-mail arrivi al 10%, e oh invia rapidamente lo strano pacchetto DNS ma non lasciare che qualcuno mi DOS con esso." /P>
Soluzione 2:
Puoi definire le curve con nomi diversi:
- rt, curva in tempo reale, garanzia di larghezza di banda/ritardo.
- ls, curva link-share, larghezza di banda/condivisione ritardo (basata sulla configurazione delle foglie vicine)
- ul, curva del 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 a 128 kbit/s di link-share (nessuna curva in tempo reale per nessuno dei due), ognuno di essi otterrà 128 kbit/s se la radice ha 512 kbit/s da distribuire (e A e B sono entrambi a 256 kbit/s ovviamente), giusto? Perché dovrei inoltre dare ad A1 e B1 una curva in tempo reale con 128 kbit/s? A cosa servirebbe? Per dare a questi 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 a entrambe le classi una curva di [256kbit/s 20ms 128kbit/s] entrambe hanno automaticamente il doppio della priorità rispetto ad A2 e B2 (ottenendo comunque solo 128 kbit/son in media)
Quando crei una definizione in HFSC solo con i tassi, 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 vuoi utilizzare per la tua classe, altrimenti l'algoritmo non può capire esattamente quanta priorità dovrebbe avere una classe.
Ogni volta che dai la priorità ai pacchetti, la priorità degli altri pacchetti dovrà essere ridotta. In base ai valori 'dmax' e 'rate' tutte le classi verranno multiplexate utilizzando timer virtuali. Fare riferimento a tc-hfsc(7) per maggiori informazioni.
La larghezza di banda in tempo reale conta per la larghezza di banda di condivisione del collegamento? se A1 e B1 hanno entrambi solo 64kbit/s di larghezza di banda in tempo reale e 64kbit/slink-share, significa che una volta che vengono serviti a 64kbit/s in tempo reale, anche il loro requisito di condivisione del collegamento è soddisfatto (potrebbero ottenere larghezza di banda in eccesso, ma ignoriamolo per un secondo) o questo significa che ottengono altri 64 kbit/s tramite link-share? Quindi ogni classe ha un "requisito" di larghezza di banda in tempo reale più condivisione di link? Oppure una classe ha un requisito più elevato rispetto alla curva in tempo reale solo 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 questa classe)?
Se il flusso non supera i limiti della definizione di condivisione del collegamento della classe, la curva in tempo reale non viene mai utilizzata. La definizione di una curva in tempo reale in questo caso consente ad esempio:di garantire un certo 'dmax'.
Se le tue 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ò farebbe lavorare di più la tua configurazione.
La curva del limite superiore è applicata anche al tempo reale, solo alla condivisione dei collegamenti o forse a entrambi? Alcuni tutorial dicono in un modo, altri dicono nell'altro. Qual è la verità?
La curva del limite superiore della tua classe viene applicata solo alla condivisione del collegamento, quando definisci una curva del limite superiore DEVI definire una curva della condivisione del collegamento. Tuttavia, la curva del limite superiore delle classi padre viene ancora applicata.
Supponendo che A2 e B2 siano entrambi a 128 kbit/s, fa alcuna differenza se A1 e B1 sono solo link-share a 128 kbit/s o 64 kbit/s in tempo reale e link-share a 128 kbit/s, e se sì, cosa differenza?
C'è una leggera differenza, se ad es. A2 =0 kbit/s e 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 in tempo reale separata per aumentare le priorità delle classi, perché avrei bisogno di "curve"? Perché il tempo reale non è un valore fisso e anche la condivisione dei collegamenti non è un valore fisso? Perché entrambe le curve? La necessità delle curve è chiara nel documento originale, perché esiste un solo attributo di quel tipo per classe. Ma ora, avendo tre attributi (tempo reale, condivisione link e limite superiore) a cosa mi servono ancora le curve su ognuno? Perché dovrei volere che la forma delle curve (non la larghezza di banda media, ma le loro pendenze) fosse diversa per il traffico in tempo reale e di condivisione dei collegamenti?
Le curve in tempo reale non condividono il traffico tra foglie vicine, le curve link-share lo fanno.
Secondo la poca documentazione disponibile, i valori delle curve in tempo reale sono totalmente ignorati per le classi interne (classe A e B), sono applicati solo alle classi foglia (A1, A2, B1, B2). Se questo è vero, perché la configurazione di esempio ALTQ HFSC (cercare 3.3 Sampleconfiguration) imposta le curve in tempo reale sulle classi interne e afferma che quelle impostano il tasso garantito di quelle classi interne? Non è del tutto inutile? (nota:pshare imposta la curva link-share in ALTQ e gratta la curva in tempo reale; puoi vederlo 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 quelle classi interne vengono prese in considerazione per i calcoli sulle classi foglia.
Alcuni tutorial dicono che la somma di tutte le curve in tempo reale potrebbe non essere superiore all'80% della velocità della linea, altri dicono che non deve essere superiore al 70% della velocità della linea. Quale ha ragione o forse hanno torto entrambi?
Ciò che significano è:non puoi dare la priorità a tutto il traffico ... Ogni volta che dai la priorità ai pacchetti, la priorità degli altri pacchetti dovrà essere ridotta. Se garantisci eccessivamente, l'algoritmo diventa inutile. Definisci le classi che ottengono priorità e definisci le classi che potrebbero risentirne.
Un tutorial ha detto che devi dimenticare tutta la teoria. Non importa come funzionino realmente le cose (schedulatori 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 soddisfatti, ma la soddisfazione non può essere garantita. Nel caso in cui ci sia larghezza di banda in eccesso, alla classe potrebbe anche essere offerta più larghezza di banda del necessario per essere soddisfatta, ma potrebbe non utilizzare mai più del limite superiore indicato. Affinché 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 si tratta di un totale fraintendimento di HSFC?
Questo è corretto.
E se l'ipotesi di cui sopra è davvero accurata, dov'è la priorità in quel modello? Per esempio. ogni classe potrebbe avere una larghezza di banda in tempo reale (garantita), una larghezza di banda di condivisione del collegamento (non garantita) e forse un limite superiore, ma comunque alcune classi hanno esigenze di priorità più elevate rispetto ad altre classi. In tal caso devo ancora dare la priorità in qualche modo, anche tra il traffico in tempo reale di quelle classi. Darei la priorità alla pendenza delle curve? E se sì, quale curva? La curva in tempo reale? La curva link-share? La curva limite superiore? Tutti loro? Darei a tutti la stessa pendenza o a ciascuno una diversa e come scoprire la giusta pendenza?
La differenza tra ad es. HFSC e HTB è che HFSC ti consentirà di definire esattamente quanta priorità vuoi che abbia. Puoi farlo definendo limiti minimi e massimi con il valore 'dmax'.
Soluzione 3:
Finalmente una guida che sembra spiegare la maggior parte delle incoerenze e anche come l'attuale implementazione sia diversa dal documento originale:
http://manpages.ubuntu.com/manpages/precise/man7/tc-hfsc.7.html
Secondo questa guida, molte altre guide e post sul forum sull'HFSC sono completamente senza senso; mostra solo quanto sia complicato l'HFSC, poiché molte persone che sembrano essere esperte e fingono di comprendere 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 interagiscono.
Penso che alla fine rinuncerò all'HFSC. Se riesci a ottenere la giusta configurazione HFSC, potrebbe essere la migliore QoS che puoi ottenere, ma le possibilità che tu sbagli completamente sono molto più alte delle possibilità che tu abbia successo.