Alguém realmente entende como funciona o agendamento HFSC no Linux/BSD?

Question 1

Ler os artigos sobre o HFSC e seus primos não é uma boa maneira de entendê-lo. O objetivo principal do artigo do HFSC é fornecer uma prova matemática rigorosa das suas afirmações, e não explicar como funciona. Na verdade, você não consegue entender como isso funciona apenas com o artigo do HFSC; você também precisa ler os artigos aos quais ele faz referência. Se você tiver algum problema com a reivindicação ou com suas provas, entrar em contato com os autores dos artigos pode ser uma boa ideia, caso contrário, duvido que eles estejam interessados em receber notícias suas.

Eu escrevi umtutorial para HFSC. Leia se minhas explicações abaixo não estiverem claras.

Para que preciso de uma curva em tempo real? Supondo que A1, A2, B1, B2 sejam todos link-share de 128 kbit/s (sem curva em tempo real para qualquer um), então cada um deles obterá 128 kbit/s se a raiz tiver 512 kbit/s para distribuir (e A e B são ambos de 256 kbit/s, claro), certo? Por que eu daria adicionalmente a A1 e B1 uma curva em tempo real com 128 kbit/s? Para que isso serviria? Para dar a esses dois uma prioridade mais alta? De acordo com o artigo original, posso dar a eles uma prioridade mais alta usando uma curva; afinal, é disso que se trata o HFSC. Ao dar a ambas as classes uma curva de [256kbit/s 20ms 128kbit/s], ambas têm o dobro da prioridade que A2 e B2 automaticamente (ainda obtendo apenas 128 kbit/s em média)

A curva em tempo real e a curva de compartilhamento de link são avaliadas de diferentes maneiras. A curva em tempo real leva em consideração o que uma turma fez ao longo de toda a sua história. Ele deve fazer isso para fornecer largura de banda precisa e alocação de latência. A desvantagem não é o que a maioria das pessoas intuitivamente considerajusto. Em tempo real, se uma classe emprestar largura de banda quando ninguém mais quiser, ela será penalizada quando alguém a quiser de volta mais tarde. Isso significa que sob a garantia de tempo real uma classe pode ficar sem largura de banda por um longo período porque a usou antes, quando ninguém a queria.

O compartilhamento do link é justo, pois não penaliza uma classe pelo uso de largura de banda sobressalente. No entanto, isso significa que não pode fornecer garantias fortes de latência.

A separação entre o compartilhamento de links e o fornecimento de garantias de latência é a novidade que o HFSC traz para a mesa, e o artigo diz isso em sua frase de abertura:Neste artigo, estudamos modelos e algoritmos hierárquicos de gerenciamento de recursos que suportam compartilhamento de links e serviços garantidos em tempo real com atraso (prioridade) desacoplado e alocação de largura de banda. A palavra-chave nessa frase é dissociado. Traduzido, significa que você deve dizer como a largura de banda não utilizada deve ser compartilhada com ls e especificar quais garantias em tempo real (também conhecidas como garantias de latência) são necessárias com rt. Os dois são ortogonais.

A largura de banda em tempo real conta para a largura de banda de compartilhamento de link?

Sim. No artigo do HFSC eles definem a largura de banda em termos do que a classe enviou desde que a classe ficou acumulada (ou seja, tem pacotes aguardando para serem enviados). A única diferença entre rt e ls é que rt aguarda cada vez que a classe ficou com backlog e calcula a menor largura de banda garantida desse conjunto, enquanto o compartilhamento de link apenas analisa a última vez que a classe ficou com backlog. Portanto, rt leva em consideração mais bytes do que ls, mas cada byte que ls considera também é considerado por rt.

A curva de limite superior também é aplicada ao tempo real, apenas ao compartilhamento de links, ou talvez a ambos?

O limite superior não impede que os pacotes sejam enviados para satisfazer a condição de tempo real. Os pacotes enviados sob a condição de tempo real ainda contam para o limite superior e, portanto, podem atrasar o envio de um pacote sob a condição de compartilhamento de link no futuro. Esta é outra diferença entre tempo real e compartilhamento de link.

Supondo que A2 e B2 sejam ambos de 128 kbit/s, faz alguma diferença se A1 e B1 forem apenas compartilhamento de link de 128 kbit/s, ou 64 kbit/s em tempo real e compartilhamento de link de 128 kbit/s, e se assim for , que diferença?

Sim, faz diferença. Conforme explicado acima, se você usar tempo real, as latências serão garantidas, mas o link não será compartilhado de maneira justa (e, em particular, a classe poderá sofrer escassez de largura de banda) e os limites superiores não serão aplicados. Se você usar o compartilhamento de link, a latência não será garantida, mas o compartilhamento de link será justo, não haverá risco de falta e o limite máximo será aplicado. O tempo real é sempre verificado antes do compartilhamento do link, porém isso não significa necessariamente que o compartilhamento do link será ignorado. Isso ocorre porque os pacotes são contados de forma diferente. Como o histórico é considerado em tempo real, um pacote pode não ser necessário para atender à garantia de tempo real (por causa de um pacote contado incluído no histórico), mas é necessário para satisfazer o compartilhamento do link porque ignora o pacote histórico.

Se eu usar a curva separada em tempo real para aumentar as prioridades das classes, por que precisaria de "curvas"? Por que o tempo real não é um valor fixo e o compartilhamento de link também é um valor fixo? Por que ambas as curvas são? A necessidade de curvas fica clara no artigo original, pois existe apenas um atributo desse tipo por classe. Mas agora, tendo três atributos (tempo real, link-share e limite superior), para que ainda preciso de curvas em cada um? Por que eu desejaria que o formato das curvas (não a largura de banda média, mas suas inclinações) fosse diferente para tráfego em tempo real e de compartilhamento de link?

