News Corrections des lags/freezes

Statut
N'est pas ouverte pour d'autres réponses.

nathan818

Staff
Admin
Admin Forum
12/12/2019
236
1 168
60
27
| Dernière édition :
Ceux présents l'ont remarqué, le second test de Totem a été complètement parasité par les lags/freezes.
Ça en a agace beaucoup et c'est d'autant plus incompréhensible puisqu'il n'y avait "que 150 joueurs".

Pour que vous puissiez comprendre la situation, je vais vous faire un petit résumé sur les performances et le fonctionnement des serveurs Minecraft :

Fonctionnement du serveur MC
La "tick loop"
Comme pour la majorité des serveurs de jeux, le serveur MC est piloté par une "boucle" principale. Cette boucle se répète et chaque exécution est appelée un "tick".
À chaque "tick", le serveur fait un certain nombre d'opérations :
  • traiter les packets entrants des joueurs (attaques, déplacements, placement de blocs, ...) ;
  • mettre à jour le monde (redstone, eau, ...) ;
  • faire spawn les mobs et traiter leur IA ;
  • mettre à jour la position des joueurs et des entités ;
  • etc.
Le serveur Minecraft a pour objectif d’exécuter exactement 20 ticks par seconde, soit 1 tick toutes les 50 millisecondes (50ms).

✅ Lorsque le serveur ne lag pas :
Il met moins de 50ms pour exécuter 1 tick. Par exemple, s'il met 10ms seulement, il attendra ensuite 40ms sans rien faire avant le tick suivant.
Ressenti : Le jeu est fluide.

💥 Lorsque le serveur est surchargé :
Il se peut qu'il mette plus de 50ms pour exécuter un tick ! Par exemple, s'il met 75ms, il ne sera plus capable d’exécuter les 20 ticks par seconde comme attendu (il ne pourra en exécuter que ~13... - 1000ms/75ms = ~13).
Ressenti : les joueurs ont une sensation de latence : les entités se déplacent plus lentement (on le remarque surtout avec les flèches, enderpearls, etc), les joueurs se "téléportent", etc.

Il y a également une dernière possibilité :
⚠ Lorsque le serveur ne lag pas, mais a des surcharges aléatoires :
Le serveur met moins de 50ms pour exécuter 1 tick en général, mais d'un coup il va mettre 400ms à en exécuter 1 (peut-être parce qu'une opération sera anormalement longue, comme une mise à jour de lumière). On appelle ça des "lag spikes" ("pointes de lag" traduit en français).
Ressenti : Le jeu est fluide, mais par moment tout s'arrête de bouger.

Limites du serveur MC
Il n'est pas possible d'exécuter les opérations de la tick loop en parallèle. Ce qui fait que les serveurs MC sont forcément limités à un certain nombre de joueurs, même en achetant le processeur le plus puissant du monde !

Pour pallier à ça, nous utilisons des "proxys" (BungeeCord et Velocity sont les plus connus) qui redirigent de façon transparente les joueurs vers différents serveurs.
Par exemple, FunCraft n'est pas un énorme serveur capable d'accueillir plus de 5000 joueurs. En réalité il s'agit de plein de petits serveurs aux capacités différentes (les hubs/lobbys à 150+ slots, les serveurs Rush/Skywars/... à ~20 slots, etc).

Le problème des PvP/Factions est que l'objectif est souvent d’accueillir le maximum de joueurs sur un seul monde (et donc un seul serveur).

