Skip to content

Qualcuno capisce davvero come funziona lo scheduling HFSC in Linux/BSD?

Esaminiamo ciascuna delle sezioni del nostro sito Web con l'obiettivo di mostrarti sempre informazioni accurate e aggiornate.

Soluzione:

Soluzione 1:

Leggere i documenti sull'HFSC e sui suoi cugini non è un buon modo per capirlo. L'obiettivo principale dell'articolo sull'HFSC è fornire una prova matematica rigorosa delle sue affermazioni, non spiegare come funziona. In effetti, non si può capire come funziona solo dall'articolo sull'HFSC, ma è necessario leggere anche i documenti a cui fa riferimento. Se avete qualche problema con le affermazioni o le loro prove, allora contattare gli autori dei documenti potrebbe essere una buona idea, altrimenti dubito che saranno interessati ad ascoltarvi.

Ho scritto un tutorial per HFSC. Leggetelo se le mie spiegazioni qui sotto non sono chiare.

A cosa mi serve una curva in tempo reale? Supponendo che A1, A2, B1, B2
siano tutti link-share a 128 kbit/s (nessuna curva in tempo reale per nessuno dei due),
ciascuno di essi riceverà 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é
Perché dovrei dare ad A1 e B1 una curva in tempo reale con 128 kbit/s?
A cosa servirebbe? Per dare a questi due una priorità maggiore?
Secondo il documento originale, posso dare loro una priorità più alta utilizzando una curva.
una curva, dopotutto è questo il senso dell'HFSC. Dando a entrambe le
classi una curva di [256kbit/s 20ms 128kbit/s] entrambe hanno il doppio della
di A2 e B2 automaticamente (ricevendo comunque solo 128 kbit/s in media).
in media)

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

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

La separazione tra la condivisione dei collegamenti e la fornitura di garanzie di latenza è la novità che HFSC apporta al tavolo, e il documento lo dice nella sua frase di apertura: In questo lavoro, studiamo modelli e algoritmi di gestione gerarchica delle risorse che supportano sia la condivisione dei collegamenti che i servizi garantiti in tempo reale con l'allocazione disaccoppiata di ritardo (priorità) e larghezza di banda. La parola chiave in questa frase è disaccoppiato. Tradotto, significa che ci si aspetta che si dica come la larghezza di banda inutilizzata deve essere condivisa con ls, e che si specifichi quali garanzie in tempo reale (alias garanzie di latenza) sono necessarie con rt. Le due cose sono ortogonali.

La larghezza di banda in tempo reale conta per la larghezza di banda condivisa?

Sì. Nel documento HFSC si definisce la larghezza di banda in termini di ciò che la classe ha inviato dal momento in cui è diventata arretrata (cioè ha pacchetti in attesa di essere inviati). L'unica differenza tra rt e ls è che rt guarda in avanti da ogni volta che la classe è diventata arretrata e calcola la più bassa larghezza di banda garantita da quell'insieme, mentre link sharing guarda solo dall'ultima volta che la classe è diventata arretrata. Quindi rt prende in considerazione più byte di ls, ma ogni byte che ls considera è considerato anche da rt.

La curva del limite superiore si applica anche al tempo reale, solo al link-share,
o forse a entrambi?

Il limite superiore non impedisce l'invio di pacchetti per soddisfare la condizione di tempo reale. I pacchetti inviati in tempo reale contano comunque per il limite superiore e quindi possono ritardare l'invio di un pacchetto in futuro in condizioni di condivisione del collegamento. Questa è un'altra differenza tra tempo reale e condivisione del collegamento.

Supponendo che A2 e B2 siano entrambi a 128 kbit/s, fa qualche differenza se
A1 e B1 sono solo a 128 kbit/s in condivisione di link, o a 64 kbit/s in tempo reale e a 128 kbit/s in condivisione di link.
128 kbit/s in tempo reale e 128 kbit/s in link-share e, in caso affermativo, che differenza c'è?

