Temurin-build: Baixe extremamente lento. Que tal compartilhar torrents para poupar largura de banda?

Criado em 27 out. 2019  ·  42Comentários  ·  Fonte: adoptium/temurin-build

Tentando baixar o OpenJDK 11, 174 MB a 20 KB/s, 2 horas estimadas. Desacelera ainda mais (10 KB/s) durante a tentativa.

O LibreOffice é fornecido via torrents. Pode ser útil para este projeto também se a largura de banda for um problema para você.

invalid

Comentários muito úteis

Os downloads do AdoptOpenJDK também são muito lentos através da minha conexão DSL de 50 MBit (Alemanha - Deutsche Telekom VDSL, funcionando perfeitamente normalmente com velocidade dl de mais de 5 MB/s). Normalmente, recebo de 30 a 50 KB/s - portanto, um download típico do OpenJDK leva mais de 1 hora.
Presumo que isso seja algum problema entre a Deutsche Telekom e a Amazon (e "telia.net" de acordo com tracert o sistema de rede que conecta os dois).

O servidor de download usado é
52.216.161.35 (github-production-release-asset-2e65be.s3.amazonaws.com) de acordo com alguns rastreadores de localização de IP, este IP está localizado na Virgínia (EUA). Os dados são transmitidos via IPv4.

Todos 42 comentários