Optimisations
Évidemment le premier objectif sur un serveur accueillant des très nombreux joueurs est d'optimiser au maximum toutes les opérations de la tick loop pour pouvoir accueillir le maximum de joueurs sans lags !
Pour nous l'opération est en bonne voie puisque le serveur a été capable d'accueillir 450 joueurs sur le même monde sans lags (pour un serveur PvP ce chiffre est en général plus proche des 300 - d'ailleurs c'est fou le nombre de serveurs Factions qui trichent/mentent sur leur nombre de joueurs connectés, il faudra qu'on en discute un jour).

Ce genre d'optimisations ne se fait pas par magie, c'est un processus long qui dure dans le temps.

Pour les lags "classiques", on analyse les parties du code qui mettent en moyenne le plus de temps à s'exécuter à chaque tick et on essayer de réduire leur temps d'exécution (en utilisant de meilleurs algorithmes, etc).

Pour les "lag spikes", il faut en premier identifier les opérations qui durent parfois trop longtemps et essayer de les lisser sur plusieurs ticks.

Le problème des totems
Suite à ces informations, on pourrait croire que lors du totems il y avait des "lag spikes" venant de la tick-loop : les joueurs arrêtaient tous de bouger d'un coup par moment.
Surprise : non, ce n'est pas ça. La tick-loop n'avait aucun lag et mettait moins de 20ms pour exécuter chaque tick, donc aucun problème pour les 20 ticks par seconde ! Absolument aucun tick n'a excédé les 50ms.

Mais alors, d'où viennent ces lags lors du totem ?! Et bien c'est la question en or... Malheureusement je n'avais pas les outils nécessaires pour analyser tout ce qu'il se passait lors de ce totem (car je m'attendais à ce que les lags éventuels viennent de la tick-loop).
J'ai quelques pistes (principalement côté réseau/packets), mais il faudra encore faire des "totems qui lags" pour pouvoir comprendre puis corriger ça. C'est le pire dans ce genre de situations : il faut la reproduire pour pouvoir la corriger... Surement même qu'il faudra la reproduire plusieurs fois.

Pour ceux qui veulent quelques info supplémentaires :
- pas de soucis de tps donc, aucun tick n'a excédé les 50ms
- pas de soucis liés à la GC (aucune GC n'a excédée les 2ms et elles étaient toutes très espacées)
- peu probable que le souci soit lié aux threads netty du spigot (j'avais quelques outils d'analyses pour ça - mais je vais quand même les monitorer la prochaine fois, sais-t-on jamais)

Le soucis semble donc ne pas venir du spigot directement ?! Il faut donc monitorer les proxys.
Si le pb n'est lié ni au spigot ni au proxy alors il faudra envisager de monitorer le réseau (maybe un pb spigot<->bungee ou bungee<->client).

En soit la rencontre de 150 joueurs dans une zone minuscule qui sont en full pvp c'est assez intense, en out/joueurs on a :
- 20pps de déplacement
- ~8 pps de swing de mains
- qq pps pour le sneak, les metadata de fire, etc

On voit bien l'explosion du traffic out sur ce graph pendant les quelques minutes du totem (rose : bungee, violet : spigot du totem) :
1589876044515.png

---

Conclusion
Ce problème reste la dernière grosse barrière avant la vraie ouverture du serveur... dès qu'il sera réglé on pourra enfin démarrer les totems, le classement, la pubs !
Il faudra surement encore plusieurs tests de totems ratés pour le corriger... Mais avant je dois finir de préparer tous les outils nécessaires pour analyser tout ça.

On va surement faire des totems sous forme de "mini-jeux" pour faciliter ces tests (le stuff ne sera pas lié au reste du faction et tout le monde sera p4u3 avec pots, etc).
 

Aiirosolo

Membre
26/03/2020
50
77
60
Bien que n'ayant pas compris grand chose, pour moi il s'agit exactement du genre de transparence que la communauté de Pactify (du moins la partie mature) attendait, certes c'est peut être long et compliqué pour le staff de toujours faire des reporting de ce genre mais au moins la communauté se sent impliquée et le sentiment d'abandon disparaît.
Pour le principe des totems test sous forme de mini-jeux c'est une solution parfaite, on est d'une part prévenu pour les lags / freezes mais personne perdra de stuff donc 100% de fun pour les joueurs !

Bon courage pour la suite et merci de l'update !
PS : n'oubliez pas les 49 LockAP qu'il reste hein ;)
 
  • J'aime
Réactions : wordaime

Styleure

Staff
Admin
Admin Forum
07/01/2020
113
478
60
25
Bien que n'ayant pas compris grand chose, pour moi il s'agit exactement du genre de transparence que la communauté de Pactify (du moins la partie mature) attendait, certes c'est peut être long et compliqué pour le staff de toujours faire des reporting de ce genre mais au moins la communauté se sent impliquée et le sentiment d'abandon disparaît.
Pour le principe des totems test sous forme de mini-jeux c'est une solution parfaite, on est d'une part prévenu pour les lags / freezes mais personne perdra de stuff donc 100% de fun pour les joueurs !

Bon courage pour la suite et merci de l'update !
PS : n'oubliez pas les 49 LockAP qu'il reste hein ;)
En résumé, t'as rien compris mais t'es content quand même ? 😂
 

Dunk

Membre
11/03/2020
35
23
60
Salut !
Comme Airosolo l'a dit, nous apprécions fortement ce genre de post vis-à-vis de la transparence que vous communiquer avec nous, certes . Pouvez-vous nous communiquer d'autres informations, par exemple si le totem sera cassable à l'épée en émeraude? Ou si vous comptez enlevez le portail de back du totem afin que même les personnes en combat puisses aussi l'emprunter et atterrir directement dans le manoir, ou dans un délais de combien de temps comptez vous faire des essais totems mais dans d'autres biomes, par ailleurs..

Auriez-vous une fourchette de jours à nous communiquer concernant la mise en place finale des totems malgrès les efforts et la recherche que Nathan fait actuellement? C'est pas tout mais j'aimerai bien me repayer mon grade mais si c'est pour perdre 7-10 jours à tourner dans le spawn et pouvoir en profiter pleinement que 20 jours cela ne vaux pas le coup.
Merci :)
 