Sì, fa differenza. Come spiegato sopra, se si usa il tempo reale, le latenze sono garantite ma il collegamento non è condiviso in modo equo (e in particolare la classe potrebbe soffrire di fame di banda) e i limiti superiori non sono applicati. Se si usa la condivisione del collegamento, la latenza non è garantita, ma la condivisione del collegamento è equa, non c'è rischio di inedia e il limite superiore è applicato. Il tempo reale viene sempre controllato prima della condivisione del collegamento, ma questo non significa necessariamente che la condivisione del collegamento venga ignorata. Questo perché i pacchetti vengono contati in modo diverso. Poiché la cronologia viene considerata dal tempo reale, un pacchetto potrebbe non essere necessario per soddisfare la garanzia del tempo reale (a causa di un pacchetto conteggiato 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é dovrei avere bisogno di "curve"?
classi, perché avrei bisogno di "curve"? Perché il tempo reale non è un valore
e anche la condivisione dei collegamenti è un valore piatto? Perché sono entrambe curve? La necessità
di curve è chiara nel documento originale, perché c'è un solo
attributo di questo tipo per classe. Ma ora, avendo tre attributi
(tempo reale, condivisione dei link e limite superiore) a cosa mi servono ancora le curve?
curve per ciascuno di essi? Perché dovrei volere che la forma delle curve (non la larghezza di banda media
ma le loro pendenze) siano diverse per il traffico in tempo reale e per quello in condivisione?
traffico in tempo reale e per quello in condivisione?

La curva per i controlli in tempo reale consente di scambiare una latenza elevata per una particolare classe di traffico (ad esempio VOIP) con una latenza scarsa per altre classi di traffico (ad esempio la posta elettronica). Quando si decide quale pacchetto inviare in base al vincolo del tempo reale, HFSC sceglie quello che completerà l'invio per primo. Tuttavia, non utilizza la larghezza di banda del collegamento per calcolare questo dato, ma la larghezza di banda allocata dalla curva del tempo reale. Pertanto, se abbiamo pacchetti VOIP e di posta elettronica della stessa lunghezza e il pacchetto VOIP ha una curva convessa che offre un incremento di 10 volte rispetto alla curva concava della posta elettronica, allora 10 pacchetti VOIP saranno inviati prima del primo pacchetto di posta elettronica. Ma questo avviene solo per il tempo di burst, che dovrebbe essere al massimo il tempo necessario per l'invio di alcuni pacchetti, ovvero milli secondi. In seguito, la curva del VOIP dovrebbe appiattirsi e il VOIP non otterrà alcun incremento futuro, a meno che non si faccia marcia indietro per un po' (cosa che, dato che il VOIP è un'applicazione a bassa larghezza di banda, dovrebbe fare). Il risultato netto di tutto questo è garantire che i primi due pacchetti VOIP vengano inviati più velocemente di qualsiasi altra cosa, dando così al VOIP una bassa latenza a scapito dell'alta latenza della posta elettronica.

Come ho detto in precedenza, poiché il link share non guarda alla cronologia, non può dare garanzie di latenza. Una garanzia solida è necessaria per il traffico in tempo reale come il VOIP. Tuttavia, in media, una curva convessa condivisa dal link fornirà comunque un aumento di latenza al suo traffico. Solo che non è garantito. Questo va bene per la maggior parte delle cose, come il traffico web via e-mail.

