[GTER] Dúvida sobre Taxa de Erro

Antonio Carlos Pina antoniocarlospina at gmail.com
Fri Jul 31 07:02:00 -03 2009


Em outras palavras: Bom mesmo é ter o enlace SEM erros :-)

Abs

2009/7/31 Julio Arruda <jarruda-gter at jarruda.com>

> Danton Nunes wrote:
>
>> On Thu, 30 Jul 2009, Julio Arruda wrote:
>>
>>  Danton Nunes wrote:
>>>
>>>> On Mon, 27 Jul 2009, Jose Augusto dos Santos Neto wrote:
>>>>
>>>>  Caros,
>>>>>
>>>>> Uma LP com taxa de alta taxa de erro e de CRC pode causar corrupção dos
>>>>> dados transmitidos ?
>>>>>
>>>>
>>>> sim, mas para evitar isso tem um monte de garantias fim-a-fim. o efeito
>>>> de retransmissões para correção dos erros, etc. será de uma linha
>>>> virtualmente mais lenta, ou mesmo inoperante.
>>>>
>>>> baixar o MTU é uma boa providência para aumentar a chance de
>>>> sobrevivencia de seus pacotinhos.
>>>>
>>>
>>> Se você esta falando de MTU neste link serial
>>> somente......curiosidade, por que ?
>>>
>>
>> CUIDADO, ALTAS ELOCUBRAÇÕES ADIANTE.
>>
>> (e o pior é que nem sei se estão certas)
>>
>> vamos imaginar primeiro que não há overhead em reduzir a MTU (obviamente
>> que há, veremos o efeito disso depois). então se a probabilidade de um
>> pacote estragar com MTU=1U é f1=(t/m)exp(-t/m), onde m é o tempo médio entre
>> erros e t é o período para transmitir uma unidade de MTU (vide distribuição
>> de Poisson). Para transmitir dois pacotes de 1U é preciso ter sucesso em
>> ambos. a chance de sucesso é o produto das chances de sucesso de cada
>> pacote: p1²=(1-f1)²=[1-(t/m)exp(-t/m)]²=1-2f1+(t/m)²exp(-2t/m)
>>
>> para um só pacote com o dobro de MTU temos p2=1-(2t/m)exp(-2t/m)
>>
>> comparando o pacotão com os dois pacotinhos:
>>
>> p1²-p2=1-2(t/m)exp(-t/m)-[1-(2t/m)exp(-2t/m)]=
>> 1-(2t/m)exp(-t/m)-1+(2t/m)exp(-2t/m)=(2t/m)(exp(-2t/m)-exp(-t/m))=
>> (2t/m)exp(-t/m)(exp(-t/m)-1)
>> a. 2t/m>0, pois t>0 m>0
>> b. exp(-t/m)>0 e para t<m (nem faz muito sentido MTU muito longo em canal
>> altamente ruidoso, porque é quase certeza de que vai pifar) exp(-t/m)>1
>>
>> logo p1² > p2 ou seja a chance de sucesso com dois pacotinhos é maior do
>> que com um pacotão.
>>
>> no limite pacotes com MTU=0 passariam todos incólumes. Aí é que entra o
>> overhead. com ele temos que comparar um pacote de 2t+u contra dois de t+u,
>> onde u é o overhead.
>>
>> sucesso de dois pacotinhos c/ overhead: P1²=[1-[(t+u)/m]exp[-(t+u)/m]]²
>> sucesso de um pacotão com overhead: P2=1-[(2t+u)/m]exp[-(2t+u)/m]
>>
>> prá gente não endoidar de vez, voltando aos bons tempos de cálculo I,
>> fazemos f(t+u)=f(t)+f'(t)u, isto é, usando a noção de diferencial, temos:
>>
>> exp[-(t+u)/m] = exp(-t/m)-(u/m)exp(-t/m)+lixo
>> exp[-(2t+u)/m] = exp(-2t/m)-(2u/m)exp(-2t/m)+lixo
>>
>> entonces
>>
>> P1=1-[(t+u)/m][exp(-t/m)-(u/m)exp(-t/m)+lixo]=
>>   1-[(t+u)/m][exp(-t/m)+[(t+u)/m](u/m)exp(-t/m)+caraminguás=
>>
>> 1-(t/m)exp(-t/m)[1+[(t+u)/m](u/m)]+(u/m)exp(-t/m)[1+[(t+u)/m](u/m)]+mixaria=
>>
>>   1-f1[1+(tu+u²)/m²](1+u/t)+poeira=
>>   p1(1-u/t)+pequenos_incômodos.
>>
>> então, o efeito do overhead, se pequeno comparado com a MTU (note que isto
>> não vale para VoIP!) é de piorar a chance de sucesso proporcionalmente à
>> porcentagem de overhead. para pequenos overheads a vantagem ainda está com
>> os dois pacotinhos. é claro que conforme o overhead aumenta, haverá um ponto
>> em que o ganho com a fragmentação é perdido porque teríamos que quebrar um
>> pacotão em dois não tão menores.
>>
>
> Bombei em matematica, porem, nao seria a logica, dizer que se ocorre erro
> de um bit em cada x bits passados, passando a mesma quantidade de bits,
> deveriamos ter a mesma quantidade de erros ?
> Se aumentamos o numero de bits (em 'y' bits) de overhead, como o enlace nao
> sabe o que e' dado do usuario, e o que e' overhead, ele vai aumentar a
> ocorrencia de erros em proporcao para a mesma quantidade de dados 'do
> usuario' passados ?
> Nao consigo imaginar como separar os MESMOS bits (teoria do overhead zero)
> poderia melhorar a situacao. O 'contador' de erros nao reseta no inicio de
> cada pacote :-)
>
>
>> isso tudo se nenhum idiota filtrar ICMP impossibilitar a determinação da
>> MTU do caminho. ;-)
>>
>
> Se voce tiver PMTU discovery, se a comunicacao for TCP, e se passar, a
> fragmentacao NAO vai ocorrer no enlace, vai ser por causa do MSS usado,
> acaba ate sendo melhor do que simplesmente a fragmentacao por MTU 'a
> revelia' do TCP. O overhead e' um pouco maior do que seria com fragmentacoa
> no nivel IP porem.
>
>  --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>
>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>



More information about the gter mailing list