ChooKzZ

Membre
11/03/2020
86
86
60
Salut !
Comme Airosolo l'a dit, nous apprécions fortement ce genre de post vis-à-vis de la transparence que vous communiquer avec nous, certes . Pouvez-vous nous communiquer d'autres informations, par exemple si le totem sera cassable à l'épée en émeraude? Ou si vous comptez enlevez le portail de back du totem afin que même les personnes en combat puisses aussi l'emprunter et atterrir directement dans le manoir, ou dans un délais de combien de temps comptez vous faire des essais totems mais dans d'autres biomes, par ailleurs..

Auriez-vous une fourchette de jours à nous communiquer concernant la mise en place finale des totems malgrès les efforts et la recherche que Nathan fait actuellement? C'est pas tout mais j'aimerai bien me repayer mon grade mais si c'est pour perdre 7-10 jours à tourner dans le spawn et pouvoir en profiter pleinement que 20 jours cela ne vaux pas le coup.
Merci :)
Mon pote tu sais très bien que tu n'auras jamais de date, tu as bien eu l'expérience pdt 4 ans.
 

nathan818

Staff
Admin
Admin Forum
12/12/2019
236
1 168
60
27
Pour annoncer une date il faudrait que je sache à quel moment le problème sera corrigé, vous imaginez bien que c'est impossible de savoir.
Sans ce bug on avait prévu que les totems soient automatisés (avec points de classement) ce Week-End. Puis on aurait ajouté les autres temples au fur et à mesure la semaine suivante.
Du coup j'espère que les prochains tests permettront d'identifier clairement le problème.

Sinon :
- Oui le totem se casse avec l'épée en émeraude aussi.
- Pour le retour au manoir même en combat, je ne sais pas encore. Ce qui est sûr c'est que ça sera impossible pendant les premiers jours.
- Pour les AP restants, on attends l'ouverture officielle (la fin de la beta / le début de la promo).
 

Aiirosolo

Membre
26/03/2020
50
77
60
Pour annoncer une date il faudrait que je sache à quel moment le problème sera corrigé, vous imaginez bien que c'est impossible de savoir.
Sans ce bug on avait prévu que les totems soient automatisés (avec points de classement) ce Week-End. Puis on aurait ajouté les autres temples au fur et à mesure la semaine suivante.
Du coup j'espère que les prochains tests permettront d'identifier clairement le problème.

Sinon :
- Oui le totem se casse avec l'épée en émeraude aussi.
- Pour le retour au manoir même en combat, je ne sais pas encore. Ce qui est sûr c'est que ça sera impossible pendant les premiers jours.
- Pour les AP restants, on attends l'ouverture officielle (la fin de la beta / le début de la promo).
Oh le temple MAYA qui va arriver avec son immense labyrinthe, ses jardins sous terrains et ses salles secrètes, hâte ! 😱 😱 😱 😱
 

Dunk

Membre
11/03/2020
35
23
60
Pour annoncer une date il faudrait que je sache à quel moment le problème sera corrigé, vous imaginez bien que c'est impossible de savoir.
Sans ce bug on avait prévu que les totems soient automatisés (avec points de classement) ce Week-End. Puis on aurait ajouté les autres temples au fur et à mesure la semaine suivante.
Du coup j'espère que les prochains tests permettront d'identifier clairement le problème.

