Ottimizzazione delle prestazioni

• Non utilizzare cache condivise per i core del processore del controller.

• Se utilizzi bus di campo basati su Ethernet per il tuo dispositivo di destinazione, utilizza per essi un adattatore fisico. Non utilizzare un'architettura switch.

• Utilizza un kernel in tempo reale.

  Si consiglia di utilizzare il kernel di prelazione RT (https://rt.wiki.kernel.org) per il tuo sistema Linux. Nel caso delle distribuzioni Debian e Ubuntu troverai un kernel RT come pacchetto che potrai installare facilmente utilizzando il comando apt comando. Per dettagli a riguardo, consultare il manuale della propria distribuzione.

  • Sui sistemi Debian

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

  • Controlla quale kernel stai utilizzando con il file uname -a comando. Per esempio.

• Evita di utilizzare un gestore di finestre, un server GUI/X o simili sul tuo sistema.

  L'utilizzo di questi strumenti potrebbe influire sulle capacità in tempo reale del sistema, con conseguente jitter elevato nell'applicazione IEC).

Utilizzo degli "rt-tools":

• Installazione di "rt-tools": sudo apt install rt-tests

• Avvio del "test ciclico": sudo cyclictest -p 99 -t -m

• IL man cyclictest Il comando mostra più opzioni della riga di comando che puoi utilizzare per misurare meglio aspetti prestazionali più o specifici del tuo sistema.

• Disabilita la modalità di risparmio energetico della CPU.

• Disabilita l'hyperthreading.

  È possibile utilizzare il comando seguente per disabilitare l'hyperthreading (esempio):

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

• Disabilitare il ridimensionamento e la commutazione della frequenza della CPU il più possibile.

  Ad esempio, impostare la frequenza minima e massima della CPU sullo stesso valore (fisso).

• Disabilita il meccanismo di limitazione in tempo reale del kernel Linux, perché ciò può causare jitter sul tuo sistema.

  Per ulteriori informazioni, vedere: The Linux Foundation: Scheduling — RT throttling

  È possibile utilizzare il comando seguente per disattivare la limitazione in tempo reale (esempio):

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

• Controllare e modificare il regolatore di pianificazione/dimensionamento.

  • Controllare il regolatore di pianificazione/scalabilità utilizzato:

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

  • Modificare il governatore di pianificazione/scalabilità utilizzato (come root/admin) A 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

    Si noti che il regolatore di scala deve essere reimpostato ogni volta che si avvia il sistema. Puoi anche impostarlo tramite la configurazione del kernel.

    IL intel_pstate driver del kernel può rendere più difficile l'impostazione corretta. Pertanto, dovresti usare il file cpufreq-info comando per verificare la configurazione.

  • Puoi anche utilizzare programmi come cpu-freq-utils. Ciò potrebbe interferire con i driver Intel pstate. Questi driver normalmente richiedono un approccio diverso per impostare la frequenza della CPU.

  • Per ulteriori informazioni, vedere: https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt

• disattivare HyperV nel BIOS (se disponibile).

• Crea un'applicazione di prova che descriva approssimativamente l'applicazione per la quale desideri ottimizzare il tuo sistema (in termini di risorse richieste, prestazioni richieste e dimensioni del progetto).

• Puoi farlo in modo iterativo: prima crea un'approssimazione molto approssimativa e poi espandila per avvicinarti sempre di più all'applicazione reale.

• minimo Jitter (μs)/max. Jitter (μs)

  • I valori dovrebbero avvicinarsi il più possibile ai valori determinati dal programma "cycletest". I dettagli sono descritti nella sezione Configurazione di Linux.

  • Per ulteriori informazioni su jitter e latenza, vedere: Definizioni di jitter e latenza

  • Per ulteriori informazioni sulla scheda Monitoraggio, vedere: Scheda: Monitoraggio

• Tempo ciclo medio (μs)/max. Tempo di ciclo (μs) Tempo di ciclo (μs)

  • Il ciclo massimo non dovrebbe mai avvicinarsi al tempo di ciclo configurato. Ciò porta a problemi non appena il sistema sperimenta un carico elevato.

  • Mantenere sempre il tempo di ciclo il più breve possibile.

• Suddividi le attività di lunga durata in più attività più piccole.

• Durante l'esecuzione, il tempo di ciclo massimo del task con la priorità più alta non dovrebbe mai raggiungere il tempo di ciclo configurato. Se non è possibile evitarlo, è necessario aumentare il tempo di ciclo progettato per garantire tempi di esecuzione coerenti.

• All'avvio dei sistemi bus di campo (ad esempio EtherCAT o PROFINET) i cicli di avvio possono comportare un carico leggermente maggiore della CPU. In questo caso ha senso monitorare il carico della CPU subito dopo l'avvio dell'applicazione.

Non è possibile modificare le seguenti opzioni CODESYS Virtual Control SL, ma devono essere configurati sull'host:

• Imposta il valore per DisableCpuDmaLatency a 1:

  [SysCpuHandling]
  Linux.DisableCpuDmaLatency=1

  • Tieni presente che questa è l'impostazione predefinita a partire dalla versione runtime 4.11.0.0.

  • Per verificare la versione del runtime, fare clic su Extra → Aggiorna Linux → Sistema → Informazioni di sistema.

