Optimisation des performances

• N'utilisez pas de caches partagés pour les cœurs de processeur de votre contrôleur.

• Si vous utilisez des bus de terrain Ethernet pour votre appareil cible, utilisez un adaptateur physique pour eux. N’utilisez pas d’architecture de commutateur.

• Utilisez un noyau temps réel.

  Nous vous recommandons d'utiliser le noyau de préemption RT (https://rt.wiki.kernel.org) pour votre système Linux. Dans le cas des distributions Debian et Ubuntu, vous trouverez un noyau RT sous forme de package que vous pourrez facilement installer à l'aide du apt commande. Pour plus de détails à ce sujet, consultez le manuel de votre distribution.

  • Sur les systèmes Debian

    sudo apt-get install linux-image-rt-amd64

  • Vérifiez quel noyau vous utilisez avec le uname -a commande. Par exemple.

• Évitez d'utiliser un gestionnaire de fenêtres, un serveur GUI/X ou similaire sur votre système.

  L'utilisation de ces outils pourrait affecter les capacités en temps réel de votre système, ce qui entraînerait une gigue élevée dans l'application CEI).

Utilisation des "rt-tools" :

• Installation de "rt-tools": sudo apt install rt-tests

• Démarrage de "cyclictest" : sudo cyclictest -p 99 -t -m

• Le man cyclictest La commande vous montre davantage d'options de ligne de commande que vous pouvez utiliser pour mieux mesurer des aspects de performances plus spécifiques ou plus spécifiques de votre système.

• Désactivez le mode d'économie d'énergie du processeur.

• Désactivez l'hyperthreading.

  Vous pouvez utiliser la commande suivante pour désactiver l'hyperthreading (exemple) :

  echo off | sudo tee /sys/devices/system/cpu/smt/control

• Désactivez autant que possible la mise à l’échelle et la commutation de la fréquence du processeur.

  Par exemple, définissez la fréquence minimale et maximale du processeur sur la même valeur (fixe).

• Désactivez le mécanisme d'étranglement en temps réel du noyau Linux, car cela peut provoquer des tremblements sur votre système.

  Pour plus d'informations, voir : La Linux Foundation : Planification — RT throttling

  Vous pouvez utiliser la commande suivante pour désactiver la limitation en temps réel (exemple) :

  echo -1 > /proc/sys/kernel/sched_rt_runtime_us

• Vérifiez et modifiez le gouverneur de planification/mise à l’échelle.

  • Vérifiez le gouverneur de planification/de mise à l'échelle utilisé :

    cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

  • Modifiez le gouverneur de planification/mise à l'échelle utilisé (comme root/admin) à Performance:

    echo "performance" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
    # set it for all available cores:
    echo "performance" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
    echo "performance" > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor
    echo "performance" > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor

    Notez que le régulateur de mise à l'échelle doit être réinitialisé à chaque démarrage du système. Vous pouvez également le définir au moyen de la configuration du noyau.

    Le intel_pstate Le pilote du noyau peut rendre le réglage correct plus difficile. Par conséquent, vous devez utiliser le cpufreq-info commande pour vérifier votre configuration.

  • Vous pouvez également utiliser des programmes tels que cpu-freq-utils. Cela pourrait interférer avec les pilotes Intel pstate. Ces pilotes nécessitent normalement une approche différente pour définir la fréquence du processeur.

  • Pour plus d'informations, voir : https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt

• Désactiver HyperV dans le BIOS (si disponible).

• Créez une application de test qui décrit grossièrement l'application pour laquelle vous souhaitez optimiser votre système (en termes de ressources requises, de performances requises et de taille du projet).

• Vous pouvez le faire de manière itérative : créez d’abord une approximation très grossière, puis développez-la pour vous rapprocher de plus en plus de l’application réelle.

• Min. Gigue (µs) / Max. Gigue (µs)

  • Les valeurs doivent être aussi proches que possible des valeurs déterminées par le programme "cycletest". Les détails sont décrits dans la section Configuration de Linux.

  • Pour plus d’informations sur la gigue et la latence, consultez : Définitions de la gigue et de la latence

  • Pour plus d'informations sur l'onglet Surveillance, voir : Onglet : Surveillance

• Temps de cycle moyen (µs) / Max. Temps de cycle (µs) Temps de cycle (µs)

  • Le cycle maximum ne doit jamais s'approcher du temps de cycle configuré. Cela entraîne des problèmes dès que le système subit une charge élevée.

  • Gardez toujours le temps de cycle aussi court que possible.

• Divisez les tâches de longue durée en plusieurs tâches plus petites.

• Lors de l'exécution, le temps de cycle maximum de la tâche la plus prioritaire ne doit jamais atteindre le temps de cycle configuré. Si vous ne pouvez pas éviter cela, vous devez augmenter le temps de cycle configuré pour garantir des temps d'exécution cohérents.

• Lors du démarrage de systèmes de bus de terrain (par exemple EtherCAT ou PROFINET), les cycles de démarrage peuvent entraîner une charge CPU légèrement plus élevée. Dans ce cas, il est judicieux de surveiller la charge du processeur peu de temps après le démarrage de l'application.

Les options suivantes ne peuvent pas être modifiées dans CODESYS Virtual Control SL, mais doit être configuré sur l'hôte :