As versões são hospedadas no GitHub (por exemplo, https://github.com/AdoptOpenJDK/openjdk11-binaries/releases/download/jdk-11.0.5%2B10/OpenJDK11U-jdk_x64_linux_hotspot_11.0.5_10.tar.gz). O GitHub os armazena e os distribui com o Amazon S3. Portanto, é improvável que seja um problema upstream. Acabei de baixar o tarball citado com 5,07 MB/s.

Ainda estou baixando um instalador do Windows x64 MSI pré-compilado , quase 30 de 174 MB até agora... a 5 KB/s agora.

34,3 MB ... download interrompido. O navegador exibe menos de 1 KB/s.

34,3 MB ... download interrompido. O navegador exibe menos de 1 KB/s.

O meu cai em cerca de 65 segundos, suspeito que você tenha um problema localizado.

Neste caso, eu teria que culpar a Deutsche Telekom... pseudo-pretensa conexão de banda larga em áreas rurais.

@LigH-de Lamento que seus downloads estejam lentos, mas até agora não há indicação de que o problema esteja do nosso lado. O status do GitHub e o AWS também são verdes. Se você quiser ajuda para diagnosticar seu problema, forneça pelo menos um traceroute.

Esses problemas geralmente são causados ​​por portas de switch que estão acima da capacidade em algum ponto de trânsito, seja porque muito tráfego foi roteado na direção errada (corrigível alterando a tabela de roteamento) ou porque algum ISP é muito barato para atualizar as portas de peering ou comprar maior capacidade de trânsito. De qualquer forma, sua melhor aposta é reclamar com seu ISP e GitHub (nessa ordem). Eles estão em posição de ajudar. Forneça a eles pelo menos um traceroute.

Obrigada. Certamente é uma questão temporal. Sempre nos mesmos horários, alguns serviços não são confiáveis ​​(por exemplo, os fluxos do Twitch continuam travando, dessincronizando, desconectando), outros serviços não são prejudicados.

Agora eu acabei de baixá-lo com 2 MB/s em 1 minuto.

Os downloads do AdoptOpenJDK também são muito lentos através da minha conexão DSL de 50 MBit (Alemanha - Deutsche Telekom VDSL, funcionando perfeitamente normalmente com velocidade dl de mais de 5 MB/s). Normalmente, recebo de 30 a 50 KB/s - portanto, um download típico do OpenJDK leva mais de 1 hora.
Presumo que isso seja algum problema entre a Deutsche Telekom e a Amazon (e "telia.net" de acordo com tracert o sistema de rede que conecta os dois).

O servidor de download usado é
52.216.161.35 (github-production-release-asset-2e65be.s3.amazonaws.com) de acordo com alguns rastreadores de localização de IP, este IP está localizado na Virgínia (EUA). Os dados são transmitidos via IPv4.

O problema com a Deutsche Telekom é que eles querem que outros provedores comprem trânsito. É por isso que todos os outros links estão saturados e você obtém velocidades de download abismais. A melhor coisa que você pode fazer é reclamar com o DTAG e o GitHub na esperança de que eles comecem a trocar tráfego por meio de um link direto.

Acabei de receber um download de cerca de 8 MB/s. Talvez eles tenham negociado alguma coisa?

Relatórios semelhantes no fórum doom9 sobre AviSynth+ ; Não sei qual ISP esse repórter usa, mas acredito que ele resida na Polônia, então talvez tenha que passar por uma espinha dorsal alemã.

Tentando entrar em contato com o suporte do github sobre isso.

Relatórios semelhantes no fórum doom9 sobre AviSynth+ ; Não sei qual ISP esse repórter usa, mas acredito que ele resida na Polônia, então talvez tenha que passar por uma espinha dorsal alemã.

Tentando entrar em contato com o suporte do github sobre isso.

Eu tenho o mesmo. Mesmo provedor que você.

Mesmos problemas aqui, também na Alemanha. O provedor é 1&1.

Edit: corrigiu o problema com um ip não europeu.

Hoje tentei notificar a Deutsche Telekom (com o suporte prioritário da nossa empresa) e também a Telia. Suponho que a limitação esteja em algum lugar entre suas redes de backbone ...

O mesmo para mim, estou usando a Deutsche Telekom também. Isso acontece com todos os downloads do github.

Usando meu cliente VPN (também usando um IP alemão), posso baixar a toda velocidade.

Então este é um problema com o nosso ISP? Há algo que possamos fazer sobre isso?

O mesmo aqui (também Deutsche Telekom). Eu trabalhei em torno disso usando o Opera e sua VPN integrada.

Não sei se ajuda quando muitas pessoas reclamam do mesmo problema (no portal da Web Telekom Kundencenter, não na linha direta de telefone). Mas é melhor tentar do que dar de ombros.

Mesmo problema aqui (Deutsche Telekom), obrigado pela dica com o Opera. Vai reclamar na Deutsche Telekom. Curiosamente também sobre a T-Mobile (mesma empresa).

Baixando a 44kb/s

|------------------------------------------------- ------------------------------|
| Estatísticas |
| Host - % | Enviado | Recv | Melhor | Média | Primeiro | Último |
|------------------------------------------------| ------|------|------|------|------|------|
| 10.0.0.1 - 0 | 14 | 14 | 0 | 0 | 1 | 1 |
| 10.73.200.1 - 0 | 14 | 14 | 8 | 13 | 22 | 15 |
|nrth-core-2a-xe-10010-0.network.virginmedia.net - 0 | 14 | 14 | 10 | 14 | 24 | 16 |
| Nenhuma resposta do host - 100 | 2 | 0 | 0 | 0 | 0 | 0 |
| Nenhuma resposta do host - 100 | 2 | 0 | 0 | 0 | 0 | 0 |
| m686-mp2.cvx1-b.lis.dial.ntli.net - 10 | 11 | 10 | 0 | 21 | 28 | 28 |
| Nenhuma resposta do host - 100 | 2 | 0 | 0 | 0 | 0 | 0 |
| uk-lon01b-ri1-ae-25-0.aorta.net - 0 | 14 | 14 | 18 | 21 | 30 | 18 |
| ldn-b1-link.telia.net - 0 | 14 | 14 | 17 | 21 | 31 | 19 |
| Nenhuma resposta do host - 100 | 2 | 0 | 0 | 0 | 0 | 0 |
| Nenhuma resposta do host - 100 | 2 | 0 | 0 | 0 | 0 | 0 |
| ffm-bb2-link.telia.net - 10 | 11 | 10 | 0 | 37 | 41 | 37 |
| ffm-b1-link.telia.net - 0 | 14 | 14 | 34 | 40 | 59 | 35 |
| github-ic-350972-ffm-b1.c.telia.net - 0 | 14 | 14 | 31 | 37 | 48 | 34 |
| Nenhuma resposta do host - 100 | 2 | 0 | 0 | 0 | 0 | 0 |
| Nenhuma resposta do host - 100 | 2 | 0 | 0 | 0 | 0 | 0 |
| lb-140-82-118-4-ams.github.com - 10 | 11 | 10 | 0 | 41 | 44 | 41 |
|________________________________________________|______|______|______|______|______|______|

Então há a Telia envolvida novamente... mas é difícil saber a quem culpar nesta batalha entre os grandes ISP's de backbone.

@tpavesi A Virgin Media é propriedade da Liberty Global? Traceroute se parece com isso (aorta.net). A Liberty Global é um infrator notório a esse respeito. Reclame com o suporte ao cliente deles.

@LigH-de Telia é um dos maiores provedores de conectividade de trânsito. Não é culpa deles se as partes envolvidas não quiserem atualizar o link.

A Virgin Media é propriedade da Liberty Global. Houve uma grande interrupção no Reino Unido em
nos últimos dias exatamente onde você mencionou.

Em segunda-feira, 27 de abril de 2020 às 07:35, Andreas Ahlenstorf [email protected]
escreveu:

@tpavesi https://github.com/tpavesi A Virgin Media é propriedade da Liberty
Global? Traceroute se parece com isso (aorta.net). A Liberty Global é uma
criminoso notório a esse respeito. Reclame com o suporte ao cliente deles.

@LigH-de https://github.com/LigH-de Telia é uma das maiores
provedores de conectividade de trânsito. Não é culpa deles se as partes envolvidas
não quer atualizar o link.


Você está recebendo isso porque foi mencionado.

Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/AdoptOpenJDK/openjdk-build/issues/1349#issuecomment-619759818 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/AAXA2GBZAA52NG53YZMUSZ3ROURR5ANCNFSM4JFRUSVA
.

De fato. O Twitch também quebrou, então o público desse caso foi grande.

Uma observação da França rural em cobre e 100kbs max (oh sim).
Mesmo problema tentando obter "AdoptOpenJDK" ... mas encontrei uma solução 'agrícola'.
Se eu deixar o navegador aberto e a máquina sem perturbações, o download faz como os outros descobriram... alguns segundos depois quebra... repita algumas vezes até alguns por cento e então trava/fecha/termina.
Mas .. se eu continuar a usar o navegador e mover entre as páginas, isso parece incitar a fera de volta à vida.
Tive que tentar isso algumas vezes, mas parece ser repetível ... na medida em que o download adormece.
Não sei se isso é útil, mas pode ajudar nesse meio tempo.
Win7pro64+Opera

@karianna
Para sua informação, estou trabalhando no pacote de codificação VS Code cerca de 6% dos usuários não conseguiram baixar o JDK após 3 tentativas , o que não é um número pequeno. Existe alguma ideia para melhorá-lo?

BTW, além dos ISPs mencionados nos comentários acima, com quase todos os ISPs na China, temos acesso instável ao GitHub/AWS.

O problema não é a falta de largura de banda na fonte. O problema são interconexões saturadas entre ISPs. Não há muito que possamos fazer desde que deleguemos o manuseio dos downloads ao GitHub. Estamos no banco do passageiro, por assim dizer.

Existem maneiras de melhorar a situação, mas elas tornam as coisas mais complicadas e exigem muito trabalho e talvez dinheiro. O dinheiro é um problema menor, o trabalho é porque estamos com falta de mão-de-obra.

Opções que vejo:

  • Encaminhar downloads por meio da API em vez de redirecionar para o GitHub. Desperdiça recursos em binários de streaming, mas eles podem ser armazenados em cache pela Cloudflare. Precisaríamos de uma licença ICP da China para armazenar conteúdo em cache e habilitar o Cloudflare China CDN. Combinar a API com downloads não é algo que eu quero, no entanto.
  • Desenvolva um programa que possa sincronizar um diretório local em uma máquina/Azure Blob Storage com nossa API/GitHub (somente versões). Isso nos permitiria hospedar nossos downloads (provavelmente novamente via Cloudflare) e dar a opção de hospedar espelhos (não é necessária licença ICP porque outra pessoa o hospedaria). Requer a introdução da assinatura GPG de somas de verificação binárias (deve ser feita de qualquer maneira). Para a China, veja acima. Problema: atraso ao sincronizar API, GitHub e máquina local/Azure Blob Storage.
  • Faça algo inteligente com Cloudflare Workers. Para a China, veja acima.

Se alguém quiser trabalhar nisso, por favor, entre em contato.

Obrigado pela informação. Parece que uma solução ideal seria o GitHub/AWS para trabalhar com diferentes ISPs, então nos beneficiamos gratuitamente 🤷 .

Sobre espelhos, abaixo está uma descoberta, apenas para sua informação, caso seja útil.
Um espelho hospedado pela Universidade Tsinghua na China: https://mirrors.tuna.tsinghua.edu.cn/AdoptOpenJDK/
e o bilhete original para ele. (É apenas em chinês e você pode traduzir a página.)

Obrigado pelo link para esse espelho chinês. https://github.com/tuna/tunasync-scripts/blob/master/adoptopenjdk.py é o script que eles estão usando. Fazer algo assim é um caminho potencial a seguir, mas como eu disse, e não posso enfatizar o suficiente, isso requer verificação de somas de verificação, o que é muito mais fácil com o GPG.

O mesmo aqui (também Deutsche Telekom). Eu trabalhei em torno disso usando o Opera e sua VPN integrada.

O mesmo para mim .. lento no Chrome/Opera/Edge sem VPN
(Sim, meu download é um cliente mqtt, mas experimentou o mesmo para JDK)
image

Ao usar VPN (por exemplo, cliente embutido Operas)
O download aumenta para pelo menos 500 KB/s
image

Obrigado pela dica com o espelho chinês. Muito mais rápido do que usar o download do Github diretamente

Estou usando 1&1 (Deutsche Telekom) e ainda estou enfrentando o mesmo problema.
Estou recebendo 1KB/s às vezes :-(

Alguma solução para isso?

@getashraf Abri um ticket no Deutsche Telekom Kundenportal. Assim que isso for resolvido, vou exigir algum dinheiro de volta.
Eu adicionei um link para este artigo: https://www.golem.de/news/deutsche-telekom-peering-zu-us-servern-scheint-langsam-zu-sein-2012-152982.html

Mas espere ligações da Telekom. Eles são forçados a ligar para você aleatoriamente se o problema persistir ou se você temperou com seu roteador. Eles também insistem que você tenha uma conexão funcionando, pois eles veem apenas sua velocidade de sincronização DSL no suporte técnico.

Há uma declaração oficial da Telekom alemã
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Downloadgeschwindigkeiten-von-GitHub-mal-wieder-unterirdisch/td-p/3873484/page/11

Não sei até que ponto isso é verdade, porque é sempre mais fácil dizer que é a falha de um outro serviço.

BdT
Varmandra

@getashraf Abri um ticket no Deutsche Telekom Kundenportal. Assim que isso for resolvido, vou exigir algum dinheiro de volta.
Eu adicionei um link para este artigo: https://www.golem.de/news/deutsche-telekom-peering-zu-us-servern-scheint-langsam-zu-sein-2012-152982.html

Mas espere ligações da Telekom. Eles são forçados a ligar para você aleatoriamente se o problema persistir ou se você temperou com seu roteador. Eles também insistem que você tenha uma conexão funcionando, pois eles veem apenas sua velocidade de sincronização DSL no suporte técnico.

Este tópico foi marcado como resolvido, mas na verdade não é. Ainda estou baixando com cerca de 4-5 kbit/s e logo depois tudo para de baixar. Como afirmado na resposta oficial, não é culpa deles. Eu não tenho certeza sobre isso. Mesmo assim foi marcado como resolvido...

Eu não tenho certeza sobre isso.

Por quê?

Eles tiveram problemas de vez em quando quando todos os outros provedores não tiveram esses problemas. Além disso, é uma espécie de desconfiança geral no suporte da Telekom. Os problemas não são resolvidos e são marcados como resolvidos devido a "departamento errado" e/ou demora muito tempo nos níveis de suporte com espera no telefone por horas. Eu tive o mesmo problema alguns anos atrás.

Eles tiveram problemas de vez em quando quando todos os outros provedores não tiveram esses problemas. Além disso, é uma espécie de desconfiança geral no suporte da Telekom. Os problemas não são resolvidos e são marcados como resolvidos devido a "departamento errado" e/ou demora muito tempo nos níveis de suporte com espera no telefone por horas. Eu tive o mesmo problema alguns anos atrás.

Ah, vejo que interpretei errado. Achei que você insinuou que o problema está no Adopt.

Baixar com lftp usando várias conexões simultâneas ajuda a aliviar um pouco a dor. Por exemplo

lftp -c "pget -c -n 20 https://github.com/mikefarah/yq/releases/download/3.4.1/yq_linux_amd64"

No entanto, os tempos de download ainda estão longe do normal.

@getashraf Abri um ticket no Deutsche Telekom Kundenportal. Assim que isso for resolvido, vou exigir algum dinheiro de volta.
Eu adicionei um link para este artigo: https://www.golem.de/news/deutsche-telekom-peering-zu-us-servern-scheint-langsam-zu-sein-2012-152982.html

@bmarwell você já ouviu falar deles? Eu fiz o mesmo com um "Stoerungsmeldung", mas isso foi um desastre completo. Eles queriam enviar um técnico para minha casa e/ou o DSLAM para "consertar" isso" e quando liguei de volta para cancelar que a linha direta estava completamente sem noção quando falei sobre problemas no backbone que só podem ser contornados para não usar o roteamento padrão da Telekom (por exemplo, via VPN) Ela então quis me vender seu serviço "Computerhilfe".

@getashraf Abri um ticket no Deutsche Telekom Kundenportal. Assim que isso for resolvido, vou exigir algum dinheiro de volta.
Eu adicionei um link para este artigo: https://www.golem.de/news/deutsche-telekom-peering-zu-us-servern-scheint-langsam-zu-sein-2012-152982.html

@bmarwell você já ouviu falar deles? Eu fiz o mesmo com um "Stoerungsmeldung", mas isso foi um desastre completo. Eles queriam enviar um técnico para minha casa e/ou o DSLAM para "consertar" isso" e quando liguei de volta para cancelar que a linha direta estava completamente sem noção quando falei sobre problemas no backbone que só podem ser contornados para não usar o roteamento padrão da Telekom (por exemplo, via VPN) Ela então quis me vender seu serviço "Computerhilfe".

A Deutsche Telekom queria fornecer uma solução até a semana passada. 🙄 Eu diria que é melhor pedir à equipe do Twitter para ligar de volta. Eles sabem mais sobre o que está acontecendo. Eu também disse ao torcedor para ensinar a equipe de 1º nível sobre esse assunto. Não aconteceu, ao que parece.

Então, incomode a equipe do Twitter. Acho que é @telekom_hilft ou similar.

trabalhou para mim com NordVPN. provedor Deutsche telekom é uma merda com a Amazon

Baixar com lftp usando várias conexões simultâneas ajuda a aliviar um pouco a dor. Por exemplo

lftp -c "pget -c -n 20 https://github.com/mikefarah/yq/releases/download/3.4.1/yq_linux_amd64"

No entanto, os tempos de download ainda estão longe do normal.

Sua solução é incrível, funcionou.

Esta página foi útil?
0 / 5 - 0 avaliações