Secondo la poca documentazione disponibile, i valori delle curve in tempo reale
in tempo reale sono totalmente ignorati per le classi interne (classe A e B), vengono
solo per le classi interne (classe A e B), mentre vengono applicati solo alle classi esterne (A1, A2, B1, B2). Se questo è vero, perché
la configurazione di esempio di ALTQ HFSC (cercare 3.3 Configurazione di esempio)
configurazione) imposta curve in tempo reale sulle classi interne e sostiene che queste
che queste definiscono il tasso garantito di tali classi interne? Non è forse
completamente inutile? (nota: pshare imposta la curva di condivisione dei collegamenti in ALTQ
e grate la curva in tempo realee; lo si può vedere 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 so dire perché ALTQ pensi che sia così.

Alcuni tutorial dicono che la somma di tutte le curve in tempo reale non può essere superiore all'80% della velocità della linea.
dell'80% della velocità della linea, altri dicono che non deve essere superiore al 70% della velocità della linea.
della velocità della linea. Quale dei due ha ragione o forse sono entrambi sbagliati?

Entrambi sono sbagliati. Se il 70% o l'80% del traffico ha requisiti di latenza rigidi che devono essere specificati in tempo reale, la realtà è che quasi certamente non è possibile soddisfarli con il collegamento in uso. Avete bisogno di un collegamento più veloce.

L'unico modo in cui qualcuno potrebbe pensare di specificare che l'80% del traffico deve essere in tempo reale è se si sta facendo leva sul tempo reale per aumentare la priorità. Sì, per fornire garanzie di latenza si sta in effetti aumentando la priorità di alcuni pacchetti. Ma dovrebbe essere solo per millisecondi. Questo è tutto ciò che un collegamento può sopportare e fornire comunque le garanzie di latenza.

C'è pochissimo traffico che ha bisogno di garanzie di latenza. Il VOIP è uno di questi, l'NTP un altro. Il resto dovrebbe essere fatto con la condivisione dei collegamenti. Se si vuole che il web sia veloce, lo si rende tale allocando la maggior parte della capacità dei collegamenti. Questa condivisione è garantita a lungo termine. Se si vuole che la latenza sia bassa (in media), si deve dare una curva convessa alla condivisione dei collegamenti.

Un tutorial dice che bisogna dimenticare tutta la teoria. Non importa come
come funzionano realmente le cose (scheduler e distribuzione della larghezza di banda), immaginare
le tre curve secondo il seguente "modello mentale semplificato":
real-time è la larghezza di banda garantita che questa classe otterrà sempre.
link-share è la larghezza di banda che questa classe vuole ottenere per essere pienamente
soddisfatta, ma la soddisfazione non può essere garantita. Nel caso in cui ci sia
banda in eccesso, alla classe potrebbe anche essere offerta una larghezza di banda maggiore di quella
necessaria per essere soddisfatta, ma non potrà mai utilizzare più di quanto
del limite superiore. Affinché tutto questo funzioni, la somma di tutte le larghezze di banda in tempo reale
in tempo reale non deve superare l'xx% della velocità della linea (vedere la domanda precedente,
la percentuale varia). Domanda: Si tratta di un'affermazione più o meno accurata o di un
totale incomprensione dell'HSFC?

Si tratta di un buon limite superiore di descrizione. La descrizione di link share è rigorosamente accurata, ma è fuorviante. Sebbene sia vero che link share non dia garanzie di latenza come il tempo reale, fa un lavoro migliore nel dare alla classe la sua larghezza di banda rispetto ai suoi concorrenti, come CBQ e HTB. Quindi, affermando che link share "non fornisce garanzie", lo si sottopone a uno standard superiore a quello che può fornire qualsiasi altro scheduler.

La descrizione di Real Time riesce a essere accurata, ma anche così fuorviante che la definirei sbagliata. Come suggerisce il nome, lo scopo del tempo reale non è quello di fornire una larghezza di banda garantita. È quello di fornire una latenza garantita, cioè il pacchetto viene inviato ORA, non un tempo casuale dopo, a seconda di come viene utilizzato il collegamento. La maggior parte del traffico non ha bisogno di una latenza garantita.

