La machine est très probablement chargée et d'autres travaux peuvent être plus prioritaires que les vôtres.

Mais il est possible que vous ayez mal paramétré votre travail. Par exemple, si la commande squeue vous indique (QOSMaxWallDurationPerJobLimit) dans la colonne intitulée NODELIST(REASON), cela signifie que vous demandez un temps d’exécution trop important (directive #SBATCH –time=… dans votre job) pour la QoS sélectionnée (soit par défaut, soit via la directive #SBATCH –qos=… dans votre job). Dans ce cas, vous devez supprimer votre job et le modifier avant de le soumettre à nouveau.

Remarque : si vos travaux CPU (respectivement GPU) respectent les critères des partitions CPU et des QoS CPU (respectivement des partitions GPU et des QoS GPU) définies sur la machine, ne les supprimez pas. Ils seront exécutés dès que possible.

La priorité d'un travail dépend de plusieurs critères :

• La QoS (Quality of Service) choisie : les QoS “dev” n'autorisant que des travaux courts (moins de 2h) sont plus prioritaires que les QoS par défaut “t3” (autorisant des travaux jusqu'à 20h) et les Qos “t3” sont plus prioritaires que les QoS “t4” autorisant des travaux mono-nœuds jusqu'à 100h.
• Des modalités de régulation des heures de calcul basées sur un critère dit de fairshare : un projet ayant pris de l'avance sur la consommation de son allocation d'heures verra la priorité de ses travaux baisser. Vous pouvez vérifier le statut de votre projet avec la commande idr_compuse.
• Le temps d'attente dans la queue : plus un travail a été soumis il y a longtemps, plus sa priorité augmente.

Ces différents critères assurent que tous les utilisateurs puissent utiliser les ressources tout en maximisant le taux de remplissage de la machine.