Temurin-build: Téléchargement extrêmement lent. Que diriez-vous de partager des torrents pour économiser de la bande passante ?

Les versions sont hébergées sur GitHub (par exemple https://github.com/AdoptOpenJDK/openjdk11-binaries/releases/download/jdk-11.0.5%2B10/OpenJDK11U-jdk_x64_linux_hotspot_11.0.5_10.tar.gz). GitHub les stocke et les distribue avec Amazon S3. Il est donc peu probable que ce soit un problème en amont. Je viens de télécharger l'archive ci-dessus avec 5,07 Mo/s.

Je télécharge toujours un programme d'installation Windows x64 MSI précompilé , près de 30 sur 174 Mo jusqu'à présent... à 5 Ko/s maintenant.

34,3 Mo ... téléchargement bloqué. Le navigateur affiche moins de 1 Ko/s.

34,3 Mo ... téléchargement bloqué. Le navigateur affiche moins de 1 Ko/s.

Le mien descend dans environ 65 secondes, je soupçonne que vous avez un problème localisé.

Dans ce cas, je devrais blâmer Deutsche Telekom... pseudo-aspirante connexion haut débit dans les zones rurales.

@LigH-de Je suis désolé que vos téléchargements soient lents, mais jusqu'à présent, rien n'indique que le problème soit de notre côté. Le statut GitHub et le AWS sont également tous verts. Si vous voulez de l'aide pour diagnostiquer votre problème, veuillez fournir au moins un traceroute.

De tels problèmes sont généralement causés par des ports de commutation qui sont en surcapacité à un point de transit, soit parce que trop de trafic a été acheminé dans la mauvaise direction (réparable en modifiant la table de routage), soit parce que certains FAI sont trop bon marché pour mettre à niveau les ports de peering ou acheter plus de capacité de transit. Dans tous les cas, votre meilleur pari est de vous plaindre auprès de votre FAI et de GitHub (dans cet ordre). Ils sont en mesure d'aider. Fournissez-leur au moins un traceroute.

Merci. C'est certainement une question temporelle. Toujours à peu près aux mêmes heures, certains services deviennent peu fiables (par exemple, les flux Twitch continuent de caler, de se désynchroniser, de se déconnecter), d'autres services ne sont pas endommagés.

En ce moment, je viens de le télécharger avec 2 Mo/s en 1 minute.

Les téléchargements AdoptOpenJDK sont également très très lents via ma connexion DSL de 50 Mo (Allemagne - Deutsche Telekom VDSL, fonctionnant parfaitement généralement à plus de 5 Mo/sec de vitesse dl). J'obtiens généralement 30-50 Ko/sec - donc un téléchargement OpenJDK typique prend plus d'une heure.
Je suppose qu'il s'agit d'un problème entre Deutsche Telekom et Amazon (et "telia.net" selon tracert le système de réseau qui les relie tous les deux).

Le serveur de téléchargement utilisé est
52.216.161.35 (github-production-release-asset-2e65be.s3.amazonaws.com) selon certains trackers d'emplacement IP, cette IP est située en Virginie (États-Unis). Les données sont transmises via IPv4.

Le problème avec Deutsche Telekom est qu'ils veulent que d'autres fournisseurs achètent du transit. C'est pourquoi tous leurs autres liens sont saturés et vous obtenez des vitesses de téléchargement épouvantables. La meilleure chose à faire est de vous plaindre à la fois auprès de DTAG et de GitHub dans l'espoir qu'ils commencent à échanger du trafic via un lien direct.

Je viens de recevoir un téléchargement d'environ 8 Mo/s. Peut-être qu'ils ont négocié quelque chose ?

Rapports similaires dans le forum doom9 concernant AviSynth+ ; Je ne sais pas quel FAI utilise ce journaliste, mais je pense qu'il réside en Pologne, il devra donc peut-être passer par une dorsale allemande.

J'essaye de contacter le support github à ce sujet.

Rapports similaires dans le forum doom9 concernant AviSynth+ ; Je ne sais pas quel FAI utilise ce journaliste, mais je pense qu'il réside en Pologne, il devra donc peut-être passer par une dorsale allemande.

J'essaye de contacter le support github à ce sujet.

J'ai le même. Même fournisseur que vous.

Mêmes problèmes ici, aussi en Allemagne. Le fournisseur est 1&1.

Edit : correction du problème avec une IP non européenne.

Aujourd'hui, j'ai essayé d'informer Deutsche Telekom (avec le support prioritaire de notre société) ainsi que Telia. Je suppose que l'étranglement se situe quelque part entre leurs réseaux fédérateurs...

Idem pour moi, j'utilise aussi Deutsche Telekom. Cela se produit avec tous les téléchargements github.

En utilisant mon client VPN (utilisant également une adresse IP allemande), je peux télécharger à pleine vitesse.

C'est donc un problème avec notre FAI ? Y a-t-il quelque chose que nous pouvons faire pour cela?

Idem ici (aussi Deutsche Telekom). J'ai contourné cela en utilisant Opera et son VPN intégré.

Je ne sais pas si cela aide quand de nombreuses personnes se plaignent du même problème (sur le portail Web Telekom Kundencenter, pas sur la hotline téléphonique). Mais mieux vaut essayer que hausser les épaules.

Même problème ici (Deutsche Telekom), merci pour l'astuce avec Opera. Se plaindra à Deutsche Telekom. Fait intéressant aussi sur T-Mobile (même entreprise).

Téléchargement à 44kb/s

|------------------------------------------------- -----------------------------------------|
| Statistiques |
| Hôte - % | Envoyé | Recv | Meilleur | Moy | Poignet | Dernier |
|------------------------------------------------| ------|------|------|------|------|------|
| 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 |
| Aucune réponse de l'hôte - 100 | 2 | 0 | 0 | 0 | 0 | 0 |
| Aucune réponse de l'hôte - 100 | 2 | 0 | 0 | 0 | 0 | 0 |
| m686-mp2.cvx1-b.lis.dial.ntli.net - 10 | 11 | 10 | 0 | 21 | 28 | 28 |
| Aucune réponse de l'hôte - 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 |
| Aucune réponse de l'hôte - 100 | 2 | 0 | 0 | 0 | 0 | 0 |
| Aucune réponse de l'hôte - 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 |
| Aucune réponse de l'hôte - 100 | 2 | 0 | 0 | 0 | 0 | 0 |
| Aucune réponse de l'hôte - 100 | 2 | 0 | 0 | 0 | 0 | 0 |
| lb-140-82-118-4-ams.github.com - 10 | 11 | 10 | 0 | 41 | 44 | 41 |
|________________________________________________|______|______|______|______|______|______|

Telia est donc de nouveau impliquée... mais difficile de savoir qui blâmer dans cette bataille entre les grands FAI du réseau fédérateur.

@tpavesi Virgin Media appartient-elle à Liberty Global ? Traceroute ressemble à ça (aorta.net). Liberty Global est un délinquant notoire à cet égard. Se plaindre à leur support client.

@LigH-de Telia est l'un des plus grands fournisseurs de connectivité de transit. Ce n'est pas de leur faute si les parties concernées ne souhaitent pas mettre à niveau le lien.

Virgin Media appartient à Liberty Global. Il y a eu une énorme panne au Royaume-Uni en
les derniers jours exactement où vous avez mentionné.

Le lun. 27 avril 2020 à 07:35, Andreas Ahlenstorf [email protected]
a écrit:

@tpavesi https://github.com/tpavesi Virgin Media appartient-elle à Liberty
Global? Traceroute ressemble à ça (aorta.net). Liberty Global est un
délinquant notoire à cet égard. Se plaindre à leur support client.

@LigH-de https://github.com/LigH-de Telia est l'un des plus grands
fournisseurs de connectivité de transit. Ce n'est pas de leur faute si les parties impliquées
Je ne veux pas mettre à jour le lien.

-
Vous recevez ceci parce que vous avez été mentionné.

Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/AdoptOpenJDK/openjdk-build/issues/1349#issuecomment-619759818 ,
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AAXA2GBZAA52NG53YZMUSZ3ROURR5ANCNFSM4JFRUSVA
.

En effet. Twitch s'est également cassé, le public de cette affaire était donc large.

Une observation de la France rurale sur le cuivre et 100kbs max (ah oui).
Même problème en essayant d'obtenir "AdoptOpenJDK" ... mais j'ai trouvé une solution de contournement "agricole".
Si je laisse le navigateur ouvert et que la machine n'est pas perturbée, le téléchargement se fait comme d'autres l'ont trouvé... quelques secondes puis s'interrompt... répétez plusieurs fois jusqu'à quelques pour cent, puis se bloque/se ferme/se termine.
Mais .. si je continue à utiliser le navigateur et à passer d'une page à l'autre, cela semble redonner vie à la bête.
J'ai dû essayer plusieurs fois mais cela semble être reproductible ... en ce sens que le téléchargement s'endort.
Je ne sais pas si c'est utile mais ça peut aider en attendant.
Win7pro64+Opéra

@karianna
Pour info, je travaille sur le pack de codage de code VS qu'environ 6% des utilisateurs n'ont pas réussi à télécharger le JDK après 3 tentatives , ce qui n'est pas un petit nombre. Y a-t-il une idée pour l'améliorer?

BTW, outre les FAI mentionnés dans les commentaires ci-dessus, avec presque tous les FAI en Chine, nous avons un accès instable à GitHub/AWS.

Le problème n'est pas un manque de bande passante à la source. Le problème, ce sont les interconnexions saturées entre les FAI. Nous ne pouvons pas faire grand-chose tant que nous déléguons la gestion des téléchargements à GitHub. Nous sommes sur le siège du passager pour ainsi dire.

Il existe des moyens d'améliorer la situation, mais ils rendent les choses plus compliquées et nécessitent un travail important et peut-être de l'argent. L'argent est moins un problème, le travail est parce que nous sommes à court de personnel.

Options que je vois :

• Transférer les téléchargements via l'API au lieu de les rediriger vers GitHub. Gaspille des ressources sur les binaires de streaming, mais ils peuvent être mis en cache par Cloudflare. Nous aurions besoin d'une licence ICP de Chine pour mettre en cache le contenu et activer Cloudflare China CDN. Cependant, combiner l'API avec des téléchargements n'est pas quelque chose que je souhaite.
• Développez un programme capable de synchroniser un répertoire local sur une machine/Azure Blob Storage avec notre API/GitHub (versions uniquement). Cela nous permettrait d'héberger nous-mêmes nos téléchargements (probablement à nouveau via Cloudflare) et donnerait la possibilité d'héberger des miroirs (aucune licence ICP requise car quelqu'un d'autre l'hébergerait). Nécessite l'introduction de la signature GPG des sommes de contrôle binaires (devrait être fait de toute façon). Pour la Chine, voir ci-dessus. Problème : Retard lors de la synchronisation de l'API, de GitHub et de la machine locale/Azure Blob Storage.
• Faites quelque chose d'intelligent avec Cloudflare Workers. Pour la Chine, voir ci-dessus.

Si quelqu'un veut y travailler, merci de me contacter.

Merci pour l'information. Il semble qu'une solution idéale serait GitHub/AWS pour fonctionner avec différents FAI, alors nous en bénéficions gratuitement 🤷 .

À propos des miroirs, vous trouverez ci-dessous une conclusion, juste pour info au cas où cela serait utile.
Un miroir hébergé par l'Université Tsinghua en Chine : https://mirrors.tuna.tsinghua.edu.cn/AdoptOpenJDK/
et le billet original pour cela. (C'est en chinois uniquement et vous pouvez traduire la page.)

Merci pour le lien vers ce miroir chinois. https://github.com/tuna/tunasync-scripts/blob/master/adoptopenjdk.py est le script qu'ils utilisent. Faire quelque chose comme ça est une voie potentielle à suivre, mais comme je l'ai dit, et je ne saurais trop le souligner, cela nécessite une vérification des sommes de contrôle, ce qui est beaucoup plus facile avec GPG.

Idem ici (aussi Deutsche Telekom). J'ai contourné cela en utilisant Opera et son VPN intégré.

Idem pour moi .. lent dans Chrome/Opera/Edge sans VPN
(Oui, mon téléchargement est un client mqtt, mais j'ai la même expérience pour JDK)

Lors de l'utilisation d'un VPN (par exemple, le client intégré Operas)
Le téléchargement monte à au moins 500 Ko/s

Merci pour l'astuce avec le miroir chinois. Beaucoup plus rapide que d'utiliser directement le téléchargement Github

J'utilise 1&1 (Deutsche Telekom) et je rencontre toujours le même problème.
Je reçois parfois 1 Ko/s :-(

Une solution pour cela ?

@getashraf J'ai ouvert un ticket chez Deutsche Telekom Kundenportal. Une fois ce problème résolu, je demanderai un remboursement.
J'ai ajouté un lien vers cet article : https://www.golem.de/news/deutsche-telekom-peering-zu-us-servern-scheint-langsam-zu-sein-2012-152982.html

Mais attendez-vous à des appels de Telekom. Ils sont obligés de vous appeler au hasard si le problème persiste ou si vous tempérez avec votre routeur. Ils insistent également sur le fait que vous disposez d'une connexion fonctionnelle car ils ne voient que votre vitesse de synchronisation DSL au service d'assistance.

Il y a une déclaration officielle de German Telekom
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Downloadgeschwindigkeiten-von-GitHub-mal-wieder-unterirdisch/td-p/3873484/page/11

Je ne sais pas si c'est vrai, car c'est toujours plus facile de dire que c'est l'échec d'un autre service.

BdT
Varmandra

@getashraf J'ai ouvert un ticket chez Deutsche Telekom Kundenportal. Une fois ce problème résolu, je demanderai un remboursement.
J'ai ajouté un lien vers cet article : https://www.golem.de/news/deutsche-telekom-peering-zu-us-servern-scheint-langsam-zu-sein-2012-152982.html

Mais attendez-vous à des appels de Telekom. Ils sont obligés de vous appeler au hasard si le problème persiste ou si vous tempérez avec votre routeur. Ils insistent également sur le fait que vous disposez d'une connexion fonctionnelle car ils ne voient que votre vitesse de synchronisation DSL au service d'assistance.

Ce fil a été marqué comme résolu mais ne l'est pas en réalité. Je télécharge toujours avec environ 4-5 kbit/s et peu de temps après, tout s'arrête de télécharger. Comme indiqué dans la réponse officielle, ce n'est pas de leur faute. Je ne suis pas sûr de cela. Néanmoins, il a été marqué comme résolu...

Je ne suis pas sûr de cela.

Pourquoi?

Ils ont eu des problèmes de temps en temps alors que tous les autres fournisseurs n'avaient pas ces problèmes. De plus, c'est une sorte de méfiance générale à l'égard du support Telekom. Les problèmes sont soit non résolus et marqués comme résolus en raison d'un "mauvais département" et/ou cela prend un long chemin à travers les niveaux d'assistance avec une attente au téléphone pendant des heures. J'ai eu le même problème il y a quelques années.

Ils ont eu des problèmes de temps en temps alors que tous les autres fournisseurs n'avaient pas ces problèmes. De plus, c'est une sorte de méfiance générale à l'égard du support Telekom. Les problèmes sont soit non résolus et marqués comme résolus en raison d'un "mauvais département" et/ou cela prend un long chemin à travers les niveaux d'assistance avec une attente au téléphone pendant des heures. J'ai eu le même problème il y a quelques années.

Ah, je vois que j'ai mal lu. Je pensais que tu insinuais que le problème était chez Adopt.

Le téléchargement avec lftp utilisant plusieurs connexions simultanées aide à soulager un peu la douleur. Par exemple

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

Pourtant, les temps de téléchargement sont encore loin d'être normaux.

@getashraf J'ai ouvert un ticket chez Deutsche Telekom Kundenportal. Une fois ce problème résolu, je demanderai un remboursement.
J'ai ajouté un lien vers cet article : https://www.golem.de/news/deutsche-telekom-peering-zu-us-servern-scheint-langsam-zu-sein-2012-152982.html

@bmarwell avez-vous déjà eu de leurs nouvelles ? J'ai fait la même chose avec un "Stoerungsmeldung" mais c'était un désastre complet. Ils voulaient envoyer un technicien chez moi et/ou le DSLAM pour "réparer" cela" et quand j'ai rappelé pour annuler que la hotline était complètement désemparée quand j'ai parlé de problèmes dans le backbone qui ne peuvent être contournés que pour ne pas utiliser le routage Telekom standard (par exemple via VPN).Elle a ensuite voulu me vendre leur service "Computerhilfe".

@getashraf J'ai ouvert un ticket chez Deutsche Telekom Kundenportal. Une fois ce problème résolu, je demanderai un remboursement.
J'ai ajouté un lien vers cet article : https://www.golem.de/news/deutsche-telekom-peering-zu-us-servern-scheint-langsam-zu-sein-2012-152982.html

@bmarwell avez-vous déjà eu de leurs nouvelles ? J'ai fait la même chose avec un "Stoerungsmeldung" mais c'était un désastre complet. Ils voulaient envoyer un technicien chez moi et/ou le DSLAM pour "réparer" cela" et quand j'ai rappelé pour annuler que la hotline était complètement désemparée quand j'ai parlé de problèmes dans le backbone qui ne peuvent être contournés que pour ne pas utiliser le routage Telekom standard (par exemple via VPN).Elle a ensuite voulu me vendre leur service "Computerhilfe".

Deutsche Telekom voulait apporter une solution d'ici la semaine dernière. 🙄 Je dirais qu'il vaut mieux demander à l'équipe Twitter de vous rappeler. Ils en savent plus sur ce qui se passe. J'ai également dit au supporter d'enseigner ce problème à l'équipe de 1er niveau. Ne s'est pas produit, comme il semble.

Alors, harcelez l'équipe Twitter. Je pense que c'est @telekom_hilft ou similaire.

travaillé pour moi avec NordVPN. fournisseur Deutsche telekom Sucks avec Amazon

Le téléchargement avec lftp utilisant plusieurs connexions simultanées aide à soulager un peu la douleur. Par exemple

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

Pourtant, les temps de téléchargement sont encore loin d'être normaux.

Votre solution est géniale, elle a fonctionné.