A curva para controles em tempo real permite que você troque uma latência restrita para uma classe de tráfego específica (por exemplo, VOIP) por uma latência baixa para outras classes de tráfego (por exemplo, e-mail). Ao decidir qual pacote enviar sob a restrição de tempo real, o HFSC escolhe aquele que completará o envio primeiro. Porém, ele não utiliza a largura de banda do link para calcular isso, ele utiliza a largura de banda alocada pela curva em tempo real. Assim, se tivermos pacotes VOIP e de e-mail do mesmo comprimento, e o pacote VOIP tiver uma curva convexa que dá um aumento de 10 vezes sobre a curva côncava para e-mail, então 10 pacotes VOIP serão enviados antes do primeiro pacote de e-mail. Mas isso só acontece para o tempo de burst, que deve ser no máximo o tempo necessário para enviar alguns pacotes – ou seja, milissegundos. Depois disso, a curva VOIP deve se estabilizar e o VOIP não terá nenhum impulso futuro, a menos que recue por um tempo (o que, dado que o VOIP é um aplicativo de baixa largura de banda, deveria). O resultado líquido de tudo isso é garantir que os primeiros pacotes VOIP sejam enviados mais rápido do que qualquer outra coisa, proporcionando assim baixa latência ao VOIP em detrimento do e-mail obter alta latência.

Como eu disse anteriormente, como o compartilhamento de link não analisa o histórico, ele não pode fornecer garantias de latência. Uma garantia sólida é o que é necessário para tráfego em tempo real como VOIP. No entanto, em média, uma curva convexa compartilhada por link ainda proporcionará um aumento de latência ao seu tráfego. Simplesmente não é garantido. Isso é bom para a maioria das coisas, como tráfego da web por e-mail.

De acordo com a pouca documentação disponível, os valores das curvas em tempo real são totalmente ignorados para as classes internas (classes A e B), sendo aplicados apenas para as classes folhas (A1, A2, B1, B2). Se isso for verdade, por que a configuração de amostra ALTQ HFSC (pesquise 3.3 Configuração de amostra) define curvas em tempo real nas classes internas e afirma que elas definem a taxa garantida dessas classes internas? Isso não é completamente inútil? (nota: pshare define a curva link-share em ALTQ e ralar a curva em tempo real; você pode ver isso no parágrafo acima do exemplo de configuração).

A documentação está correta. A hierarquia (e, portanto, os nós internos) não tem qualquer efeito no cálculo do tempo real. Não sei dizer por que o ALTQ evidentemente pensa que sim.

Alguns tutoriais dizem que a soma de todas as curvas em tempo real não pode ser superior a 80% da velocidade da linha, outros dizem que não deve ser superior a 70% da velocidade da linha. Qual deles está certo ou talvez ambos estejam errados?

Ambos estão errados. Se 70% ou 80% do seu tráfego tiver requisitos rígidos de latência que devem ser especificados em tempo real, a realidade é que é quase certo que você não conseguirá satisfazê-los com o link que está usando. Você precisa de um link mais rápido.

A única maneira de alguém pensar que a especificação de 80% do tráfego deveria ser em tempo real seria se estivesse considerando o tempo real como um aumento de prioridade. Sim, para fornecer garantias de latência, você está, na verdade, aumentando a prioridade de alguns pacotes. Mas deve durar apenas milissegundos. Isso é tudo que um link pode suportar e ainda fornecer garantias de latência.

Há muito pouco tráfego que precisa de garantias de latência. VOIP é um, NTP outro. O resto deve ser feito com compartilhamento de links. Se você deseja que a web seja rápida, você a torna rápida alocando a maior parte da capacidade dos links. Essa parteégarantida a longo prazo. Se você quiser que tenha baixa latência (em média), forneça uma curva convexa no compartilhamento de link.

Um tutorial dizia que você esqueceria toda a teoria. Não importa como as coisas realmente funcionam (programadores e distribuição de largura de banda), imagine as três curvas de acordo com o seguinte "modelo mental simplificado": tempo real é a largura de banda garantida que esta classe sempre terá. link-share é a largura de banda que esta classe deseja que fique totalmente satisfeita, mas a satisfação não pode ser garantida. Caso haja excesso de largura de banda, a classe pode até receber mais largura de banda do que o necessário para ficar satisfeita, mas nunca pode usar mais do que o limite superior diz. Para que tudo isso funcione, a soma de todas as larguras de banda em tempo real não pode estar acima de xx% da velocidade da linha (veja a pergunta acima, a porcentagem varia). Pergunta: Isso é mais ou menos preciso ou é um mal-entendido total sobre o HSFC?

É uma boa descrição do limite superior. Embora a descrição do compartilhamento do link seja estritamente precisa, ela é enganosa. Embora seu verdadeiro compartilhamento de link não ofereça garantias de latência como o tempo real, ele faz um trabalho melhor em fornecer à classe sua largura de banda e alocação do que seus concorrentes, como CBQ e HTB. Portanto, ao dizer que o compartilhamento de link "não fornece garantias", ele está mantendo um padrão mais alto do que qualquer outro agendador pode fornecer.

A descrição em tempo real consegue ser precisa, mas tão enganosa que eu diria que está errada. Como o nome indica, o objetivo do tempo real não é fornecer largura de banda garantida. É para fornecer latência garantida - ou seja, o pacote é enviado AGORA, e não algum tempo aleatório depois, dependendo de como o link é usado. A maior parte do tráfego não precisa de latência garantida.

Dito isto, o tempo real também não oferece garantias de latência perfeita. Poderia, se o link também não fosse gerenciado pelo compartilhamento de link, mas a maioria dos usuários deseja a flexibilidade adicional de ter os dois e isso não é gratuito. O tempo real pode perder o prazo de latência pelo tempo necessário para enviar um pacote MTU. (Se isso acontecer, será porque foi um compartilhamento de link de pacote MTU que entrou furtivamente enquanto mantinha o link ocioso em tempo real, caso fosse fornecido um pacote com um prazo curto que deveria ser enviado imediatamente. Esta é mais uma diferença entre o compartilhamento de link e tempo real. Para fornecer suas garantias, o tempo real pode deliberadamente manter a linha ociosa, mesmo que haja pacotes para enviar, desde que menos de 100% de utilização do link. O compartilhamento de link sempre utiliza 100% da capacidade disponível dos links. , pode-se dizer que é "preservação do trabalho".)