Detto questo, nemmeno il tempo reale fornisce una perfetta garanzia di latenza. Potrebbe, se il link non fosse gestito anche da link share, ma la maggior parte degli utenti vuole la flessibilità aggiuntiva di avere entrambe le cose e non è gratis. Il tempo reale può mancare la scadenza di latenza per il tempo necessario a inviare un pacchetto MTU. (Se ciò accade, sarà perché si trattava di un pacchetto MTU che il link share ha inserito di nascosto mentre il tempo reale manteneva il collegamento inattivo nel caso in cui fosse stato inviato un pacchetto con una scadenza breve che doveva essere inviato immediatamente. Questa è un'altra differenza tra link share e tempo reale. Per fornire le sue garanzie, il tempo reale può deliberatamente mantenere la linea inattiva anche se ci sono pacchetti da inviare, fornendo così un utilizzo dei collegamenti inferiore al 100%. Link share utilizza sempre il 100% della capacità disponibile del collegamento. A differenza del tempo reale, si può dire che "preserva il lavoro").

Il motivo per cui si può dire che il tempo reale offra garanzie di latenza è che il ritardo è limitato. Quindi, se si sta cercando di offrire una garanzia di latenza di 20 ms su un collegamento a 1 Mbit/sec, e la condivisione del collegamento sta inviando pacchetti di dimensioni MTU (1500 byte), si sa che uno di questi pacchetti impiegherà 12 ms per essere inviato. Pertanto, se si dice in tempo reale che si vuole una latenza di 8 ms, si può comunque rispettare la scadenza di 20 ms, con una garanzia assoluta.

E se l'ipotesi di cui sopra è davvero accurata, dov'è la prioritizzazione in questo modello?
questo modello? Ad esempio, ogni classe potrebbe avere una larghezza di banda in tempo reale (garantita).
(garantita), una larghezza di banda per la condivisione del collegamento (non garantita) e forse un
limite superiore, ma alcune classi hanno esigenze di priorità più elevate di altre.
altre classi. In questo caso devo comunque assegnare delle priorità in qualche modo, anche
tra il traffico in tempo reale di queste classi. Potrei assegnare le priorità in base alla
pendenza delle curve? E se sì, quale curva? La curva in tempo reale? La curva
curva di condivisione dei link? La curva del limite superiore? Tutte? Dovrei dare a tutte
tutte la stessa pendenza o a ciascuna di esse una diversa e come trovare la
giusta pendenza?

Non c'è un modello di priorità. Davvero. Se vuoi dare priorità assolute al traffico, usa il pfifo. È a questo che serve. Ma attenzione anche al fatto che se si dà al traffico web la priorità assoluta rispetto al traffico email, ciò significa lasciare che il traffico web saturi il link e quindi che non passino i pacchetti email, affatto. Tutte le connessioni e-mail muoiono.

In realtà nessuno vuole questo tipo di priorità. Quello che vogliono è ciò che fornisce HFSC. Se si ha effettivamente traffico in tempo reale, HFSC lo fornisce. Ma si tratta di roba di tutti. Per il resto, HFSC vi permette di dire "su un link congestionato, assegnate il 90% al web e lasciate che la posta elettronica arranchi al 10%, e oh, inviate rapidamente il pacchetto DNS, ma non lasciate che qualcuno mi mandi in DOS".

Soluzione 2:

Si possono definire le curve con nomi diversi:

  • rt, curva in tempo reale, garanzia di larghezza di banda/ritardo.
  • ls, curva di condivisione dei collegamenti, condivisione della larghezza di banda/del ritardo (basata sulla configurazione delle foglie dei vicini).
  • ul, curva del limite superiore, massima larghezza di banda/ritardo che può raggiungere.

A cosa serve una curva in tempo reale? Supponendo che A1, A2, B1, B2
siano tutti link-share a 128 kbit/s (nessuna curva in tempo reale per nessuno dei due),
ciascuno di essi riceverà 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é
Perché dovrei dare ad A1 e B1 una curva in tempo reale con 128 kbit/s?
A cosa servirebbe? Per dare a questi due una priorità maggiore?
Secondo il documento originale, posso dare loro una priorità più alta utilizzando una curva.
una curva, dopotutto è questo il senso dell'HFSC. Dando a entrambe le
classi una curva di [256kbit/s 20ms 128kbit/s] entrambe hanno il doppio della
di A2 e B2 automaticamente (ricevendo comunque solo 128 kbit/s in media).
in media)

