Perché scegliere un kernel a bassa latenza su uno generico o in tempo reale?

93

Dopo aver installato Ubuntu Studio 12.04, ho scoperto che utilizza un kernel a bassa latenza. Ho cercato perché e come tornare a uno in tempo reale o generico. Ma sembra che questa parte di Linux non sia stata coperta così tanto.

Q: Perché scegliere un kernel a bassa latenza su uno generico o in tempo reale?

PS: ho già letto le risposte da questa domanda e questo post.

    
posta Starx 28.04.2012 - 05:09

4 risposte

55
  

Queste sono alcune semplici linee guida fornite per aiutarti a capire quale   kernel e in quale ordine, dovresti testare per adattarlo al caso d'uso.

     
  • Se non si richiede una bassa latenza per il proprio sistema, si prega di utilizzare il kernel -generico
  •   
  • Se hai bisogno di un sistema a bassa latenza (ad esempio per la registrazione audio), utilizza il kernel -preempt come prima scelta. Questo riduce la latenza   ma non sacrifica le funzionalità di risparmio energetico. È disponibile solo per   Sistemi a 64 bit (chiamato anche amd64).
  •   
  • Se il kernel -preempt non fornisce una latenza sufficientemente bassa per le tue esigenze (o hai un sistema a 32 bit) allora dovresti provare   -lowlatency kernel.
  •   
  • Se il kernel -lowlatency non è abbastanza, dovresti provare il kernel -rt
  •   
  • Se il kernel -rt non è abbastanza stabile per te allora dovresti provare il kernel -realtime
  •   

link

Credo dipenda da cosa farai con la tua distro in studio. Per alcuni utenti, generico andrà bene, per altri no.

DISCORSO DI LIBERTA ', prova a leggere questo link: link

    
risposta data ubuntu fan 28.04.2012 - 05:21
45

Sono l'autore del blogpost collegato da fan di ubuntu: link

Quel post sul blog non presenta alcun fatto, è solo la teoria . Funziona in realtà: il processore si "ferma" più frequentemente per vedere se ci sono processi che richiedono attenzione immediata. Ciò significa che quei processi saranno eseguiti prima degli altri, quindi non salterai i frame durante la codifica, o avrai enormi tempi di ritardo tra clic del mouse e morti nemiche. Ciò non significa che tutti i processi finiranno prima: in realtà la CPU sta perdendo una parte maggiore del proprio tempo decidendo quale processo verrà eseguito successivamente, e facendo il cambio di contesto. Quindi il tempo di esecuzione totale è più lungo, ed è per questo che nessuno esegue un kernel preempibile su server web o macchine di database. Ma un kernel pre-300Hz (o anche 1000Hz) è il migliore per i server di giochi.

Ma al giorno d'oggi i processori hanno molti core, quindi quando ci sono pochi processi che richiedono attenzione possono essere facilmente allocati su un core differente piuttosto che aspettare che un core lo prenda.

(StackExchange mi richiede riferimenti / esperienza personale: sono un ingegnere elettronico, un noobgamer assetato di sangue che gestisce diversi server di gioco al link ).

Quindi, come regola generale, direi: se il tuo processore è un potente quad-core ad alta frequenza che scricchiola il numero E di solito non apri tonnellate di pagine web durante la codifica / decodifica / gioco (huh) , si potrebbe semplicemente provare il kernel generico (o i686, o amd64 se esiste) e avere il massimo throughput possibile (cioè, il raw-crunch che il processore è in grado di fare). Se riscontri problemi (in realtà dovrebbero essere minori) o la tua macchina è leggermente meno potente della fascia più alta del mercato, prova il valore -preempt.

Se ti trovi su una macchina di fascia bassa che ha solo uno o due core, prova con -lowlatency. Puoi anche provare il -realtime, ma scoprirai che tende a bloccare i processi fino a quando quelli "in tempo reale" hanno finito il loro lavoro. Credo che il kernel in tempo reale non sia quello "vanilla", ma abbia applicato la patch CONFIG_PREEMPT_RT. Penso che i kernel in tempo reale siano solo per coloro che devono creare una singola applicazione su sistemi embedded, quindi gli utenti desktop usuali non dovrebbero avere reali benefici perché di solito gestiscono un numero discreto di applicazioni contemporaneamente.

Infine, le opzioni del kernel più rilevanti se vuoi ricompilare il tuo kernel per avere un desktop a bassa latenza sono:

PREEMPT=y

e

CONFIG_1000_HZ=y

Per aggiungere un po 'di risparmio energetico puoi controllare questo:

CONFIG_NO_HZ=y
    
risposta data seven 24.10.2012 - 22:27
6

BTW: preemt-, lowlatency o il kernel rt non renderanno più veloce il tuo sistema. Sono leggermente più lenti rispetto al kernel generico.

    
risposta data gemue2010 28.04.2012 - 05:53
2

Dal documento citato sopra ( link )

  1. un sistema soft real-time fornirà una latenza media ridotta ma non un tempo di risposta massimo garantito.
  2. Un sistema hardware in tempo reale soddisfa le scadenze desiderate in qualsiasi momento (100%), anche in caso di carico del sistema peggiore.
  3. Secondo Yaghmour [4], "Il tempo reale si occupa delle garanzie, non della velocità non elaborata."

L'articolo dice che per il kernel duro in tempo reale senza responsività o il tempo limite è la proprietà più importante, quindi a volte ritardano le attività non critiche che portano al ritardo, ma per il kernel a bassa latenza o altri soft in tempo reale tentano di ridurre la latenza generale che aiuta nella maggior parte dei casi. A causa della ridotta latenza, il sistema sembra essere veloce. Leggi attentamente l'articolo.

    
risposta data Mayank Suman 17.08.2014 - 07:34

Leggi altre domande sui tag