Por que a navegação / download é tão lenta ao fazer o upload / sincronização com o Google Drive através da ethernet?

Question

Primeiro, observe que estou usando ethernet, não wifi.

Verificando com meu ISP, eu tenho 5Mbps de download e 512Kb de upload.

Então, por que é que, ao fazer o upload para o Google Drive (acontece que eu uso o aplicativo do Mac OSX Google Drive executado na barra de menus), acho que surfe seja TÃO lento?

A quantidade relativamente pequena de largura de banda que eu tenho disponível para o upload deixa muita largura de banda de cabo e / ou ISP para fazer o download ?

Isso é algo que eu sempre confundi. Eu tentei conversar com meu provedor, mas eles não sabiam a resposta.

    

Answer 1

O gargalo é - como você assumiu - o upstream: se estiver saturado pelo upload, ele introduzirá alta latência nos pacotes ack do TCP (no que se refere a downloads grandes) e em consultas DNS e solicitações HTTP (ao contrário de suas respostas) - isso resultará em uma lentidão altamente perceptível.

Como a maior parte dessa latência vem do enfileiramento e do armazenamento em buffer, a solução é restringir seus envios a algo como 95% da largura de banda de upload disponível. Isso manterá as filas e os buffers quase vazios, mas não impedirá significativamente seus envios.

    

Answer 2

A saturação do seu envio NÃO deve causar alta latência. Você deseja que carreguem para saturar seu envio, caso contrário você estaria desperdiçando largura de banda e desnecessariamente prolongando os envios. Dito isso, em muitas redes domésticas, saturar seu upstream causa alta latência, mas NÃO é apenas um fato da vida que você tem que aceitar e conviver, é um bug que pode ser consertado, não apenas contornado, reduzindo a velocidade de uploads .

Se saturar seu upstream causa alta latência, é um sinal clássico de que você precisa corrigir um problema de bufferbloat.

Se o Google Drive usar o TCP para seu envio, ele não deverá exacerbar o congestionamento nem causar aumento de latência, porque o TCP possui mecanismos internos para evitar congestionamentos e controlar congestionamentos.

No entanto, um software de roteador mal projetado que não faz fila inteligente será suscetível a um problema conhecido como bufferbloat, que é onde alguns roteadores mal projetados se concentram muito em tentar nunca descartar pacotes, portanto eles armazenam tudo em buffer e deixe suas filas de buffer crescerem excessivamente, o que efetivamente oculta o congestionamento do TCP (o TCP usa pacotes descartados como um sinal de congestionamento), impedindo que o TCP faça o controle de congestionamento que é muito bom.

Examine o bufferbloat e veja o firmware do aftermarket no seu roteador que suporta as inovações anti-bufferbloat que foram pioneiras no projeto CeroWrt, como o FQ_CoDel (ou o CoDel simples) e o Explicit Congestion Notification (ECN).

Além disso, se o seu roteador (possivelmente com firmware pós-mercado) permitir qualquer tipo de limitação de largura de banda da porta WAN, você deverá limitar o envio da porta WAN à largura de banda upstream da sua conexão de banda larga.

Ou seja, digamos que você tenha uma situação como esta:

• A porta WAN do seu roteador é Gigabit Ethernet
• Ele está conectado a um modem ADSL2 + definido no Anexo A, e você está pagando "até 25 Mbps para baixo, até 6 Mbps para cima"
• Você mediu seu upload com dslreports.com/speedtest (a ferramenta de teste de velocidade do DSLReports mede o bufferbloat, tornando-o muito melhor que Speedtest.net), e você está recebendo apenas 400kbps de upload.

Neste cenário, uma vez que você sabe que o upstream de banda larga realmente mede apenas 400kbps, defina a porta WAN do roteador para enviar apenas 400kbps para o modem. Isso provavelmente impedirá que as filas de buffer inchadas se acumulem.

    

Answer 3

Eu estava me deitando com esse problema e, em seguida, executei o TCP Optimizer do link e usei-o para definir minha conexão para configurações ideais. Agora, a sincronização do Google Drive não está mais matando minha rede. Bons momentos.