• Définissez la valeur pour DisableCpuDmaLatency à 1 :

  [SysCpuHandling]
  Linux.DisableCpuDmaLatency=1

  • Notez qu'il s'agit du paramètre par défaut à partir de la version d'exécution 4.11.0.0.

  • Pour vérifier votre version d'exécution, cliquez sur Suppléments → Mettre à jour Linux → Système → Information système.

• Vérifiez si le noyau temps réel est réellement utilisé.

  • Depuis la version 4.11.0.0, vous pouvez utiliser la commande shell PLC rt-get kernelinfo pour vérifier cela.

  • Si vous disposez d'une ancienne version, vous pouvez le faire directement sur la ligne de commande avec la commande uname -a.

  • Si le noyau temps réel n’est pas utilisé, vous devez alors recommencer depuis le début.

• Vous pouvez utiliser les tests de l'étape précédente Configuration du système d'exécution CODESYS pour tester votre application CEI.

• Vous pouvez utiliser le Multicœur fonctionnalité dans CODESYS.

• Déterminez les bonnes priorités pour vos tâches. Les tâches importantes devraient avoir une priorité plus élevée.

  Tableau 5. Cartographie des priorités des tâches IEC et des priorités des threads Linux :

  Priorité des tâches CEI	Priorité Linux
  --	88 (SCHED_FIFO)
  --	57 (SCHED_FIFO)
  0 (priorité en temps réel la plus élevée)	56 (SCHED_FIFO)
  15 (priorité en temps réel la plus basse)	41 (SCHED_FIFO)
  16 (pas de priorité en temps réel)	0 (SCHED_OTHER)
  31 (pas de priorité en temps réel)	0 (SCHED_OTHER)
  --	0 (SCHED_OTHER)
  Avis Sur un système Linux classique, la plupart des interruptions (IRQ) et des opérateurs du noyau ont la priorité Linux 50. L'utilisation des priorités (en cas de charge élevée) ci-dessus peut empêcher les fonctions du système (réseau/stockage) de fonctionner comme prévu

  
  
  

• Vous pouvez configurer la priorité d'une tâche dans la configuration de la tâche correspondante.

  

Si vous n'obtenez pas les performances souhaitées après toutes les étapes mentionnées ici, vous pouvez consulter les sections suivantes :

• Informations spécifiques au bus de terrain

• [Pour les experts] – Outils et sujets supplémentaires

• Vérifier la Send Time / Recv Time valeurs sur la page d’état EtherCAT.

  • Un processeur x64 avec un processeur Intel Core i7 et un bon adaptateur devrait avoir moins de 10 µs.

  • Les processeurs ARM avec puce intégrée auront environ 50 µs ou plus.

  

• Vérifier la Send Time / Recv Time valeurs sur la page d’état PROFINET.

  • Un processeur x64 avec un processeur Intel Core i7 et un bon adaptateur devrait avoir moins de 10µs.

  • Les processeurs ARM avec puce intégrée auront environ 50 µs ou plus.

  

• Pour trier vos priorités et les IRQ requises, vous pouvez utiliser les commandes du shell PLC irq-list et irq-set-prio.

  • Ces commandes utilisent les priorités Linux normales et non les priorités CEI.

  • Cette optimisation n'est pas possible dans CODESYS Virtual Control SL, mais plutôt sur le système hôte.

• Utilisez une carte réseau distincte pour les appareils.

• Pour plus d'informations, voir :

  • EtherCAT

  • PROFINET

  • Ethernet/IP

  • CANbus, CANopen

• KernelShark / trace du noyau

  • C'est le programme de choix si vous estimez que la cause de vos problèmes de performances est liée à la planification. A l'aide de la « trace du noyau », vous pouvez voir si votre tâche est interrompue par une autre tâche, un autre service ou une interruption.

    • trace-cmd record -p function

    • Vous pouvez utiliser KernelShark pour examiner le généré trace.dat déposer.

  • En général, les problèmes de planification peuvent être divisés en deux catégories :

    • Remplacement/préemption

      • Si l'interruption ou la tâche empêchant l'exécution est inutile, désactivez-la.

      • Augmentez la priorité de votre tâche ou réduisez la priorité des autres.

      • Passez à un autre cœur de processeur.

      Important

      Vérifiez l'efficacité des changements en utilisant les programmes décrits dans le chapitre précédent.

    • Temps d'exécution

      Voir ci-dessous : "Trace de la fonction noyau"

• Trace de fonction du noyau

  • Si vous déterminez que le temps d'exécution du code est trop long, vous pouvez utiliser cet outil pour identifier le problème.

  • Si la fonction avec un temps d'exécution trop élevé se trouve dans votre propre code, vous devez alors l'optimiser.

  • Si la fonction avec un temps d'exécution trop élevé se trouve dans le noyau, vous pouvez essayer d'obtenir la fonctionnalité souhaitée avec une autre fonction du noyau. Alternativement, vous pouvez également transmettre les paramètres de configuration au pilote du noyau afin de réduire le temps d'exécution.

  • Si aucune de ces options ne résout le problème, vous devrez probablement utiliser un matériel plus puissant.

Examinez les points suivants et vérifiez s'ils constituent ou non le bon outil pour atteindre vos objectifs de performance :

• PREEMPT_FULL

• isolcpu

• rcu_nocbs

• rcu_nocb_poll

• pas de verrouillage logiciel

• irqbalance désactiver

• kernel.sched_rt_runtime_us