A razão pela qual se pode dizer que o tempo real oferece garantias de latência rígida é que o atraso é limitado. Portanto, se você estiver tentando oferecer uma garantia de latência de 20 ms em um link de 1 Mbit/s e o compartilhamento do link estiver enviando pacotes de tamanho MTU (1.500 bytes), você sabe que um desses pacotes levará 12 ms para ser enviado. Assim, se você disser em tempo real que deseja uma latência de 8 ms, ainda poderá cumprir o prazo de 20 ms - com garantia absoluta.

E se a suposição acima for realmente precisa, onde está a priorização nesse modelo? Por exemplo, cada classe pode ter uma largura de banda em tempo real (garantida), uma largura de banda de compartilhamento de link (não garantida) e talvez um limite superior, mas ainda assim algumas classes têm necessidades de prioridade mais altas do que outras classes. Nesse caso ainda devo priorizar de alguma forma, mesmo entre o tráfego em tempo real dessas classes. Eu priorizaria pela inclinação das curvas? E se sim, qual curva? A curva em tempo real? A curva de compartilhamento de link? A curva do limite superior? Todos eles? Eu daria a todos eles a mesma inclinação ou a cada um diferente e como descobrir a inclinação correta?

Não existe um modelo de priorização. Seriamente. Se você quiser dar prioridades absolutas ao tráfego, use pfifo. É pra isso que isto serve. Mas também tome cuidado: se você der prioridade absoluta ao tráfego da web sobre o tráfego de e-mail, isso significa deixar o tráfego da web saturar o link e, portanto, nenhum pacote de e-mail passar,de forma alguma. Todas as suas conexões de e-mail morrem.

Na realidade, ninguém quer esse tipo de priorização. O que eles querem é o que o HFSC oferece. Se você realmente tiver tráfego em tempo real, o HFSC fornece isso. Mas será tudo. De resto, o HFSC permite que você diga "em um link congestionado, aloque 90% para a web e deixe o e-mail chegar a 10% e, ah, envie um pacote DNS estranho rapidamente, mas não deixe ninguém me dar um DOS com ele".

Answer

Ler os artigos sobre o HFSC e seus primos não é uma boa maneira de entendê-lo. O objetivo principal do artigo do HFSC é fornecer uma prova matemática rigorosa das suas afirmações, e não explicar como funciona. Na verdade, você não consegue entender como isso funciona apenas com o artigo do HFSC; você também precisa ler os artigos aos quais ele faz referência. Se você tiver algum problema com a reivindicação ou com suas provas, entrar em contato com os autores dos artigos pode ser uma boa ideia, caso contrário, duvido que eles estejam interessados em receber notícias suas.

Eu escrevi umtutorial para HFSC. Leia se minhas explicações abaixo não estiverem claras.

Para que preciso de uma curva em tempo real? Supondo que A1, A2, B1, B2 sejam todos link-share de 128 kbit/s (sem curva em tempo real para qualquer um), então cada um deles obterá 128 kbit/s se a raiz tiver 512 kbit/s para distribuir (e A e B são ambos de 256 kbit/s, claro), certo? Por que eu daria adicionalmente a A1 e B1 uma curva em tempo real com 128 kbit/s? Para que isso serviria? Para dar a esses dois uma prioridade mais alta? De acordo com o artigo original, posso dar a eles uma prioridade mais alta usando uma curva; afinal, é disso que se trata o HFSC. Ao dar a ambas as classes uma curva de [256kbit/s 20ms 128kbit/s], ambas têm o dobro da prioridade que A2 e B2 automaticamente (ainda obtendo apenas 128 kbit/s em média)

A curva em tempo real e a curva de compartilhamento de link são avaliadas de diferentes maneiras. A curva em tempo real leva em consideração o que uma turma fez ao longo de toda a sua história. Ele deve fazer isso para fornecer largura de banda precisa e alocação de latência. A desvantagem não é o que a maioria das pessoas intuitivamente considerajusto. Em tempo real, se uma classe emprestar largura de banda quando ninguém mais quiser, ela será penalizada quando alguém a quiser de volta mais tarde. Isso significa que sob a garantia de tempo real uma classe pode ficar sem largura de banda por um longo período porque a usou antes, quando ninguém a queria.

O compartilhamento do link é justo, pois não penaliza uma classe pelo uso de largura de banda sobressalente. No entanto, isso significa que não pode fornecer garantias fortes de latência.

A separação entre o compartilhamento de links e o fornecimento de garantias de latência é a novidade que o HFSC traz para a mesa, e o artigo diz isso em sua frase de abertura:Neste artigo, estudamos modelos e algoritmos hierárquicos de gerenciamento de recursos que suportam compartilhamento de links e serviços garantidos em tempo real com atraso (prioridade) desacoplado e alocação de largura de banda. A palavra-chave nessa frase é dissociado. Traduzido, significa que você deve dizer como a largura de banda não utilizada deve ser compartilhada com ls e especificar quais garantias em tempo real (também conhecidas como garantias de latência) são necessárias com rt. Os dois são ortogonais.

A largura de banda em tempo real conta para a largura de banda de compartilhamento de link?

Sim. No artigo do HFSC eles definem a largura de banda em termos do que a classe enviou desde que a classe ficou acumulada (ou seja, tem pacotes aguardando para serem enviados). A única diferença entre rt e ls é que rt aguarda cada vez que a classe ficou com backlog e calcula a menor largura de banda garantida desse conjunto, enquanto o compartilhamento de link apenas analisa a última vez que a classe ficou com backlog. Portanto, rt leva em consideração mais bytes do que ls, mas cada byte que ls considera também é considerado por rt.