• Controllare se il kernel in tempo reale viene realmente utilizzato o meno.

  • A partire dalla versione 4.11.0.0 è possibile utilizzare il comando della shell PLC rt-get kernelinfo per verificare questo.

  • Se disponi di una versione precedente, puoi farlo direttamente sulla riga di comando con il comando uname -a.

  • Se il kernel in tempo reale non viene utilizzato, è necessario ricominciare dall'inizio.

• È possibile utilizzare i test del passaggio precedente Configurazione del sistema runtime CODESYS per testare la tua applicazione IEC.

• Puoi usare il Multicore caratteristica in CODESYS.

• Determina le priorità corrette per i tuoi compiti. I compiti importanti dovrebbero avere una priorità più alta.

  Tabella 5. Mappatura delle priorità delle attività IEC e delle priorità dei thread Linux:

  Priorità del compito IEC	Priorità Linux
  --	88 (SCHED_FIFO)
  --	57 (SCHED_FIFO)
  0 (massima priorità in tempo reale)	56 (SCHED_FIFO)
  15 (priorità in tempo reale più bassa)	41 (SCHED_FIFO)
  16 (priorità non in tempo reale)	0 (SCHED_OTHER)
  31 (priorità non in tempo reale)	0 (SCHED_OTHER)
  --	0 (SCHED_OTHER)
  Avviso Su un sistema Linux convenzionale, la maggior parte degli interrupt (IRQ) e dei kernel worker hanno la priorità Linux 50. L'uso di priorità (con carico elevato) superiori a tale valore può far sì che le funzioni di sistema (rete/storage) non funzionino

  
  
  

• È possibile configurare la priorità di un'attività nella rispettiva configurazione dell'attività.

  

Se non ottieni le prestazioni desiderate dopo tutti i passaggi qui menzionati, puoi consultare le seguenti sezioni:

• Informazioni specifiche del bus di campo

• [Per esperti] – Strumenti e argomenti aggiuntivi

• Controlla il Send Time / Recv Time valori nella pagina di stato EtherCAT.

  • Una CPU x64 con processore Intel Core i7 e un buon adattatore dovrebbe avere meno di 10μs.

  • I processori ARM con chip integrato avranno ~50μs o più.

  

• Controlla il Send Time / Recv Time valori nella pagina di stato PROFINET.

  • Una CPU x64 con processore Intel Core i7 e un buon adattatore dovrebbe avere meno di 10μs.

  • I processori ARM con chip integrato avranno ~50μs o più.

  

• Per ordinare le priorità e gli IRQ richiesti, è possibile utilizzare i comandi della shell PLC irq-list E irq-set-prio.

  • Questi comandi utilizzano le normali priorità Linux e non le priorità IEC.

  • Questa ottimizzazione non è possibile in CODESYS Virtual Control SL, ma piuttosto sul sistema host.

• Utilizzare un adattatore di rete separato per i dispositivi.

• Per ulteriori informazioni, vedere:

  • EtherCAT

  • PROFINET

  • Ethernet/IP

  • CANbus, CANopen

• KernelShark/traccia del kernel

  • Questo è il programma da scegliere se ritieni che la causa dei tuoi problemi di prestazioni sia la pianificazione. Con l'aiuto della "traccia del kernel", puoi vedere se la tua attività viene interrotta da un'altra attività, da un altro servizio o da un'interruzione.

    • trace-cmd record -p function

    • È possibile utilizzare KernelShark per esaminare il file generato trace.dat file.

  • In generale, i problemi di pianificazione possono essere suddivisi in due categorie:

    • Sostituzione/prelazione

      • Se l'interruzione o l'attività che impedisce l'esecuzione non è necessaria, disabilitala.

      • Aumenta la priorità del tuo compito o riduci la priorità degli altri.

      • Passa a un core della CPU diverso.

      Importante

      Verificare l'efficacia delle modifiche utilizzando i programmi descritti nel capitolo precedente.

    • Tempo di esecuzione

      Vedi sotto: "Traccia delle funzioni del kernel"

• Traccia della funzione del kernel

  • Se determini che il tempo di esecuzione del codice è troppo elevato, puoi utilizzare questo strumento per individuare il problema.

  • Se la funzione con un tempo di esecuzione troppo elevato è nel tuo codice, devi ottimizzarla.

  • Se nel kernel è presente una funzione con un tempo di esecuzione troppo elevato, è possibile provare a ottenere la funzionalità desiderata con un'altra funzione del kernel. In alternativa, potresti anche passare i parametri di configurazione al driver del kernel per ridurre il tempo di esecuzione.

  • Se nessuna di queste opzioni risolve il problema, probabilmente dovrai utilizzare hardware più potente.

Osserva i seguenti punti e verifica se sono o meno lo strumento corretto per raggiungere i tuoi obiettivi di performance:

• PREEMPT_FULL

• isolcpu

• rcu_nocbs

• rcu_nocb_poll

• nosoftlockup

• disabilitazione del bilanciamento irq

• kernel.sched_rt_runtime_us