Quando si effettua una definizione in HFSC solo con le tariffe, si imposta automaticamente 'dmax' a 0. Ciò significa fondamentalmente che non tiene conto del ritardo. Una buona configurazione di 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 è in grado di capire esattamente la priorità di una classe.

Ogni volta che si assegna una priorità ai pacchetti, gli altri pacchetti dovranno diminuire la loro priorità. In base ai valori 'dmax' e 'rate', tutte le classi verranno multiplexate utilizzando timer virtuali. Per ulteriori informazioni, consultare tc-hfsc(7).

La larghezza di banda in tempo reale conta per la larghezza di banda di condivisione del collegamento?
Ad esempio, se A1 e B1 hanno entrambi solo 64kbit/s di banda in tempo reale e 64kbit/s di banda di condivisione del collegamento, ciò significa che la larghezza di banda in tempo reale e la larghezza di banda di condivisione del collegamento
di banda in tempo reale e 64kbit/s di banda condivisa, significa che una volta serviti 64kbit/s in tempo reale, il loro requisito di condivisione del collegamento
in tempo reale, anche il loro requisito di condivisione del collegamento è soddisfatto (potrebbero ottenere una
potrebbero ottenere una larghezza di banda in eccesso, ma ignoriamo questo aspetto per un secondo) oppure significa che
significa che ricevono altri 64 kbit/s tramite link-share? Quindi ogni
classe ha un "requisito" di banda in tempo reale più link-share? Oppure
una classe ha un requisito più elevato della curva del tempo reale solo
se la curva di link-share è più alta di quella del tempo reale (il requisito attuale di link-share
richiesta di condivisione del collegamento è uguale alla richiesta di condivisione del collegamento specificata meno
la larghezza di banda in tempo reale già fornita a questa classe)?

Se il flusso non supera i confini della definizione di condivisione dei collegamenti 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 una certa "dmax".

Se le definizioni di link-share sono impeccabili, allora non si ha bisogno di curve in tempo reale. Si potrebbero semplicemente definire delle curve di servizio (sc), ma questo renderebbe più difficile la configurazione.

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

La curva del limite superiore della classe viene applicata solo alla condivisione dei collegamenti; quando si definisce una curva del limite superiore si DEVE definire una curva della condivisione dei collegamenti. Tuttavia, la curva di limite superiore delle classi genitore viene ancora applicata.

Supponendo che A2 e B2 siano entrambi a 128 kbit/s, fa qualche differenza se
A1 e B1 sono solo a 128 kbit/s o a 64 kbit/s in tempo reale e a 128 kbit/s in link-share.
128 kbit/s e, in caso affermativo, che differenza c'è?

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

Se utilizzo la curva in tempo reale separata per aumentare le priorità delle
classi, perché avrei bisogno di "curve"? Perché il tempo reale non è un valore
e anche link-share è un valore piatto? Perché sono entrambe curve? La necessità
di curve è chiara nel documento originale, perché c'è un solo
attributo di questo tipo per classe. Ma ora, avendo tre attributi
(tempo reale, condivisione dei link e limite superiore) perché ho ancora bisogno di
curve per ciascuno di essi? Perché dovrei volere che la forma delle curve (non la larghezza di banda media
ma le loro pendenze) siano diverse per il traffico in tempo reale e per quello in condivisione?
traffico in tempo reale e per quello in condivisione?

Le curve in tempo reale non condividono il traffico tra le foglie vicine, mentre le curve di condivisione dei collegamenti sì.

Secondo la poca documentazione disponibile, i valori delle curve in tempo reale
in tempo reale sono totalmente ignorati per le classi interne (classe A e B), vengono
solo per le classi interne (A1, A2, B1, B2), mentre vengono applicati solo alle classi esterne (A1, A2, B1, B2). Se questo è vero, perché
la configurazione di esempio di ALTQ HFSC (cercare 3.3 Configurazione di esempio)
configurazione) imposta curve in tempo reale sulle classi interne e sostiene che queste
che queste definiscono il tasso garantito di tali classi interne? Non è forse
completamente inutile? (nota: pshare imposta la curva di condivisione dei collegamenti in ALTQ
e grate la curva in tempo realee; lo si può vedere nel paragrafo sopra
la configurazione di esempio).