A curva de limite superior também é aplicada ao tempo real, apenas ao compartilhamento de links, ou talvez a ambos?

O limite superior não impede que os pacotes sejam enviados para satisfazer a condição de tempo real. Os pacotes enviados sob a condição de tempo real ainda contam para o limite superior e, portanto, podem atrasar o envio de um pacote sob a condição de compartilhamento de link no futuro. Esta é outra diferença entre tempo real e compartilhamento de link.

Supondo que A2 e B2 sejam ambos de 128 kbit/s, faz alguma diferença se A1 e B1 forem apenas compartilhamento de link de 128 kbit/s, ou 64 kbit/s em tempo real e compartilhamento de link de 128 kbit/s, e se assim for , que diferença?

Sim, faz diferença. Conforme explicado acima, se você usar tempo real, as latências serão garantidas, mas o link não será compartilhado de maneira justa (e, em particular, a classe poderá sofrer escassez de largura de banda) e os limites superiores não serão aplicados. Se você usar o compartilhamento de link, a latência não será garantida, mas o compartilhamento de link será justo, não haverá risco de falta e o limite máximo será aplicado. O tempo real é sempre verificado antes do compartilhamento do link, porém isso não significa necessariamente que o compartilhamento do link será ignorado. Isso ocorre porque os pacotes são contados de forma diferente. Como o histórico é considerado em tempo real, um pacote pode não ser necessário para atender à garantia de tempo real (por causa de um pacote contado incluído no histórico), mas é necessário para satisfazer o compartilhamento do link porque ignora o pacote histórico.

Se eu usar a curva separada em tempo real para aumentar as prioridades das classes, por que precisaria de "curvas"? Por que o tempo real não é um valor fixo e o compartilhamento de link também é um valor fixo? Por que ambas as curvas são? A necessidade de curvas fica clara no artigo original, pois existe apenas um atributo desse tipo por classe. Mas agora, tendo três atributos (tempo real, link-share e limite superior), para que ainda preciso de curvas em cada um? Por que eu desejaria que o formato das curvas (não a largura de banda média, mas suas inclinações) fosse diferente para tráfego em tempo real e de compartilhamento de link?

A curva para controles em tempo real permite que você troque uma latência restrita para uma classe de tráfego específica (por exemplo, VOIP) por uma latência baixa para outras classes de tráfego (por exemplo, e-mail). Ao decidir qual pacote enviar sob a restrição de tempo real, o HFSC escolhe aquele que completará o envio primeiro. Porém, ele não utiliza a largura de banda do link para calcular isso, ele utiliza a largura de banda alocada pela curva em tempo real. Assim, se tivermos pacotes VOIP e de e-mail do mesmo comprimento, e o pacote VOIP tiver uma curva convexa que dá um aumento de 10 vezes sobre a curva côncava para e-mail, então 10 pacotes VOIP serão enviados antes do primeiro pacote de e-mail. Mas isso só acontece para o tempo de burst, que deve ser no máximo o tempo necessário para enviar alguns pacotes – ou seja, milissegundos. Depois disso, a curva VOIP deve se estabilizar e o VOIP não terá nenhum impulso futuro, a menos que recue por um tempo (o que, dado que o VOIP é um aplicativo de baixa largura de banda, deveria). O resultado líquido de tudo isso é garantir que os primeiros pacotes VOIP sejam enviados mais rápido do que qualquer outra coisa, proporcionando assim baixa latência ao VOIP em detrimento do e-mail obter alta latência.

Como eu disse anteriormente, como o compartilhamento de link não analisa o histórico, ele não pode fornecer garantias de latência. Uma garantia sólida é o que é necessário para tráfego em tempo real como VOIP. No entanto, em média, uma curva convexa compartilhada por link ainda proporcionará um aumento de latência ao seu tráfego. Simplesmente não é garantido. Isso é bom para a maioria das coisas, como tráfego da web por e-mail.

De acordo com a pouca documentação disponível, os valores das curvas em tempo real são totalmente ignorados para as classes internas (classes A e B), sendo aplicados apenas para as classes folhas (A1, A2, B1, B2). Se isso for verdade, por que a configuração de amostra ALTQ HFSC (pesquise 3.3 Configuração de amostra) define curvas em tempo real nas classes internas e afirma que elas definem a taxa garantida dessas classes internas? Isso não é completamente inútil? (nota: pshare define a curva link-share em ALTQ e ralar a curva em tempo real; você pode ver isso no parágrafo acima do exemplo de configuração).

A documentação está correta. A hierarquia (e, portanto, os nós internos) não tem qualquer efeito no cálculo do tempo real. Não sei dizer por que o ALTQ evidentemente pensa que sim.

Alguns tutoriais dizem que a soma de todas as curvas em tempo real não pode ser superior a 80% da velocidade da linha, outros dizem que não deve ser superior a 70% da velocidade da linha. Qual deles está certo ou talvez ambos estejam errados?

Ambos estão errados. Se 70% ou 80% do seu tráfego tiver requisitos rígidos de latência que devem ser especificados em tempo real, a realidade é que é quase certo que você não conseguirá satisfazê-los com o link que está usando. Você precisa de um link mais rápido.

A única maneira de alguém pensar que a especificação de 80% do tráfego deveria ser em tempo real seria se estivesse considerando o tempo real como um aumento de prioridade. Sim, para fornecer garantias de latência, você está, na verdade, aumentando a prioridade de alguns pacotes. Mas deve durar apenas milissegundos. Isso é tudo que um link pode suportar e ainda fornecer garantias de latência.

Há muito pouco tráfego que precisa de garantias de latência. VOIP é um, NTP outro. O resto deve ser feito com compartilhamento de links. Se você deseja que a web seja rápida, você a torna rápida alocando a maior parte da capacidade dos links. Essa parteégarantida a longo prazo. Se você quiser que tenha baixa latência (em média), forneça uma curva convexa no compartilhamento de link.

