[GTER] Overhead Link Dedicado

Wed Jan 30 10:53:37 -02 2019

Só uma correção na minha conta: o preâmbulo + inter-frame gap somam 20
bytes, não 84, como eu disse (o 84 vem de outra conta, deixa pra lá).

1500 bytes de IP + 18 bytes de layer 2 (dst/src mac, eth-type, FCS) + 20
bytes (preâmbulo + FSD + gap) = 1538 bytes efetivos por frame

10.000.000.000 bits (velocidade da porta) / 1.538*8 (tamanho do frame em
bits) = aproximadamente 812.744 frames por segundo

Agora multiplica 812.744 pelo que você quiser (em bits) pra saber o valor
real trafegado.

812.744 * 1.500 * 8 = 9.752.928.000 = aproximadamente 9.75Gb de tráfego
contabilizado na sua interface, encapsulando TCP/IP

812.744 * 1460 * 8 = 9.492.849.920 = aproximadamente 9.49Gb de payload útil
(dado puro, sem nenhum encapsulamento)

Se você descontar os 20 bytes de preâmbulo + FSD + gap, a conta vira
10.000.000.000 / 1518*8 = 823.452 frames/s

823.452 * 1500 * 8 = 9.88Gb de tráfego, o que é consistente com o que o
Tiago SR disse sobre o overhead TCP/IP ser de aproximadamente 1.3%.

Em qua, 30 de jan de 2019 às 10:06, Rômulo Silva <
romulo.silva at gerenciatec.com.br> escreveu:

