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

["Fabrício F. Kammer"]

Boa tarde Rubens,

Sendo esta a função do software, controlar equipamentos, muda de figura, 
pois a comunicação entre o software e os equipamentos é pequena, somente 
instruções de acionamento e se é toda sobre TCP/IP, então deve haver 
algum problema realmente no desenvolvimento do software, algo 
relacionado ao tratamento de erro/timeout.

[]s

Rubens Marins escreveu:
> 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.
> 
> Em ultimo caso, vamos usar sim Terminal Service ou algo do genero, mas
> isso sera somente um remendo , e vou somente sugerir isso quando a
> batalha estiver terminada , e nós os derrotados.
> 
> 
> 
> Agradeco os comentários recebidos, espero que estas novas informações
> possam ajudar os colegas em busca de uuma solução.
>