Um tutorial dizia que você esqueceria toda a teoria. Não importa como as coisas realmente funcionam (programadores e distribuição de largura de banda), imagine as três curvas de acordo com o seguinte "modelo mental simplificado": tempo real é a largura de banda garantida que esta classe sempre terá. link-share é a largura de banda que esta classe deseja que fique totalmente satisfeita, mas a satisfação não pode ser garantida. Caso haja excesso de largura de banda, a classe pode até receber mais largura de banda do que o necessário para ficar satisfeita, mas nunca pode usar mais do que o limite superior diz. Para que tudo isso funcione, a soma de todas as larguras de banda em tempo real não pode estar acima de xx% da velocidade da linha (veja a pergunta acima, a porcentagem varia). Pergunta: Isso é mais ou menos preciso ou é um mal-entendido total sobre o HSFC?

É uma boa descrição do limite superior. Embora a descrição do compartilhamento do link seja estritamente precisa, ela é enganosa. Embora seu verdadeiro compartilhamento de link não ofereça garantias de latência como o tempo real, ele faz um trabalho melhor em fornecer à classe sua largura de banda e alocação do que seus concorrentes, como CBQ e HTB. Portanto, ao dizer que o compartilhamento de link "não fornece garantias", ele está mantendo um padrão mais alto do que qualquer outro agendador pode fornecer.

A descrição em tempo real consegue ser precisa, mas tão enganosa que eu diria que está errada. Como o nome indica, o objetivo do tempo real não é fornecer largura de banda garantida. É para fornecer latência garantida - ou seja, o pacote é enviado AGORA, e não algum tempo aleatório depois, dependendo de como o link é usado. A maior parte do tráfego não precisa de latência garantida.

Dito isto, o tempo real também não oferece garantias de latência perfeita. Poderia, se o link também não fosse gerenciado pelo compartilhamento de link, mas a maioria dos usuários deseja a flexibilidade adicional de ter os dois e isso não é gratuito. O tempo real pode perder o prazo de latência pelo tempo necessário para enviar um pacote MTU. (Se isso acontecer, será porque foi um compartilhamento de link de pacote MTU que entrou furtivamente enquanto mantinha o link ocioso em tempo real, caso fosse fornecido um pacote com um prazo curto que deveria ser enviado imediatamente. Esta é mais uma diferença entre o compartilhamento de link e tempo real. Para fornecer suas garantias, o tempo real pode deliberadamente manter a linha ociosa, mesmo que haja pacotes para enviar, desde que menos de 100% de utilização do link. O compartilhamento de link sempre utiliza 100% da capacidade disponível dos links. , pode-se dizer que é "preservação do trabalho".)

A razão pela qual se pode dizer que o tempo real oferece garantias de latência rígida é que o atraso é limitado. Portanto, se você estiver tentando oferecer uma garantia de latência de 20 ms em um link de 1 Mbit/s e o compartilhamento do link estiver enviando pacotes de tamanho MTU (1.500 bytes), você sabe que um desses pacotes levará 12 ms para ser enviado. Assim, se você disser em tempo real que deseja uma latência de 8 ms, ainda poderá cumprir o prazo de 20 ms - com garantia absoluta.

E se a suposição acima for realmente precisa, onde está a priorização nesse modelo? Por exemplo, cada classe pode ter uma largura de banda em tempo real (garantida), uma largura de banda de compartilhamento de link (não garantida) e talvez um limite superior, mas ainda assim algumas classes têm necessidades de prioridade mais altas do que outras classes. Nesse caso ainda devo priorizar de alguma forma, mesmo entre o tráfego em tempo real dessas classes. Eu priorizaria pela inclinação das curvas? E se sim, qual curva? A curva em tempo real? A curva de compartilhamento de link? A curva do limite superior? Todos eles? Eu daria a todos eles a mesma inclinação ou a cada um diferente e como descobrir a inclinação correta?

Não existe um modelo de priorização. Seriamente. Se você quiser dar prioridades absolutas ao tráfego, use pfifo. É pra isso que isto serve. Mas também tome cuidado: se você der prioridade absoluta ao tráfego da web sobre o tráfego de e-mail, isso significa deixar o tráfego da web saturar o link e, portanto, nenhum pacote de e-mail passar,de forma alguma. Todas as suas conexões de e-mail morrem.

Na realidade, ninguém quer esse tipo de priorização. O que eles querem é o que o HFSC oferece. Se você realmente tiver tráfego em tempo real, o HFSC fornece isso. Mas será tudo. De resto, o HFSC permite que você diga "em um link congestionado, aloque 90% para a web e deixe o e-mail chegar a 10% e, ah, envie um pacote DNS estranho rapidamente, mas não deixe ninguém me dar um DOS com ele".

Question 2

Você poderia definir as curvas com nomes diferentes:

rt, curva em tempo real, garantia de largura de banda/atraso.
ls, curva de compartilhamento de link, compartilhamento de largura de banda/atraso (com base na configuração das folhas vizinhas)
ul, curva limite superior, largura de banda/atraso máximo que pode atingir.

Para que preciso de uma curva em tempo real? Supondo que A1, A2, B1, B2 sejam todos link-share de 128 kbit/s (sem curva em tempo real para qualquer um), então cada um deles obterá 128 kbit/s se a raiz tiver 512 kbit/s para distribuir (e A e B são ambos de 256 kbit/s, claro), certo? Por que eu daria adicionalmente a A1 e B1 uma curva em tempo real com 128 kbit/s? Para que isso serviria? Para dar a esses dois uma prioridade mais alta? De acordo com o artigo original, posso dar a eles uma prioridade mais alta usando uma curva; afinal, é disso que se trata o HFSC. Ao dar a ambas as classes uma curva de [256kbit/s 20ms 128kbit/s], ambas têm o dobro da prioridade que A2 e B2 automaticamente (ainda obtendo apenas 128 kbit/s em média)