Sinon :
- Oui le totem se casse avec l'épée en émeraude aussi.
- Pour le retour au manoir même en combat, je ne sais pas encore. Ce qui est sûr c'est que ça sera impossible pendant les premiers jours.
- Pour les AP restants, on attends l'ouverture officielle (la fin de la beta / le début de la promo).
Merci de ta franchise , concernant les totems aujourd'hui, il me semble Sentrance avait dit qu'il devait y en avoir plusieurs dans la journée, cela est toujours maintenue?

Merci
 

nathan818

Staff
Admin
Admin Forum
12/12/2019
236
1 168
60
27
Ça sera surement demain les autres totems de test, tout n'est pas encore prêt pour analyser correctement la source des lags.
 

fisakakou

Membre
25/03/2020
10
5
5
Franchement bravo, moi qui me plaignais d'une manque de communication, pour le coup tu as fait très fort, expliquer quelque chose d'assez complexe à des joueurs inexpérimenté dans un domaine pour certains inconnu, c'est du très beau travail, ton post est très bien expliqué vrm bravo. tiens nous au courant des avancements de tes recherches et est ce que peut être le fait que le totem soit sur un autre serveur/proxy crée le lag alors que peut être il n'y aurait pas ses lags sur le serveur principal de pactify (ce qui m'étonnerai au vu des autres évents)
 

PurpleBob

Membre
16/03/2020
58
46
10
C'est carré si les stuffs sont fournis sinon c'est mort flm j'ai dja crash 2 fois en 1 totem
 

GOD_HAWX

Membre
25/04/2020
236
154
60
Bruxelles
Ceux présents l'ont remarqué, le second test de Totem a été complètement parasité par les lags/freezes.
Ça en a agace beaucoup et c'est d'autant plus incompréhensible puisqu'il n'y avait "que 150 joueurs".

Pour que vous puissiez comprendre la situation, je vais vous faire un petit résumé sur les performances et le fonctionnement des serveurs Minecraft :

Fonctionnement du serveur MC
La "tick loop"
Comme pour la majorité des serveurs de jeux, le serveur MC est piloté par une "boucle" principale. Cette boucle se répète et chaque exécution est appelée un "tick".
À chaque "tick", le serveur fait un certain nombre d'opérations :
  • traiter les packets entrants des joueurs (attaques, déplacements, placement de blocs, ...) ;
  • mettre à jour le monde (redstone, eau, ...) ;
  • faire spawn les mods et traiter leur IA ;
  • mettre à jour la position des joueurs et des entités ;
  • etc.
Le serveur Minecraft a pour objectif d’exécuter exactement 20 ticks par seconde, soit 1 tick toutes les 50 millisecondes (50ms).

✅ Lorsque le serveur ne lag pas :
Il met moins de 50ms pour exécuter 1 tick. Par exemple, s'il met 10ms seulement, il attendra ensuite 40ms sans rien faire avant le tick suivant.
Ressenti : Le jeu est fluide.

💥 Lorsque le serveur est surchargé :
Il se peut qu'il mette plus de 50ms pour exécuter un tick ! Par exemple, s'il met 75ms, il ne sera plus capable d’exécuter les 20 ticks par seconde comme attendu (il ne pourra en exécuter que ~13... - 1000ms/75ms = ~13).
Ressenti : les joueurs ont une sensation de latence : les entités se déplacent plus lentement (on le remarque surtout avec les flèches, enderpearls, etc), les joueurs se "téléportent", etc.

Il y a également une dernière possibilité :
⚠ Lorsque le serveur ne lag pas, mais a des surcharges aléatoires :
Le serveur met moins de 50ms pour exécuter 1 tick en général, mais d'un coup il va mettre 400ms à en exécuter 1 (peut-être parce qu'une opération sera anormalement longue, comme une mise à jour de lumière). On appelle ça des "lag spikes" ("pointes de lag" traduit en français).
Ressenti : Le jeu est fluide, mais par moment tout s'arrête de bouger.

Limites du serveur MC
Il n'est pas possible d'exécuter les opérations de la tick loop en parallèle. Ce qui fait que les serveurs MC sont forcément limités à un certain nombre de joueurs, même en achetant le processeur le plus puissant du monde !

