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

[Tukso Antartiko]

Já usei softwares feitos para rede local (usando RPC) e o máximo que
ocorreu foi lentidão. Travamento do software ou problemas no SO não
são aceitáveis, deveria haver ao menos uma mensagem de erro do próprio
software. Contacte o fabricante.

Quanto à rede primeiro você tem que entender o que o software está
tentando fazer (tamanho de pacote, protocolo, uso de banda, ...) rode
o wireshark para saber o que está acontecendo.

O simples fato de ser rádio não deve ser a causa do problema, mas sim
como a rede foi contruída. Você faz 300km só com rádio? É meio difícil
não existir fibra no caminho. E qual tipo de rádio/antena? Se pagaram
7mi no software eu exigiria o melhor equipamento do mercado.

Você falou que seriam vários equipamentos (pontos de monitoração) em
um ponto distante e a sala de monitoração 300km de distância. Eu
colocaria o servidor RPC (digamos) neste ponto distante e, da sala de
monitoração, acessaria o servidor RPC por um protocolo mais amigável
através de outra aplicação (terminal, site web, ...). Além de melhorar
a rede entre o servidor e os pontos de monitoração.

Também acho que o problema pode estar relacionado a perda de pacotes,
veja se há perda com pacotes de tamanho diversos e proibindo a
fragmentação.



On 7/5/07, Rubens Marins <rubens.marins at gmail.com> wrote:
> Caros,
>
> Estou tentando ajudar um orgão do governo com o seguinte problema:
>
> Este orgão licitou uma solução envolvendo hardware e software para
> monitoramento o status de determinados equipamentos . Estes
> equipamentos estão instalados a 300 Km de distãncia da sala de onde
> ser quer monitorar, a região é de dificil acesso, assim foi feita uma
> rede via rádio para ligar os dois pontos.
>
> A rede de rádio funciona bem,  com boa largura de banda, o delay de um
> ponto  ao outro pela rede é de 40-50 ms.
>
> O Software esta apresentando muitos problemas, causado por esse delay
> , ele  somente foi testado e projetado para rede local, onde o delay é
> desprezivel. Os problemas são graves pois ele não avisa simplesmente
> que não conseguiu ler informação do dispositivo X , ou se ele  esta em
> OFF, o software trava por completo, as vezes levando o SO junto.
>
> A licitação que especificou o software foi mal feita, especificando
> somente que o programa deve funcionar em "Ethernet - TCP/IP", não diz
> qual o tempo de resposta que o programa deve suportar.
>
> A empresa do programa diz que não vai corrigir o software, pois ele
> funciona bem( testando onde tudo esta ligado no mesmo switch), e que o
> problema é do link de comunicação.
>
> Agora é que vem minha pergunta:  Existe algo nas especificações do
> TCP/IP ou da Ethernet, que mencione que um programa TCP/IP deve
> aceitar/permitir  algum atraso na comunicação entre os dois pontos ?
>
> Isso por que temos de dizer que o software não esta conforme o
> especificado, para poder demonstrar , que ele não atende os
> requisitos. O Software custou mais de 7 Milhões e desde janeiro não
> esta funcionando nada  e o prazo onde pode ser reclamado algo esta
> esgotando. Passar fibra optica de um ponto ao outro vai custar mais
> milhões, e demorar anos para ficar pronta.
>
>
> Desde já agradeço as opniões dos colegas,
>
>
> --
> Rubens Marins
> Administrador de Sistemas
> rubens.marins at gmail dot com
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>