J'avais cru comprendre que la limitation d'accès aux données devait se mettre en place hier le 4 avril, et je craignais que les problèmes rencontrés hier soir en soient la conséquence. Mais apparemment non, hier c'était juste un problème comme d'habitude
Le message du 29 mars 2021 annonce bien la mise en place des restrictions d'accès pour le l20 avril:
Dans les routines de chargement des vents, il n'y a pas de temporisation actuellement entre le chargement des dalles (de 10 x 10°) successives. Juste le temps de traitement de chaque dalle qui est d'environ 1 à 3 secondes.Update to NOMADS/FTPPRD access limits
The National Centers for Environmental Prediction (NCEP) will be making a change to the user access policy for NOMADS and FTPPRD only. The usage policy will restrict individual user access to 120 hits/minute for only the websites listed above. All other website usage policies will remain as they are today. This policy is applied as a sum of hits per user Internet Protocol (IP) address across all sites listed above.
SCN for changes: https://www.weather.gov/media/notificat ... hanges.pdf
Implementation date April 20, 2021
Je pense que quand le site de téléchargement est pleinement opérationnel et sans restrictions, on dépasse les 120 hits par minute. C'est très probable qu'on soit alors touché par ces nouvelles restrictions (attente de 1 minute avant de nouveaux hits à ce que j'ai compris).
Soit on ne fait rien et on verra comment ça se passe avec les délais d'attente successifs d'une minute, mais ce n'est pas forcément la meilleure idée car la procédure est un peu sensible et il y a parfois des pertes de données quand elle est interrompue de multiples fois. L'intégrité* des données est vérifiée une fois la zone totale chargée, ce qui entraine parfois le redémarrage du camembert à zéro une fois qu'il est complètement rempli, ça arrive de temps en temps.
Une alternative simple à mettre en oeuvre est effectivement de placer une pause de durée paramétrable entre chaque chargement de dalle, genre 5 secondes pour commencer à tester. Je vais mettre à jour les scripts dans ce sens et peut-être les essayer quelques jours avant le 20 avril pour ne pas être surpris.
Une amélioration notable serait de vérifier l'intégrité* de chaque dalle une fois chargée, et de recommencer à charger uniquement la dernière dalle si elle n'est pas correcte. Cela éviterait d'attendre que tout soit chargé pour vérifier, et de devoir tout recharger si ce n'est pas ok. Ca demande un peu plus de travail.
Une solution radicale serait de charger les données successivement dès qu'elles tombent (les +12h d'abord, ensuite les +24h, etc... au lieu d'attendre comme actuellement que les prévisions max soient disponibles avant de commencer à charger), et surtout de charger les données à partir d'une autre adresse que le grib filter: il me semble bien qu'il y a un site ftp qui n'est pas concerné pas les limitations de hits à venir. Il faut que je le retrouve. Ca demande de repenser tout l'automatisme, c'est un gros travail que je repousse depuis des années et si le changement d'heure s'était arrêté (en heure d'hiver) cela n'aurait pas été vraiment nécessaire à faire. Comme cet arrêt du changement d'heure est constamment différé et dans le soucis de ne plus avoir quelques petits stress quelques fois par an, je vais sans doute essayer de m'y mettre cette année.
Une autre solution alternative proposée à chaque passage à l'heure d'été par limelight (
) serait de ne pas opérer de changement d'heure pour les bascules, de rester toujours en heure d'hiver (UTC+1), mais alors en Europe centrale, l'été les bascules se passeraient à 09h00 et 21h00. Je ne suis pas sûr que cette solution soit bien accepter par la majorité des joueurs, je préfèrerais l'éviter.*: l'intégrité des données des vents vient du fait que les fichiers grib2 de la NOAA sont décomposés à la fois en base de données (pour le calcul d'avancement des bateaux et le calcul de la projection) ainsi qu'en fichiers shape utilisés pour l'affichage sur la carte. Lorsque la NOAA hoquette (time out, proxy error et autres joyeusetés), il arrive qu'il n'y ait pas le même nombre d'éléments dans la base de données et dans les fichiers shape, ce qui fait qu'on a des vents sur la carte, mais pas dans le moteur. C'était arrivé il y a longtemps à un bateau dans l'Atlantique Sud sur le Jules Verne, et c'est ce qui m'avait amené à rajouter ce test d'intégrité.
Il y a un autre gros chantier actuellement qui est d'essayer de monter une infrastructure pouvant encaisser des centaines, voire des milliers de joueurs pour éventuellement proposer un partenariat à une course officielle. Nos choix de développement de départ étaient sans doute mal réfléchis pour une telle perspective: tous les calculs des points de la projection sont faits coté serveur, cela offre une interface légère aux clients (plutôt que le calcul soit fait par leur navigateur internet) mais si 1000 clients tournent la roue en même temps, le serveur doit calculer plusieurs fois par secondes 1000 x 36 (heures) x 6 (points de projection par heure) (à vos calculettes) et envoyer ces données aux clients... c'est un certain challenge en cours d'évaluation...
Donc en résumé, oui, pout faire simple, on va pour l'instant mettre une petite pause entre chaque chargement de dalle, de durée variable pour ajuster au mieux. En conséquence, et comme à chaque fois en heure d'été, nous sommes obligés de descendre un peu la limite des prévisions max disponibles sur l'interface du jeu. Pour les petites courses de 2 jours cela n'a pas d'importance. C'est plus handicapant pour les longues courses. Nous ne doutons pas que les joueurs qui se battent pour les premières places ont d'autres sources de renseignement pour les prévisions à long terme, comme windy, zygrib, zezo, vrtool ou autre. Ce serait sympa de créer un fil sur le forum recensant les sites internet permettant de voir les prévisions à long terme pour les joueurs qui ne sont pas forcément au courant.
Bon vent !
.