È vero che le curve in tempo reale sono ignorate per le classi interne, ma vengono applicate solo alle classi foglia. Tuttavia, le curve in tempo reale definite su queste 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 non può essere superiore all'80% della velocità della linea.
dell'80% della velocità della linea, altri dicono che non deve essere superiore al 70% della velocità della linea.
della velocità della linea. Quale dei due è giusto o forse sono entrambi sbagliati?

Quello che vogliono dire è: non si può dare priorità a tutto il traffico.Ogni volta che si dà priorità ai pacchetti, altri pacchetti dovranno essere diminuiti di priorità. Se si garantisce troppo, l'algoritmo diventa inutile. Definire le classi che ottengono la priorità e definire le classi che la subiscono.

Un tutorial dice che dovrete dimenticare tutta la teoria. Non importa come
come funzionano realmente le cose (scheduler e distribuzione della larghezza di banda), immaginare
le tre curve secondo il seguente "modello mentale semplificato":
real-time è la larghezza di banda garantita che questa classe otterrà sempre.
link-share è la larghezza di banda che questa classe vuole ottenere per essere pienamente
soddisfatta, ma la soddisfazione non può essere garantita. Nel caso in cui ci sia
banda in eccesso, alla classe potrebbe anche essere offerta una larghezza di banda maggiore di quella
necessaria per essere soddisfatta, ma non potrà mai utilizzare più di quanto
del limite superiore. Affinché tutto questo funzioni, la somma di tutte le larghezze di banda in tempo reale
in tempo reale non deve superare l'xx% della velocità della linea (si veda la domanda precedente,
la percentuale varia). Domanda: Si tratta di un'affermazione più o meno accurata o di un
totale incomprensione dell'HSFC?

È corretto.

E se l'ipotesi di cui sopra è davvero accurata, dov'è la prioritizzazione in quel modello?
questo modello? Per esempio, ogni classe potrebbe avere una banda in tempo reale
(garantita), una larghezza di banda in condivisione (non garantita) e forse un limite superiore.
limite superiore, ma alcune classi hanno esigenze di priorità più elevate di altre.
altre classi. In questo caso devo comunque assegnare delle priorità in qualche modo, anche
tra il traffico in tempo reale di queste classi. Potrei assegnare le priorità in base alla
pendenza delle curve? E se sì, quale curva? La curva in tempo reale? La curva
curva di condivisione dei link? La curva del limite superiore? Tutte? Dovrei dare a tutte
tutte la stessa pendenza o a ciascuna di esse una diversa e come trovare la
giusta pendenza?

La differenza tra HFSC e HTB è che HFSC consente di definire esattamente la quantità di priorità che si desidera. Ciò avviene definendo i limiti minimi e massimi con il valore 'dmax'.


Soluzione 3:

Finalmente una guida che sembra spiegare la maggior parte delle incongruenze e anche come l'implementazione attuale sia diversa dal documento originale:

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

Secondo questa guida, molte altre guide e post sui forum riguardanti l'HFSC sono del tutto privi di sensoe; questo dimostra quanto sia complicato l'HFSC, dato che molte persone che sembrano essere esperte e fingono di aver compreso appieno l'HFSC, in realtà ne hanno solo una conoscenza parziale e fanno affermazioni false basate su un'incomprensione del concetto e di come tutte le impostazioni giochino insieme.

Credo che alla fine rinuncerò all'HFSC. Se si riesce a configurare correttamente l'HFSC, può essere il miglior QoS che si possa ottenere, ma le probabilità di sbagliare completamente sono molto più alte di quelle di riuscire.

Se ritieni che questo post sia stato utile, ti saremmo grati se lo condividessi con altri sviluppatori in questo modo ci aiuterai a diffondere queste informazioni.



Utilizzate il nostro motore di ricerca

Ricerca
Generic filters

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.