Ottimizzazione delle prestazioni

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

• Se utilizzi bus di campo basati su Ethernet per il dispositivo di destinazione, utilizza un adattatore fisico per essi. Non utilizzate

• Utilizza un kernel in tempo reale.

  Importante

  Per il funzionamento in tempo reale su Linux, usa la patch Realtime PREEMPT. L'uso di un kernel a bassa latenza non è sufficiente perché non garantisce proprietà deterministiche in tempo

  Per ulteriori informazioni, vedere quanto segue:

  • https://realtime-linux.org/getting-started-with-preempt_rt-guide/

  • https://wiki.linuxfoundation.org/realtime/documentation/technical_basics/start

  Molte delle seguenti impostazioni di sistema possono anche essere configurate direttamente utilizzando PLCShell tramite il sistema runtime o direttamente tramite il file di configurazione del sistema runtime. Alcune impostazioni di sistema non persisteranno dopo il riavvio del sistema. Inserendo le impostazioni nel file di configurazione, le impostazioni verranno ripristinate automaticamente all'avvio del sistema di runtime. L'esecuzione del comando PLCShell corrispondente aggiunge anche le rispettive voci al file di configurazione

  Comando PLCShell	Inserimento del file di configurazione	Funzione
  rt-get scaling_governor/kernelinfo/hyperthreading/throttling/napi <device>		Restituisce informazioni sulle impostazioni di sistema Esempio 3. Esempio rt-get scaling_governor Visualizza i regolatori di scalabilità disponibili e restituisce il regolatore di scala configurato per il core
  rt-set scaling_governor <cpu_index> <value>	[CmpLinuxRTDiag] ScalingGovernor.CPU0=performance	Imposta il regolatore di scala sull'opzione specificata per core specifici o tutti i core Esempio 4. Esempio set scaling_governor all performance
  rt-set hyperthreading <state>	[CmpLinuxRTDiag] Hyperthreading=off	Attiva/disattiva l'Hyperthreading
  rt-set throttling <state>	[CmpLinuxRTDiag] Throttling=off	Attiva/disattiva il throttling
  rt-set napi <device> <state>	[CmpLinuxRTDiag] Napi=eno1	Abilita o disabilita la NAPI con thread per l'adattatore di rete
  rt-clear-settings		Elimina tutto rt-set impostazioni dal file di configurazione
  rt-marker-set <taskname> <threshold>	[CmpLinuxRTDiag] TraceMarker.TaskName=MainTask TraceMarker.ThresholdUs=100 [SysTask] Linux.MeasureInterval=1	Abilita la scrittura di un marker di traccia del kernel per l'attività specificata quando il jitter supera il limite specificato. Disponibile solo se il runtime viene eseguito come utente root
  rt-marker-disable		Disattiva il kernel trace marker
  rt-marker-get		Specifica il nome dell'attività configurato per il marker di traccia del kernel e il limite di jitter
  irq-list		Elenca tutti gli IRQ disponibili, le relative priorità e affinità sul sistema
  irq-set-prio <no | device> <priority>	[CmpLinuxInterrupt] Interrupt.1.Priority=51 Interrupt.1.Device=eno1	Sets the priority of interrupts specified either by number <no> or device <device> to the desired value
  irq-set-affinity <no | device> <bitmask>	[CmpLinuxInterrupt] Interrupt.1.Affinity=128 Interrupt.1.Device=eno1	Sets the core affinity of the interrupt specified either by number <no> or device <device> to the desired bitmask
  irq-clear-settings		Elimina tutto irq sets impostazioni dal file di configurazione

  Per richieste in tempo reale, è necessario utilizzare il kernel RT preempt (https://wiki.linuxfoundation.org/realtime/documentation/start) per il tuo sistema Linux. Nel caso delle distribuzioni Debian e Ubuntu, troverai un kernel RT come pacchetto che puoi installare facilmente usando apt comando. Per ulteriori informazioni, consulta il manuale della tua distribuzione.

  • Sui sistemi Debian

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

  • Usa il uname -a comando, ad esempio, per verificare quale kernel stai usando.

• Evita di utilizzare un gestore Windows, 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.

• Crea un'applicazione di test 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.

• Verificate che il kernel in tempo reale sia realmente utilizzato.

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

  • Se hai una versione precedente, puoi testarla direttamente sulla riga di comando con uname -a comando.

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

• È possibile utilizzare i test del passaggio precedente Configurazione del CODESYS sistema di runtime 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 6. Mappatura delle priorità delle attività IEC e delle priorità dei thread Linux:

  Priorità del compito IEC	Priorità di runtime	Priorità Linux
  --	0	88 (SCHED_FIFO)
  --	31	57 (SCHED_FIFO)
  0 (massima priorità in tempo reale)	32	56 (SCHED_FIFO)
  15 (priorità minima in tempo reale)	47	41 (SCHED_FIFO)
  16 (priorità non in tempo reale)	48	0 (SCHED_OTHER)
  31 (priorità non in tempo reale)	63	0 (SCHED_OTHER)
  --	64	0 (SCHED_OTHER)
  --	255	(SCHED_IDLE)
  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

  • Se scopri che la causa dei tuoi problemi di prestazioni ha qualcosa a che fare con la pianificazione, allora questo è il programma da scegliere. Con l'aiuto di «kernel trace», puoi verificare se la tua attività viene interrotta da un'altra attività, da un altro servizio o

    • 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

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

    • Tempo di esecuzione

      Vedi sotto «Kernel Function Trace»

• Trace della funzione del kernel

  • Se il tempo di elaborazione del codice è troppo elevato, puoi utilizzare questo strumento per trovare il problema.

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

  • Se la funzione con un tempo di esecuzione troppo elevato è nel kernel, puoi provare a ottenere la funzionalità desiderata con un'altra funzione del kernel. In alternativa, puoi 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.

Utilizza i seguenti punti per verificare se lo strumento giusto per raggiungere i tuoi obiettivi prestazionali è elencato con essi:

• PREEMPT_FULL

• isolcpu

• rcu_nocbs

• rcu_nocb_poll

• nosoftlockup

• disabilitazione del bilanciamento irq

• kernel.sched_rt_runtime_us