Quando você faz uma definição no HFSC apenas com taxas, ele automaticamente define 'dmax' como 0. O que basicamente significa que não leva em conta o atraso. Uma boa configuração HFSC deve incluir largura de banda E limites de atraso que você deseja usar para sua classe, caso contrário, o algoritmo não conseguirá descobrir exatamente quanta prioridade uma classe deve obter.

Sempre que você der prioridade aos pacotes, a prioridade de outros pacotes terá que ser diminuída. Com base nos valores 'dmax' e 'rate' todas as classes serão multiplexadas usando temporizadores virtuais. Consulte tc-hfsc(7) para obter mais informações.

A largura de banda em tempo real conta para a largura de banda de compartilhamento de link? Por exemplo, se A1 e B1 têm apenas 64 kbit/s em tempo real e 64 kbit/s de largura de banda de compartilhamento de link, isso significa que, uma vez que eles recebem 64 kbit/s em tempo real, seu requisito de compartilhamento de link também é satisfeito (eles podem obter largura de banda em excesso, mas vamos ignorar isso por um segundo) ou isso significa que eles obtêm outros 64 kbit/s via link-share? Então, cada classe tem um "requisito" de largura de banda em tempo real mais compartilhamento de link? Ou uma classe só tem um requisito maior que a curva de tempo real se a curva de compartilhamento de link for maior que a curva de tempo real (o requisito atual de compartilhamento de link é igual ao requisito de compartilhamento de link especificado menos a largura de banda em tempo real já fornecida para esta classe). aula)?

Se o fluxo não ultrapassar os limites da definição de compartilhamento de link da classe, a curva em tempo real nunca será usada. Definir uma curva em tempo real neste caso permite, por exemplo: garantir um certo 'dmax'.

Se suas definições de compartilhamento de link forem perfeitas, você não precisará de curvas em tempo real. Você poderia apenas definir curvas de serviço (sc), mas isso tornaria sua configuração mais difícil.

A curva de limite superior também é aplicada ao tempo real, apenas ao compartilhamento de links, ou talvez a ambos? Alguns tutoriais dizem de uma maneira, outros dizem de outra maneira. Alguns até afirmam que o limite superior é o máximo para largura de banda em tempo real + largura de banda de compartilhamento de link? O que é a verdade?

A curva de limite superior da sua classe é aplicada apenas ao compartilhamento de link. Ao definir uma curva de limite superior, você DEVE definir uma curva de compartilhamento de link. No entanto, a curva de limite superior das classes pai ainda é aplicada.

Supondo que A2 e B2 sejam ambos de 128 kbit/s, faz alguma diferença se A1 e B1 forem apenas compartilhamento de link de 128 kbit/s, ou 64 kbit/s em tempo real e compartilhamento de link de 128 kbit/s, e se assim for , que diferença?

Há uma pequena diferença se, por exemplo, A2 = 0 kbits/s e B2 = 256 kbits/s. Então o tempo virtual para A2 estará no máximo. Sempre que os pacotes forem classificados em A2, eles serão processados instantaneamente. No entanto, a curva em tempo real de B2 ainda garantirá que seja capaz de transmitir pelo menos 64 kbit/s

Se eu usar a curva separada em tempo real para aumentar as prioridades das classes, por que precisaria de "curvas"? Por que o tempo real não é um valor fixo e o compartilhamento de link também é um valor fixo? Por que ambas as curvas são? A necessidade de curvas fica clara no artigo original, pois existe apenas um atributo desse tipo por classe. Mas agora, tendo três atributos (tempo real, link-share e limite superior), para que ainda preciso de curvas em cada um? Por que eu desejaria que o formato das curvas (não a largura de banda média, mas suas inclinações) fosse diferente para tráfego em tempo real e de compartilhamento de link?

As curvas em tempo real não compartilham o tráfego entre as folhas vizinhas, mas as curvas de compartilhamento de link.

De acordo com a pouca documentação disponível, os valores das curvas em tempo real são totalmente ignorados para as classes internas (classes A e B), sendo aplicados apenas para as classes folhas (A1, A2, B1, B2). Se isso for verdade, por que a configuração de amostra ALTQ HFSC (pesquise 3.3 Configuração de amostra) define curvas em tempo real nas classes internas e afirma que elas definem a taxa garantida dessas classes internas? Isso não é completamente inútil? (nota: pshare define a curva link-share em ALTQ e ralar a curva em tempo real; você pode ver isso no parágrafo acima do exemplo de configuração).

É verdade que as curvas em tempo real são ignoradas para classes internas, elas só são aplicadas a classes folhas. No entanto, as curvas em tempo real definidas nessas classes internas são levadas em consideração para cálculos nas classes folhas.

Alguns tutoriais dizem que a soma de todas as curvas em tempo real não pode ser superior a 80% da velocidade da linha, outros dizem que não deve ser superior a 70% da velocidade da linha. Qual deles está certo ou talvez ambos estejam errados?

O que eles querem dizer é: você não pode priorizar todo o tráfego... Sempre que você der prioridade aos pacotes, outros pacotes terão que ter prioridade diminuída. Se você garantir demais, o algoritmo se tornará inútil. Defina as classes que ganham priorização e defina as classes que podem sofrer.

Um tutorial dizia que você esqueceria toda a teoria. Não importa como as coisas realmente funcionam (programadores e distribuição de largura de banda), imagine as três curvas de acordo com o seguinte "modelo mental simplificado": tempo real é a largura de banda garantida que esta classe sempre terá. link-share é a largura de banda que esta classe deseja que fique totalmente satisfeita, mas a satisfação não pode ser garantida. Caso haja excesso de largura de banda, a classe pode até receber mais largura de banda do que o necessário para ficar satisfeita, mas nunca pode usar mais do que o limite superior diz. Para que tudo isso funcione, a soma de todas as larguras de banda em tempo real não pode estar acima de xx% da velocidade da linha (veja a pergunta acima, a porcentagem varia). Pergunta: Isso é mais ou menos preciso ou é um mal-entendido total sobre o HSFC?