Pour pallier à ça, nous utilisons des "proxys" (BungeeCord et Velocity sont les plus connus) qui redirigent de façon transparente les joueurs vers différents serveurs.
Par exemple, FunCraft n'est pas un énorme serveur capable d'accueillir plus de 5000 joueurs. En réalité il s'agit de plein de petits serveurs aux capacités différentes (les hubs/lobbys à 150+ slots, les serveurs Rush/Skywars/... à ~20 slots, etc).

Le problème des PvP/Factions est que l'objectif est souvent d’accueillir le maximum de joueurs sur un seul monde (et donc un seul serveur).

Optimisations
Évidemment le premier objectif sur un serveur accueillant des très nombreux joueurs est d'optimiser au maximum toutes les opérations de la tick loop pour pouvoir accueillir le maximum de joueurs sans lags !
Pour nous l'opération est en bonne voie puisque le serveur a été capable d'accueillir 450 joueurs sur le même monde sans lags (pour un serveur PvP ce chiffre est en général plus proche des 300 - d'ailleurs c'est fou le nombre de serveurs Factions qui trichent/mentent sur leur nombre de joueurs connectés, il faudra qu'on en discute un jour).

Ce genre d'optimisations ne se fait pas par magie, c'est un processus long qui dure dans le temps.

Pour les lags "classiques", on analyse les parties du code qui mettent en moyenne le plus de temps à s'exécuter à chaque tick et on essayer de réduire leur temps d'exécution (en utilisant de meilleurs algorithmes, etc).

Pour les "lag spikes", il faut en premier identifier les opérations qui durent parfois trop longtemps et essayer de les lisser sur plusieurs ticks.

Le problème des totems
Suite à ces informations, on pourrait croire que lors du totems il y avait des "lag spikes" venant de la tick-loop : les joueurs arrêtaient tous de bouger d'un coup par moment.
Surprise : non, ce n'est pas ça. La tick-loop n'avait aucun lag et mettait moins de 20ms pour exécuter chaque tick, donc aucun problème pour les 20 ticks par seconde ! Absolument aucun tick n'a excédé les 50ms.

Mais alors, d'où viennent ces lags lors du totem ?! Et bien c'est la question en or... Malheureusement je n'avais pas les outils nécessaires pour analyser tout ce qu'il se passait lors de ce totem (car je m'attendais à ce que les lags éventuels viennent de la tick-loop).
J'ai quelques pistes (principalement côté réseau/packets), mais il faudra encore faire des "totems qui lags" pour pouvoir comprendre puis corriger ça. C'est le pire dans ce genre de situations : il faut la reproduire pour pouvoir la corriger... Surement même qu'il faudra la reproduire plusieurs fois.

Pour ceux qui veulent quelques info supplémentaires :
- pas de soucis de tps donc, aucun tick n'a excédé les 50ms
- pas de soucis liés à la GC (aucune GC n'a excédée les 2ms et elles étaient toutes très espacées)
- peu probable que le souci soit lié aux threads netty du spigot (j'avais quelques outils d'analyses pour ça - mais je vais quand même les monitorer la prochaine fois, sais-t-on jamais)

Le soucis semble donc ne pas venir du spigot directement ?! Il faut donc monitorer les proxys.
Si le pb n'est lié ni au spigot ni au proxy alors il faudra envisager de monitorer le réseau (maybe un pb spigot<->bungee ou bungee<->client).

En soit la rencontre de 150 joueurs dans une zone minuscule qui sont en full pvp c'est assez intense, en out/joueurs on a :
- 20pps de déplacement
- ~8 pps de swing de mains
- qq pps pour le sneak, les metadata de fire, etc

On voit bien l'explosion du traffic out sur ce graph pendant les quelques minutes du totem (rose : bungee, violet : spigot du totem) :
Voir la pièce jointe 735

---

Conclusion
Ce problème reste la dernière grosse barrière avant la vraie ouverture du serveur... dès qu'il sera réglé on pourra enfin démarrer les totems, le classement, la pubs !
Il faudra surement encore plusieurs tests de totems ratés pour le corriger... Mais avant je dois finir de préparer tous les outils nécessaires pour analyser tout ça.

On va surement faire des totems sous forme de "mini-jeux" pour faciliter ces tests (le stuff ne sera pas lié au reste du faction et tout le monde sera p4u3 avec pots, etc).
Aussi intéressant à préciser à propos des ticks, peu importe si le joueur a 1ms ou 50ms, il aura en réalité 50ms. Ensuite pareil, si le joueur a 51ms ou 100ms, il aura en réalité 100ms, et ainsi de suite...
 
  • J'aime
Réactions : Wenlix et Joriis

nathan818

Staff
Admin
Admin Forum
12/12/2019
236
1 168
60
27
Du coup, petit retour rapide sur les tests effectués ce soir :
C'est 100% confirmé, les lags ne viennent pas du spigot et des tps. De ce côté là, aucun soucis il devrait théoriquement gérer centaines de joueur tranquille.
Le problème vient bel et bien du réseau. Par moment le serveur ne reçoit plus aucun packet pendant ~500ms (parfois même plusieurs secondes)...
Bref, je vais essayer de trouver la cause exacte et tester avec d'autres machines. :/
 

nathan818

Staff
Admin
Admin Forum
12/12/2019
236
1 168
60
27
| Dernière édition :
Le problème vient donc à 100% de la connexion entre les serveurs.
Dès que la bande passante entre 2 de nos dédiés dépasse les 100MB/s, les packets commencent à drop par à-coups...

En poussant le test avec plus de dédiés (A<->B, A<->C, A<->D...) en limitant la bande passante par dédié à 100MB/s, les drops de packet apparaissent aux alentours des 250MB/s.
C'est très gênant puisqu'en totem le trafic monte facilement à 200MB/s et qu'il devrait monter à 400MB/s avec 250 joueurs (ce qui était le nombre de slots prévu pour les totems)...

Alors je ne sais pas encore si c'est un bug ou une limite d'OVH. Tous nos serveurs ont une bande passante publique d'au moins 500MB/s, mais il n'y a pas de détails sur les liens OVH<->OVH (je pensais que c'était la même limite)...
Pour les connaisseurs, notez qu'on n’utilise pas de vRack puisqu'ils ne sont pas disponibles avec la gamme GAME. Bref, je vous tiens au courant dès que j'ai des réponses à ces questions. Et tous nos serveurs sont dans le même datacenter.

Edit:
Pour le prochain test on va passer d'1 seul proxy à 4 proxy (ce qui réduira donc le traffic entre 2 dédiés afin ne pas dépasser ce cap fatidique des 100MB/s). En parallèle j'essaye de voir directement OVH pour des détails et des solutions.
Et pour la suite je verrais également si il est possible de diminuer la bande passante utilisée (il est surement possible de réduire la fréquence de certains paquets, etc).
 

LeZiaA

Membre
29/03/2020
14
9
10
Le nombre de slots prévu pour les totems risque de baisser avec ce problème ? Merci pour ce post
 

nathan818

Staff
Admin
Admin Forum
12/12/2019
236
1 168
60
27
| Dernière édition :
Le nombre de slots prévu pour les totems risque de baisser avec ce problème ? Merci pour ce post
On a arrivera bien à corriger le problème, donc non.

Bon, toutes nos machines ne sont pas affectés par ces débit faibles (certaines sont à 450+MB/s sans soucis, même en gamme GAME). La plus affectés est celle des totems...

Edit: l'équipe technique d'OVH doit intervenir sur le serveur bientôt.
 
  • J'aime
Réactions : Aiirosolo

Dunk

Membre
11/03/2020
35
23
60
On a arrivera bien à corriger le problème, donc non.

Bon, toutes nos machines ne sont pas affectés par ces débit faibles (certaines sont à 450+MB/s sans soucis, même en gamme GAME). La plus affectés est celle des totems...

Edit: l'équipe technique d'OVH doit intervenir sur le serveur bientôt.
Salut !
Donc en gros tu n'est pas capable de résoudre seule le soucis? Mais il y a quoi qui change de la version 1 de pactify à la version 2 ? C'est pas normal ...
 

James

Membre
07/03/2020
50
27
60
| Dernière édition :
Salut !
Donc en gros tu n'est pas capable de résoudre seule le soucis? Mais il y a quoi qui change de la version 1 de pactify à la version 2 ? C'est pas normal ...
Pour répondre à ta première question, le problème vient de la bande passante entre les machines et non du serveur de jeu donc c'est à OVH de corriger le problème et pour répondre à ta deuxième question, y'a tout qui a été refait entre la v1 et la v2 de Pactify mais comme je l'ai dit avant, ce n'est pas ça le problème.
 
Statut
N'est pas ouverte pour d'autres réponses.