[GTER] Tempo de Resposta esperado em Ethernet - TCP/IP

[João Carlos Mendes Luís]

Rubens Marins wrote:
> Sem muitos detalhes, a solucao permite habilitar remotamente, bombas
> d'agua assim como comportas, entres outros equipamentos.
>
> Existem dois Centro de operação, um pŕoximo dos equipamentos e outro a
> 300Km. O fundamental é que funcione o Centro que esta próximo, e este
> funciona , mas foi pago pra uma solução para dois centros , e queremos
> os dois .
> O link de rádio tem uma largura de banda de 10Mbps / Full Duplex, ele
> foi testado com tudo que voce imaginar , login em dominio, impressão
> remota , tudo funciona perfeito, inclusive video conferencia, somente
> nao funciona o software de monitoramento. Voce pode inclusive dar ping
> flood no linux que ele nao perde pacotes. No momento não usamos para
> mais nada além de tentar rodar o software, a ideia é no futuro colocar
> qos.
>
> A parte do link de comunicação foi licitado  separado do software que
> monitora, e não temos motivo nenhum para crer que o link de
> comunicação possa ter problemas, por que a empresa que presta o link
> se colocou a disposição para qualquer coisa, e realmente não vejo que
> seja o problema do link, já que ele tem boa performance, uma nova
> licitação adquirindo mais um novo link exigindo uma baixa latência tem
> um preço estratoférico.
>
> Nós medimos com mrtg , uma maquina usando o software durante um dia
> todo em ambiente local, dá pico de 300Kpbs de uso , logo largura de
> banda não é problema. A perda de pacotes no links é menor do que 0.2%,
> a unica diferença de um centro de operações para outro é a latência.
>
> Como foi licitado e projetado no governo anterior , não podemos fazer
> nada quanto a fugir da solução, o máximo que podemos e provar que a
> solução entregue difere da solução licitada, e exigir que ela
> funcione, agora temos de resolver o problema para que o dinheiro
> publico não vá para o ralo, comprando uma solução que não funciona
> direito.
>
> Não temos duvida que o software não é adequado, mas o fornecedor esta
> dizendo que o problema não é dele , assim precisamos de base para
> levar o caso para o juridico, se preciso for.
>   

Que tal comecar nos dando o nome do fornecedor do software?  Acredito 
que isso não seja contra a lei, certo?

Com um pouco de sorte, o google acha os logs desta lista, e futuros 
compradores vao querer saber com voce se o problema foi solucionado...   ;-)


Voltando ao aspecto mais prático, software travando é defeito.  Ele 
poderia até dizer que há erro de comunicação, e não mostrar nada, mas 
travar É defeito.

Se quiser replicar o defeito em rede local, coloca um roteador de baixa 
capacidade no meio do caminho, e sobrecarrega ele com algum tipo de ping 
flood, processos dessnecessários, etc..  Daí não podem mais dizer que o 
problema é do link, e toda a sua solução é de rede Ethernet local.  E 
tambem não podem reclamar da latência pois todo mundo sabe que Ethernet 
é uma rede Best Effort, que não garante NADA.  Perda e latência são 
aceitáveis dentro do protocolo, e se não gostarem, que usem outros 
protocolos acima para minimizar esse problema, por exemplo, o bom e 
velho TCP.

Acredito que o seu link de rádio seja melhor que muitas redes locais que 
eu tenho visto.  Ele não pode ser usado como desculpa.

                                        Jonny

-- 
João Carlos Mendes Luís - Networking Engineer - jonny at jonny.eng.br