Isto está certo.

E se a suposição acima for realmente precisa, onde está a priorização nesse modelo? Por exemplo, cada classe pode ter uma largura de banda em tempo real (garantida), uma largura de banda de compartilhamento de link (não garantida) e talvez um limite superior, mas ainda assim algumas classes têm necessidades de prioridade mais altas do que outras classes. Nesse caso ainda devo priorizar de alguma forma, mesmo entre o tráfego em tempo real dessas classes. Eu priorizaria pela inclinação das curvas? E se sim, qual curva? A curva em tempo real? A curva de compartilhamento de link? A curva do limite superior? Todos eles? Eu daria a todos eles a mesma inclinação ou a cada um diferente e como descobrir a inclinação correta?

A diferença entre, por exemplo, HFSC e HTB é que o HFSC permitirá que você defina exatamente quanta prioridade você deseja que ele tenha. Você faz isso definindo limites mínimo e máximo com o valor 'dmax'.

Answer

Você poderia definir as curvas com nomes diferentes:

rt, curva em tempo real, garantia de largura de banda/atraso.
ls, curva de compartilhamento de link, compartilhamento de largura de banda/atraso (com base na configuração das folhas vizinhas)
ul, curva limite superior, largura de banda/atraso máximo que pode atingir.

Para que preciso de uma curva em tempo real? Supondo que A1, A2, B1, B2 sejam todos link-share de 128 kbit/s (sem curva em tempo real para qualquer um), então cada um deles obterá 128 kbit/s se a raiz tiver 512 kbit/s para distribuir (e A e B são ambos de 256 kbit/s, claro), certo? Por que eu daria adicionalmente a A1 e B1 uma curva em tempo real com 128 kbit/s? Para que isso serviria? Para dar a esses dois uma prioridade mais alta? De acordo com o artigo original, posso dar a eles uma prioridade mais alta usando uma curva; afinal, é disso que se trata o HFSC. Ao dar a ambas as classes uma curva de [256kbit/s 20ms 128kbit/s], ambas têm o dobro da prioridade que A2 e B2 automaticamente (ainda obtendo apenas 128 kbit/s em média)

Quando você faz uma definição no HFSC apenas com taxas, ele automaticamente define 'dmax' como 0. O que basicamente significa que não leva em conta o atraso. Uma boa configuração HFSC deve incluir largura de banda E limites de atraso que você deseja usar para sua classe, caso contrário, o algoritmo não conseguirá descobrir exatamente quanta prioridade uma classe deve obter.

Sempre que você der prioridade aos pacotes, a prioridade de outros pacotes terá que ser diminuída. Com base nos valores 'dmax' e 'rate' todas as classes serão multiplexadas usando temporizadores virtuais. Consulte tc-hfsc(7) para obter mais informações.

A largura de banda em tempo real conta para a largura de banda de compartilhamento de link? Por exemplo, se A1 e B1 têm apenas 64 kbit/s em tempo real e 64 kbit/s de largura de banda de compartilhamento de link, isso significa que, uma vez que eles recebem 64 kbit/s em tempo real, seu requisito de compartilhamento de link também é satisfeito (eles podem obter largura de banda em excesso, mas vamos ignorar isso por um segundo) ou isso significa que eles obtêm outros 64 kbit/s via link-share? Então, cada classe tem um "requisito" de largura de banda em tempo real mais compartilhamento de link? Ou uma classe só tem um requisito maior que a curva de tempo real se a curva de compartilhamento de link for maior que a curva de tempo real (o requisito atual de compartilhamento de link é igual ao requisito de compartilhamento de link especificado menos a largura de banda em tempo real já fornecida para esta classe). aula)?

Se o fluxo não ultrapassar os limites da definição de compartilhamento de link da classe, a curva em tempo real nunca será usada. Definir uma curva em tempo real neste caso permite, por exemplo: garantir um certo 'dmax'.

Se suas definições de compartilhamento de link forem perfeitas, você não precisará de curvas em tempo real. Você poderia apenas definir curvas de serviço (sc), mas isso tornaria sua configuração mais difícil.

A curva de limite superior também é aplicada ao tempo real, apenas ao compartilhamento de links, ou talvez a ambos? Alguns tutoriais dizem de uma maneira, outros dizem de outra maneira. Alguns até afirmam que o limite superior é o máximo para largura de banda em tempo real + largura de banda de compartilhamento de link? O que é a verdade?

A curva de limite superior da sua classe é aplicada apenas ao compartilhamento de link. Ao definir uma curva de limite superior, você DEVE definir uma curva de compartilhamento de link. No entanto, a curva de limite superior das classes pai ainda é aplicada.

Supondo que A2 e B2 sejam ambos de 128 kbit/s, faz alguma diferença se A1 e B1 forem apenas compartilhamento de link de 128 kbit/s, ou 64 kbit/s em tempo real e compartilhamento de link de 128 kbit/s, e se assim for , que diferença?

Há uma pequena diferença se, por exemplo, A2 = 0 kbits/s e B2 = 256 kbits/s. Então o tempo virtual para A2 estará no máximo. Sempre que os pacotes forem classificados em A2, eles serão processados instantaneamente. No entanto, a curva em tempo real de B2 ainda garantirá que seja capaz de transmitir pelo menos 64 kbit/s

Se eu usar a curva separada em tempo real para aumentar as prioridades das classes, por que precisaria de "curvas"? Por que o tempo real não é um valor fixo e o compartilhamento de link também é um valor fixo? Por que ambas as curvas são? A necessidade de curvas fica clara no artigo original, pois existe apenas um atributo desse tipo por classe. Mas agora, tendo três atributos (tempo real, link-share e limite superior), para que ainda preciso de curvas em cada um? Por que eu desejaria que o formato das curvas (não a largura de banda média, mas suas inclinações) fosse diferente para tráfego em tempo real e de compartilhamento de link?

As curvas em tempo real não compartilham o tráfego entre as folhas vizinhas, mas as curvas de compartilhamento de link.

