DSL perde sincronia algumas vezes por semana por longos períodos de tempo

1

Eu tenho um serviço DSL 12/2 bonded da Frontier que perde a sincronia 3-4 vezes por semana por 1-3 horas em média. Eu tenho trabalhado com os técnicos locais que dizem que verificaram tudo e que "fizeram tudo o que sabem fazer". Eles substituíram o gateway uma vez. Eu substituí o fio do NID para o jack interno. Atualmente estou trabalhando com suporte de nível dois. Eles verificaram a perda do problema de sincronização - mas dizem que o único teste que falha é o teste de sincronização (e eles não podem mais executar ping no meu gateway). O suporte do nível 2 está recomendando a substituição do modem (este será o terceiro) e o teste da fiação interna. O suporte de nível 2 também está sugerindo que a relação sinal-ruído pode ser alta para empurrar um 12/2 (que é realmente 3 para cima neste ponto) e que eu posso ter que mudar para o 6/1. Nenhum dos 6 ou mais técnicos que estiveram na casa mencionaram que a relação sinal / ruído é um problema.

Detalhes

  • Substituir o fio pelo NID pareceu ajudar um pouco na velocidade geral. Geralmente, estou ficando quase 12 para baixo e 3 para cima.
  • O suporte do nível 2 mostrou um problema de sincronização na 1h, quando ninguém estava usando a conexão ativamente. No entanto, meu computador pode estar atualizando.
  • Geralmente, o gateway perde a sincronização e, em seguida, tenta sincronizar novamente por 2 a 4 horas em um ou nos dois lados.
  • Recentemente, o modem foi reiniciado sozinho quando eu estava transmitindo um vídeo do meu computador para o AppleTV e alguém estava transmitindo um vídeo sob demanda. Um lado perdeu a sincronização por várias horas. Nós não poderíamos replicar esse acidente
  • Recentemente, ele perdeu a sincronização por três horas quando abri aproximadamente 15 guias em páginas da web exclusivas.
  • A maioria dos problemas de sincronização acontece no final da tarde - entre 4 e 6pm
  • Estou usando o Actiontec F2250 Gateway.
  • Velocidade de link provisionada: 13923/2282 kb.
  • A reinicialização do Gateway não tem efeito na resolução dos problemas de sincronização.
  • Parece haver um problema com o buffer bloat
  • perda de pacotes de 2,8% no ping durante o download de atualização ou upload de software
  • Alta latência durante o download ou upload
  • 7400 pés para DSLAM
  • O lado com melhor SNR vai cair, e o lado com pior SRN vai ficar de pé. (Veja a captura de tela)

    ATUALIZAÇÃO 14/12/2016
  • Novo roteador em 14 de dezembro - após a instalação do novo roteador, havia menos erros de bit na linha 1 e melhor SNR na linha 2.
  • 2 horas após o novo roteador ter sido instalado, as duas linhas foram "silenciosamente inativas" e imediatamente sincronizadas. Para a linha 1: Após 14 minutos de tempo de espera, há 239.738 erros de bit, 2984 erros HEC, 8121 Erros de super frames (margem SNR é 11,8). A linha 2, que está ativa há 10 minutos, possui erros de 1225 bits, 21 erros de HEC, erro 4097 Super framers (margem SNR é 10,3).
  • Erro: xt_TCPMSS: tamanho incorreto (589 bytes), dois minutos antes do último problema de sincronização

    ATUALIZAÇÃO 12-17-2016
  • Na visita técnica de 12 a 14 anos, perguntei ao técnico se ele poderia trocar Cartão DSLAM para a linha 1 e se houvesse outra linha disponível. (Houve um problema óbvio com a linha 1.
  • No dia 12-15, o roteador perdeu a sincronização por volta das 19h.
  • Algo mudou para o positivo após essa perda de sincronização - o gateway agora está ativo por 1 dia e 15 horas. Espero que tenha sido resolvido.

    ATUALIZAÇÃO 18-12-2016
  • Perdeu a sincronização hoje por 1,5 horas.
  • Altos segundos de erro (até 521) em torno desse problema em ambas as linhas
  • Screenshot abaixo


Interrupçõesquenoteidesdequecomeceiarastrear

Sept26,2016—2:55pm—Confirmedmodemoffline.Rebootedmodemviaadmin.Backupat3:06with5.44downand.52up.1lineisdown.Intermittentlinesat3:52.Bothlinesbackbefore4:19.Runningat7.5down,2.0upSept28—9:20AM—Lowbandwidth.3.5Mbpsdown.Resolvedby9:30Sept30—4:35PM:—Lowbandwidth1.5Mbpsdown,.81up.Onelinedown.Backupby5:00pmOctober16:00pmLowbandwidth.1linedown.2.55down,1.07upOctober4,5:55pm—Bothlinesdown.6:00pm,1linedown.October11,noon—verylowbandwidth.—backupbefore12:30October11,3:30pmdown.October11,5:52pmdown—backby6:45October12,4:54pm—1sidedown.2.96Mbps/.89MbpsOctober13,5:20pm—verylowbandwidth.Unusable.One/bothsidesdown.1.64Mbpsup,1.76downOctober18,5:55pm—verylowbandwidth.Unusable..77Mbpsdown,2.88up.UnabletologintomodemOctober19,6:30—lowbandwidth,4.33down,.72up.Highlatency--408ms,highJitter836msOctober23,6:17–lowbandwidth,3.37down,1.22up.1sidedownOctober24,3:37–nobandwidth,one/bothsidesdown.October25,5:25–nobandwidthdown-upworksfine,one/bothsidesdown,abletoping.Backby6:30Nov1,8:15—nobandwidth.Bothsidesdown.Nov2,3:50—lowbandwidth,3.57down,1.31upOnesidedown.Nov4—FrontiertechreplacedwalljackNov7,10:00—onesidedown,bothsidesdown.Nobandwidthdown.Nobandwidthup.Cannotconnecttomodem.1sidestilldownat5:30p.Nov11,1:40—bothsidesdown.Nobandwidth—backat1:43Nov11,5:40—bothsidesdown.Nobandwidth—backby6:20Nov15,4:30—bothsidesdown.Nov183:50—bothsidesdown,onesidebackby4:00Nov2310:00p—verylowbandwidthNov24,8:56a—bothsidesdown.Nov24,4:50p—bothsidesdown.Nov25,Noon—1sidedown.Lowbandwidth,thenbothsidesdown.Nov27,2:40bothsidesdownDec2,5:55OnesidedownDec4—ReplacedwirefromNIDtogateway(1wirenow).Dec66:30-Routerwentoffline,rebootedautomatically(Crashed,thishashappenedbefore,butrarely).Dec66:55-OnesidedownDec8—twoshortdropspossible.(LostconnectivitywithGotoMeeting)Dec9—2:40—Down—appearedtohappenbysendingmultipleHTTPrequests.Stilldownat5:45.Keepstryingtosync.

    
por Scott Simpson 10.12.2016 / 19:51

1 resposta

1

Scott - Sou co-fundador da Firebind . Nossa nova solução de nuvem se concentra em testes contínuos de circuitos ISP de última milha. Fazemos uma série de 11 testes a cada 5 minutos, reunindo 3.168 pontos de dados por dia. Eu concordo que isso soa como um problema que somente o ISP pode consertar. Mas se você quiser coletar mais dados e ver os padrões em alguns dias ou mesmo semanas, sinta-se à vontade para usar nosso teste gratuito. Nosso principal teste simula uma chamada VoIP G.711 por 25 segundos em cada direção a cada 5 minutos, enviando um total de 360.000 pacotes por dia entre os intervalos. Como o teste é de 50 pacotes por segundo usando cargas úteis UDP (em oposição a ICMP), ele fornece uma visão muito mais confiável da perda real de dados do usuário.

Ao testar a cada 5 minutos por alguns dias, você pode acabar vendo certos padrões de hora do dia que poderiam ter referência cruzada com algo acontecendo na rede do provedor.

O link abaixo mostra uma imagem dos resultados da nossa chamada VoIP G.711 simulada. A parte esquerda do gráfico antes de 4 de dezembro era uma conexão banda larga de ondas na Califórnia. Os picos azuis mostram perda de download devido ao "efeito Netflix".

Então, em 4 de dezembro, o site mudou para a Comcast e você pode ver que o problema da perda quase desapareceu completamente.

Banda Larga com Onda de Pacotes e depois Comcast

boa sorte,

Dave

    
por 14.12.2016 / 22:13