> Duas coisas que eu diria aqui...
>
> Primeiro: eu costumo botar a banda do meu cliente ligeiramente acima do
> que ele contrata justamente pra evitar esse problema de banda contratada
> que não bate por causa de overhead, mas faço isso pra evitar dor de cabeça,
> porque o meu cliente não tem obrigação de conhecer a tecnologia pra
> entender isso. Nós, por outro lado, somos os provedores e os técnicos,
> então conhecemos a tecnologia e sabemos que overhead existe e é inevitável.
> Não vejo sentido em reclamar sobre isso, a não ser que tenhamos planos de
> redesenhar todo o protocolo TCP/IP e Ethernet.
>
> Segundo: uma porta de 10Gb nunca vai bater 10Gb por limitação da
> interface. Ela vai bater 9.76Gb teóricos (consuderando aproveitamento
> máximo de 1518 bytes), porque você precisa descontar não só os overheads
> que vocês conhecem, mas também o preâmbulo e o espaçamento entre frames (só
> essa brincadeira consome 84 bytes por frame). Ou seja: você provavelmente
> está mesmo com uma porta de 10Gb, não um link de 10Gb.
>
> Você tá batendo 9.6Gb porque além disso tudo, deve ter algum overhead de
> VLAN, adicionando mais 4 bytes na brincadeira.
>
> Se quiser bater 10Gb de fato, vai ter que agregar duas de 10Gb ou botar
> uma de 40Gb. Com isso, o seu provedor de upstream vai ter que fazer queue
> na mão (em vez de deixar a velocidade da porta como "controle de banda"), e
> você vai bater os 10Gb, porque a queue não contabiliza o inter-frame nem o
> preâmbulo.
>
>
> Em ter, 29 de jan de 2019 às 23:53, Tiago SR <listas at tiagosr.com>
> escreveu:
>
>> Posso estar falando besteira, mas vocês estão considerando overhead de
>> qual(is) camada(s)/protocolo(s)? O fato de ser um link IP, e não algum
>> serviço Ethernet, não deveria descartar overhead de cabeçalhos camada 2 no
>> controle de banda?
>>
>> Para ter 4% de overhead (400Mbps em um total de 10.000Mbps) descontado da
>> banda, não deve ser só overhead do protocolo IP, que é só 1,3% de um MTU de
>> 1500B.
>>
>> No meu ver, ele deveria estar recebendo 10Gbps de banda IP, fora o
>> overhead Ethernet. Se a porta 10GbE não entrega isso por causa do overhead
>> Ethernet, tem que trocar por uma porta com mais capacidade. Porta 10GbE não
>> entrega 10Gbps de banda IP.
>>
>> E mais: o fornecedor vender 10Gbps IP e ver a porta consumindo mais que
>> isso por causa do overhead Ethernet não é problema nem pra ele, já que
>> Ethernet fica dentro da rede, não sai para os upstreams IP dele. Considerar
>> que 9.6Gbps é normal para quem contrata 10Gbps IP é aceitar o cara pagar
>> por 270Mbps (os outros 130Mbps desses 400Mbps são overhead IP) que nem é
>> banda IP.
>>
>>
>>
>> ---- On Tue, 29 Jan 2019 18:29:35 -0200 fhfrediani at gmail.com wrote ----
>>
>> On 29/01/2019 18:03, Bruno Souto wrote:
>> > e a grande questão, se eu contratar 9.5Gbps ela me entraga sem
>> contabilizar
>> > o overhead,
>> > agora se contrato 10Gbps o overhead entra na conta.
>>
>> Como é possível certificar-se dessa informação que em um caso é sem
>> overhead e na outra é com ? Como isso foi medido ? Essa informação esta
>> no mínimo estranha ou carece de verificação.
>>
>> Na prática é impossível não haver o overhead para haver Internet então
>> ele faz parte de todos os cenários além de ter que ser igualmente
>> transportado igualmente ao payload por qualquer fornecedor.
>> E no caso dos uplinks que suportam Jumbo Frame e portanto diferentes e
>> uma maior variedade de tamanhos de MTU passando como fazer para
>> descontar o overhead. Não faz sentido.
>>
>> Fernando
>>
>> >
>> >
>> >
>> >
>> > Em ter, 29 de jan de 2019 às 17:28, Guilherme de Freitas Figueiredo <
>> > guilhermefreitasfigueiredo at gmail.com> escreveu:
>> >
>> >> Acho que a questão não é essa. Seu cliente dedicado ele compra 10Mbps
>> com
>> >> ou sem overhead? É nessa questão que acho que o Bruno está querendo
>> entrar.
>> >> Se seu cliente te questionar que a banda dele está dando somente
>> 9.8Mbps e
>> >> não os 10Mbps conforme contratado, vamos ter que explicar pra ele que
>> esses
>> >> 0.2Mbps são de overhead? Isso levando em conta um link de 10Mbps.
>> >>
>> >> Hoje nós vendemos links dedicados, banda larga, sem levar em conta o
>> >> overhead que temos. Eu penso que sim, se eu vendo 10Mbps,20,50 ou
>> 200Mbps
>> >> para o meu cliente o calculo é feito sem overhead e se eu compro isso
>> da
>> >> operadora também deveria ser, ja discuti isso com alguns colegas que
>> hoje é
>> >> melhor você comprar 9.5Gbps ou 11Gbps do que 10Gbps conforme o Rodrigo
>> >> informou na ultima mensagem.
>> >>
>> >> Abraços!
>> >>
>> >> []s!
>> >>
>> >> --
>> >> Guilherme de Freitas Figueiredo
>> >>
>> >>
>> >> On Tue, Jan 29, 2019 at 4:30 PM Rodrigo Pedrosa <
>> rodrigopa.uepb at gmail.com>
>> >> wrote:
>> >>
>> >>> Desculpe a intromissão, mas o intuito é contribuir com o colega. O
>> link
>> >>> está saturado? Caso esteja, poderia fazer um pequeno upgrade que
>> >> resolveria
>> >>> essa questão (teria que ver a viabilidade e prazo antes também com a
>> >>> operadora), não poderão entregar na porta de 10G, devem agregar outra
>> >> porta
>> >>> ou subir numa de 40G.
>> >>> Caso esteja com sobra é mais complicado, tem que ver a questão
>> >> contratual,
>> >>> inclusive se o contrato permite downgrade, mas pode tentar negociar.
>> >>> Um detalhe a ser lembrado é que caso seja feito um upgrade, será
>> feito um
>> >>> aditivo no contrato ou gerado um novo contrato, e precisa verificar a
>> >>> questão de fidelidade contratual, que normalmente é renovado o prazo.
>> >>> Atenciosamente, Rodrigo Pedrosa de Aguiar
>> >>>
>> >>> Em ter, 29 de jan de 2019 às 14:32, Fernando Frediani <
>> >>> fhfrediani at gmail.com>
>> >>> escreveu:
>> >>>
>> >>>> Mas eles não estão entregando os 10Gb ? Na minha visão estão. Ou a
>> >>>> expectativa é que seria entregue sem o overhead que faz parte da
>> >>>> tecnologia. Eu particularmente nunca vi isso.
>> >>>>
>> >>>> Além disso quem gera boa parte desse overhead é você mesmo ou seus
>> >>>> clientes então se for pegar nisso a operadora poderia hipoteticamente
>> >>>> dizer que você esta fazendo isso de maneira ineficiente utilizando
>> MTU
>> >>>> 1500. E ai ?
>> >>>>
>> >>>> Fernando
>> >>>>
>> >>>> On 29/01/2019 11:14, Bruno Souto wrote:
>> >>>>> Mário exatamente nesse ponto queria chegar.
>> >>>>> Eu comprei um link de 10Gbps e não uma porta de 10GE
>> >>>>>
>> >>>>> se fosse a porta de 10GE não tinha o que discutir, pois estaria
>> >>> correto.
>> >>>>> agora eu comprei foi um Link IP Dedicado de 10Gbps, e na fatura está
>> >>>> sendo
>> >>>>> cobrado 1000M
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> Em ter, 29 de jan de 2019 às 05:51, Mário Sapucaia Neto <
>> >>>>> mariosapucaia at gmail.com> escreveu:
>> >>>>>
>> >>>>>> Bom dia!
>> >>>>>>
>> >>>>>> Mas as semi-carriers, como falava nosso amigo Bogus, vendiam
>> sempre,
>> >>>> Fast
>> >>>>>> 90M, Gig 900M, então seguindo a matemática... Isso foi motivo de
>> >>>>>> controvérsia em 2011... O Bruno comprou uma porta 10Gbe ou um Link
>> >> 10
>> >>>>>> GIGA????
>> >>>>>>
>> >>>>>> Em seg, 28 de jan de 2019 às 17:02, Fernando Frediani <
>> >>>>>> fhfrediani at gmail.com>
>> >>>>>> escreveu:
>> >>>>>>
>> >>>>>>> Acredito que o mais importante no momento diante de um cenário
>> >> aonde
>> >>> a
>> >>>>>>> maioria dos Links Dedicados (em alguns casos até mesmo em portas
>> de
>> >>>>>>> 10Gb) ainda não são ativados com suporte à Jumbo Frame, seria se
>> >>>>>>> concentrar nisso como também em garantir que os backbones possuam
>> >>>>>>> suporte completo.
>> >>>>>>>
>> >>>>>>> Feito isso já será possível utilizar de imediato Jumbo Frame para
>> >> uso
>> >>>> em
>> >>>>>>> aplicações específicas o que seria uma vantagem e estímulo para
>> >>>> cenários
>> >>>>>>> que hoje sequer são considerados para então passar para a
>> discussão
>> >>>>>>> sobre a análise e o avanço desse suporte até o usuário final atrás
>> >> de
>> >>>>>> CPE.
>> >>>>>>> Abraços
>> >>>>>>> Fernando Frediani
>> >>>>>>>
>> >>>>>>> On 28/01/2019 08:12, T. Ayub wrote:
>> >>>>>>>> Olá Frediani,
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> Esse é o mesmo raciocínio que muita gente usa para não adotar
>> >> IPv6,
>> >>> o
>> >>>>>>> que é
>> >>>>>>>> prejudicial em ambos os casos.
>> >>>>>>>>
>> >>>>>>>> "Ah, foi sempre assim não vale a pena mudar."
>> >>>>>>>>
>> >>>>>>>> Vale a pena sim senhor.
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> Abraços,
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> Ayub
>> >>>>>>>>
>> >>>>>>>> Em dom, 27 de jan de 2019 13:09, Fernando Frediani <
>> >>>>>> fhfrediani at gmail.com
>> >>>>>>>> escreveu:
>> >>>>>>>>
>> >>>>>>>>> Pois é, são tantos "ses" que na prática não adianta muito e não
>> >>>> haverá
>> >>>>>>>>> nenhum ganho significativo se o tráfego for majoritariamente de
>> >>>>>>> clientes de
>> >>>>>>>>> banda larga portsbto a perda devido ao overhead faz parte desse
>> >>> tipo
>> >>>>>> de
>> >>>>>>>>> cenário.
>> >>>>>>>>>
>> >>>>>>>>> Fernando
>> >>>>>>>>>
>> >>>>>>>>> On Sun, 27 Jan 2019, 12:49 Douglas Fischer <
>> >>> fischerdouglas at gmail.com
>> >>>>>>>>> wrote:
>> >>>>>>>>>
>> >>>>>>>>>> @Fernando
>> >>>>>>>>>> Informação parcialmente inverdadeira!
>> >>>>>>>>>>
>> >>>>>>>>>> Se:
>> >>>>>>>>>> a- Todo o caminho da rede, incluindo CPEs dos seus clientes e a
>> >>> Lan
>> >>>>>>>>> deles,
>> >>>>>>>>>> incluindo o caminho até os servidores de conteúdo, tiverem
>> >> suporte
>> >>>>>>>>> correto
>> >>>>>>>>>> ao Jumbo-Frame L2 e L3.
>> >>>>>>>>>> b- Os usuários utilizarem sistemas operacionais razoavelmente
>> >>>>>> recentes
>> >>>>>>>>> (To
>> >>>>>>>>>> falando de Android 5 para cá, e Windows 8 para cá.)
>> >>>>>>>>>> c- Não tiver um "Faireuól" configurado por leitor de
>> >>>>>>>>>> viva-o-linux(praticante de obscuridade) no meio do caminho, e
>> os
>> >>>>>>> pacotes
>> >>>>>>>>>> ICMP conseguirem ir e voltar corretamente do Client para o
>> >> Server.
>> >>>>>>>>>> c.1- Não tô falando só de ping! To falando de Path MTU
>> >>>> Discovery
>> >>>>>>>>>> Mesmo que o MTU Default dos sistemas operacionais seja 1500,
>> >> eles
>> >>>> vão
>> >>>>>>>>>> conseguir negociar um MTU mais alto, e o JumboFrame (ou Baby
>> >>> Jumbo)
>> >>>>>> vai
>> >>>>>>>>>> funcionar.
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> P.S.: @Bruno, peço desculpas por me apossar da thread.
>> >>>>>>>>>>
>> >>>>>>>>>> Em qua, 23 de jan de 2019 às 14:02, Fernando Frediani <
>> >>>>>>>>>> fhfrediani at gmail.com>
>> >>>>>>>>>> escreveu:
>> >>>>>>>>>>
>> >>>>>>>>>>> Se está vatendo ~9600 Mbps então ela está entregando os 10Gb
>> >>>>>>> justamente
>> >>>>>>>>>>> pelo motivo que você colocou no Subject da mensagem, o
>> >> Overhead.
>> >>>>>>>>>>> Com MTU a 1500 é dificil ter algo além disso.
>> >>>>>>>>>>>
>> >>>>>>>>>>> Usando Jumbo Frame sobretudo se o MTU for 9000 ou próximo
>> disso
>> >>>>>> seria
>> >>>>>>>>>>> possível atingir uma velocidade mais próxima do limite da
>> porta
>> >>> mas
>> >>>>>> o
>> >>>>>>>>>> ponto
>> >>>>>>>>>>> é que mesmo que suas portas de uplink e seu backbone
>> >> suportassem
>> >>>>>> Jumbo
>> >>>>>>>>>>> Frame os usuários continuam com MTU em 1500 então não iria
>> >> fazer
>> >>>>>>>>>> diferença
>> >>>>>>>>>>> significativa.
>> >>>>>>>>>>>
>> >>>>>>>>>>> On Wed, 23 Jan 2019, 13:15 Bruno Souto <
>> soutobruno31 at gmail.com
>> >>>>>> wrote:
>> >>>>>>>>>>>> Bom dia Senhores,
>> >>>>>>>>>>>> estou com uma dúvida, gostaria da opinião de vocês.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Contrato um Link de 10Gbps, a operadora me entrega em uma
>> >> única
>> >>>>>>>>>> interface
>> >>>>>>>>>>>> SFP+
>> >>>>>>>>>>>> Então percebo que o link chega no máximo 9600 Mbps.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Porem no Contrato pago 10.000 Mbps.
>> >>>>>>>>>>>> Parece pouco, mas dá para comprar um carro de 50 mil por ano!
>> >>>> rsrs
>> >>>>>>>>>>>> então pergunto aos senhores, não deveria entregar os 10.000
>> >>> Mbps ?
>> >>>>>>>>>>>> A operadora informa que está entregando os 10Gbps
>> >>>>>>>>>>>> --
>> >>>>>>>>>>>> gter list https://eng.registro.br/mailman/listinfo/gter
>> >>>>>>>>>>>>
>> >>>>>>>>>>> --
>> >>>>>>>>>>> gter list https://eng.registro.br/mailman/listinfo/gter
>> >>>>>>>>>>>
>> >>>>>>>>>> --
>> >>>>>>>>>> Douglas Fernando Fischer
>> >>>>>>>>>> Engº de Controle e Automação
>> >>>>>>>>>> --
>> >>>>>>>>>> gter list https://eng.registro.br/mailman/listinfo/gter
>> >>>>>>>>>>
>> >>>>>>>>> --
>> >>>>>>>>> gter list https://eng.registro.br/mailman/listinfo/gter
>> >>>>>>>>>
>> >>>>>>>> --
>> >>>>>>>> gter list https://eng.registro.br/mailman/listinfo/gter
>> >>>>>>> --
>> >>>>>>> gter list https://eng.registro.br/mailman/listinfo/gter
>> >>>>>>>
>> >>>>>> --
>> >>>>>> gter list https://eng.registro.br/mailman/listinfo/gter
>> >>>>>>
>> >>>>> --
>> >>>>> gter list https://eng.registro.br/mailman/listinfo/gter
>> >>>> --
>> >>>> gter list https://eng.registro.br/mailman/listinfo/gter
>> >>>>
>> >>> --
>> >>> gter list https://eng.registro.br/mailman/listinfo/gter
>> >>>
>> >> --
>> >> gter list https://eng.registro.br/mailman/listinfo/gter
>> >>
>> > --
>> > gter list https://eng.registro.br/mailman/listinfo/gter
>> --
>> gter list https://eng.registro.br/mailman/listinfo/gter
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>
>