De acordo com a pouca documentação disponível, os valores das curvas em tempo real são totalmente ignorados para as classes internas (classes A e B), sendo aplicados apenas para as classes folhas (A1, A2, B1, B2). Se isso for verdade, por que a configuração de amostra ALTQ HFSC (pesquise 3.3 Configuração de amostra) define curvas em tempo real nas classes internas e afirma que elas definem a taxa garantida dessas classes internas? Isso não é completamente inútil? (nota: pshare define a curva link-share em ALTQ e ralar a curva em tempo real; você pode ver isso no parágrafo acima do exemplo de configuração).

É verdade que as curvas em tempo real são ignoradas para classes internas, elas só são aplicadas a classes folhas. No entanto, as curvas em tempo real definidas nessas classes internas são levadas em consideração para cálculos nas classes folhas.

Alguns tutoriais dizem que a soma de todas as curvas em tempo real não pode ser superior a 80% da velocidade da linha, outros dizem que não deve ser superior a 70% da velocidade da linha. Qual deles está certo ou talvez ambos estejam errados?

O que eles querem dizer é: você não pode priorizar todo o tráfego... Sempre que você der prioridade aos pacotes, outros pacotes terão que ter prioridade diminuída. Se você garantir demais, o algoritmo se tornará inútil. Defina as classes que ganham priorização e defina as classes que podem sofrer.

Um tutorial dizia que você esqueceria toda a teoria. Não importa como as coisas realmente funcionam (programadores e distribuição de largura de banda), imagine as três curvas de acordo com o seguinte "modelo mental simplificado": tempo real é a largura de banda garantida que esta classe sempre terá. link-share é a largura de banda que esta classe deseja que fique totalmente satisfeita, mas a satisfação não pode ser garantida. Caso haja excesso de largura de banda, a classe pode até receber mais largura de banda do que o necessário para ficar satisfeita, mas nunca pode usar mais do que o limite superior diz. Para que tudo isso funcione, a soma de todas as larguras de banda em tempo real não pode estar acima de xx% da velocidade da linha (veja a pergunta acima, a porcentagem varia). Pergunta: Isso é mais ou menos preciso ou é um mal-entendido total sobre o HSFC?

Isto está certo.

E se a suposição acima for realmente precisa, onde está a priorização nesse modelo? Por exemplo, cada classe pode ter uma largura de banda em tempo real (garantida), uma largura de banda de compartilhamento de link (não garantida) e talvez um limite superior, mas ainda assim algumas classes têm necessidades de prioridade mais altas do que outras classes. Nesse caso ainda devo priorizar de alguma forma, mesmo entre o tráfego em tempo real dessas classes. Eu priorizaria pela inclinação das curvas? E se sim, qual curva? A curva em tempo real? A curva de compartilhamento de link? A curva do limite superior? Todos eles? Eu daria a todos eles a mesma inclinação ou a cada um diferente e como descobrir a inclinação correta?

A diferença entre, por exemplo, HFSC e HTB é que o HFSC permitirá que você defina exatamente quanta prioridade você deseja que ele tenha. Você faz isso definindo limites mínimo e máximo com o valor 'dmax'.

Question 3

Finalmente, um guia que parece explicar a maioria das inconsistências e também como a implementação atual é diferente do artigo original:

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

De acordo com este guia, muitos outros guias e postagens em fóruns sobre HFSC são totalmente absurdos; isso apenas mostra o quão complicado é o HFSC, já que muitas pessoas que parecem ser especialistas e fingem ter compreendido completamente o HFSC, na verdade têm apenas conhecimento parcial e fazem declarações falsas com base na má compreensão do conceito e de como todas essas configurações funcionam juntas.

Acho que finalmente desistirei do HFSC. Se você conseguir configurar o HFSC corretamente, pode ser a melhor QoS possível, mas as chances de você errar completamente são muito maiores do que as chances de sucesso.

Answer

Finalmente, um guia que parece explicar a maioria das inconsistências e também como a implementação atual é diferente do artigo original:

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

De acordo com este guia, muitos outros guias e postagens em fóruns sobre HFSC são totalmente absurdos; isso apenas mostra o quão complicado é o HFSC, já que muitas pessoas que parecem ser especialistas e fingem ter compreendido completamente o HFSC, na verdade têm apenas conhecimento parcial e fazem declarações falsas com base na má compreensão do conceito e de como todas essas configurações funcionam juntas.

Acho que finalmente desistirei do HFSC. Se você conseguir configurar o HFSC corretamente, pode ser a melhor QoS possível, mas as chances de você errar completamente são muito maiores do que as chances de sucesso.

Question 4

Se você não conseguir entrar em contato com os autores originais, eu tentaria o seguinte:

entre na árvore de origem do kernel Linux e encontre os arquivos C que implementam a "estrutura de agendamento TC"
Veja o cabeçalho e encontre o autor do código.
Enviar e-mail aos programadores da "estrutura de agendamento de TC" solicitando literatura sobre sua implementação.

Tente também verificar outros artigos mais recentes que citam este. Pode haver artigos mais recentes que sejam uma continuação da pesquisa nesta área e podem incluir mais informações sobre as perguntas que você está fazendo.

Answer

Se você não conseguir entrar em contato com os autores originais, eu tentaria o seguinte:

entre na árvore de origem do kernel Linux e encontre os arquivos C que implementam a "estrutura de agendamento TC"
Veja o cabeçalho e encontre o autor do código.
Enviar e-mail aos programadores da "estrutura de agendamento de TC" solicitando literatura sobre sua implementação.

Tente também verificar outros artigos mais recentes que citam este. Pode haver artigos mais recentes que sejam uma continuação da pesquisa nesta área e podem incluir mais informações sobre as perguntas que você está fazendo.

Alguém realmente entende como funciona o agendamento HFSC no Linux/BSD?

Responder1

Responder2

Responder3

Responder4

informação relacionada