Nuova versione per il kernel di Munny

di saguan67 il 08.11.11, 18:24:51

(Ciao Felix... )

Previa autorizzazione da parte di Munny (detto il guru dei kernel musicali... ) posto il contenuto del mp che mi ha inviato su ubuntu-it:

Ti scrivo perchè ho compilato un nuovo kernel 3.0 (3.0.13 per la precisione, l'ultimo dell'11.10), con una nuova patch, che si chiama BFS (Brain f**k Scheduler) scritta da Con Kolivas, che promette di abbassare notevolmente la latenza del sistema.
A me sembra dare ottimi risultati rispetto al kernel lowlatency, ma mi piacerebbe sapere anche l'opinione di qualcun'altro.
Al momento l'ho compilato solo per il 64 bit, se funziona come sembra poi lo compilerò anche per il 32 bit.

Se ti va di provarlo, il link per scaricare i pacchetti come l'altra volta è il seguente:

http://www.mediafire.com/?vv6app3elqm79a3

Le istruzioni sono sempre uguali, quindi scompatti l'archivio e metti i 3 file che finiscono con .deb in una cartella, poi li installi con il comando "sudo dpkg -i ....." al posto dei puntini metti i nomi dei 3 pacchetti.
All'avvio del PC ricordati di selezionare dal menu di grub il kernel giusto, il nome di questo finisce con 3.0.13-bfs... con il bfs finale.
Se lo provi fammi sapere come va... a me sembra che dia mooooolti meno xruns a latenze basse... 32 o 64...

Ciao, Munny

Forse questo può risolvere il problema di Martjan???? (il precedente kernel di munny mi aveva risolto i problemi con la Fast Track Ultra...) Io intanto ci provo subito....

di el_Felix il 08.11.11, 19:48:31

La cosa è buona!
ho quasi voglia di provarlo
probabilmente lo proverò quando passerò a Precise, dato che a quel punto ci sarà il kernel 3 già di "default" e magari essendo passato un po' di tempo dal suo rilascio potrebbe essere migliorato ancora di più!

Mentre aspettiamo che Munny ci venga a trovare qui sul forum, invito ancora una volta il buon martjan a provarci ora ha anche un motivo in più!

di saguan67 il 10.11.11, 16:46:22

(QUESTO E' UN BREVE RIASSUNTO DEGLI MP CHE HO SCAMBIATO CON MUNNY. SPERANDO CHE PPOSSA ESSERE UTILE AI PIU'...)

Allora; ho installato il nuovo kernel e sembrerebbe che gli xrun siano calati (non moltissimo comunque, ma questo dipende penso dal pc e non da altro...)

Per quanto riguarda la stabilità, facendo editing con ardour sul brano di senbee, ardour crasha. Facendo le medesime operazioni sul precedente kernel preempt (sempre fornitomi da munny) ardour tira avanti tranquillamente.

Le prove le sto facendo su un Hp AMD_64 dual core - 2 GB ram - 3.20 GHz - porte USB 2.1. -scheda grafica Nvidia Gforce 2800 (credo) - scheda audio FAST TRACK ULTRA, collegata via USB.

IMPOSTAZIONI JACK: Priorità: 89 - campionamento: 44100 - fotogrammi/periodo: 256 - periodo/buffer: 3.

Tra i vari suggerimenti per risparmiare risorse c'é quello di eliminare certi servizi che per "fare musica" non servirebbero. Quali? Come? Network manager lo spegnevo già, compiz pure. Ma gli altri non li conosco ed ho paura di combinare guai...

Poi c'é il discorso di controllare che l'irq della porta usb non sia condiviso anche da altri dispositivi. Come controllo ed (eventualmente) come risolvo?

di martjan il 10.11.11, 17:55:34

grande munny!!
grazie anche a te saguan, come sempre...

di saguan67 il 10.11.11, 17:59:20

non c'é di che. Provaci e facci sapere!!!! Il laboratorio musicale ha bisogno di violinista provvisto di ardour

di munny il 10.11.11, 18:13:34

Allora andiamo con ordine:

1) Il crash di Ardour, per quanto strano sembrerebbe essere legato alla patch del kernel, il kernel è patchato con uno Scheduler dei processi diverso rispetto a quello standard, per quanto sembrerebbe strano potrebbe questo fare qualche macello con certe operazioni di ardour. Puoi postare il messaggio di errore di Ardour al momento del crash? Lancia Ardour da terminale, dopo il crash si dovrebbe vedere l'errore dettagliato nel terminale.

2) Per quanto riguarda i settaggi i piccoli consigli li ripeto qua:
- Essere sicuri che le frequenze di tutti i core delle cpu siano impostate su "performance", di default i kernel di ubuntu (ed anche i miei di conseguenza) impostano la politica della frequenza della cpu su "ondemand", ciò significa che la frequenza viene aumentata solo quando serve. Questo però per le applicazioni audio non è ottimo (sopratutto per le cpu più vecchiotte) in quanto al momento dello switch di frequenza, si genera latenza che si traduce in xruns su jack. Per modificare tale frequenza io conosco il pacchetto cpufrequtils, credo esistano anche piccole applet grafiche ma variano in base al Desktop utilizzato e non conosco cosa c'è su gnome.
Se si vuole usare cpufrequtils basta installarlo, e poi modificare lo script di avvio, che di default imposta le cpu su "ondemand", oppure di volta in volta lanciare i comandi per impostare
Installazione:

Codice:


sudo apt-get install cpufrequtils

per configurare cpufrequtils e mettere performance all'avvio editare questo file con i privilegi di amministratore:

Codice:


/etc/init.d/cpufrequtils

e sostituire la riga

Codice:


GOVERNOR="ondemand"

con

Codice:


GOVERNOR="performance"

-Per quanto riguarda i servizi da eliminare non c'è una regola aurea da seguire... diciamo che tendenzialmente si tende ad eliminare i servizi inutili che possono in qualche modo appesantire o rubare cicli cpu... ma tieni conto che per esperienza demoni come cups sono innocui, se hai il bluetooth quello si potrebbe spegnere, network manager di per se non da problemi, a volte invece sono i driver wireless che potrebbero causare problemi. Compiz se il pc sopratutto è poco potente fai bene a spegnerlo, inoltre io non ho mai avuto problemi con le schede nvidia ma alcuni dicono che con i driver open source nouveau invece che quelli proprietari riescano ad avere un sistema più stabile. Inoltre se hai qualche servizio di ricerca che gira in background sarebbe utile spegnerlo, su kde ad esempio c'è Nepomuk + Strigi che indicizza i file del'hard disk ed è pesantuccio. Se mi venisse in mente qualcos'altro lo aggiungerò all'elenco.

- Per controllare che gli interrupt del sistema siano , posta qui il risultato di questo comando, mi raccomando con la scheda collegata ed accesa:

Codice:


cat /proc/interrupts

- Su computer meno potenti ho notato che jack2 (se hai kxstudio dovresti avere sicuramente questo), mi "sembra" che jack2 funzioni meglio in modalità Sincrona, per farlo partire in questa modalità devi aggiungere al comando jackd l'opzione -S, fai una prova e vedi se la situazione migliora...

- la priorità ad 89, dipende da come è configurato il sistema, ma tendenzialmente mi sembrerebbe sia troppo alta... di solito a quei livelli ci stanno il timer di sistema, la tastiera ed il mouse e l'hardware vero e proprio, senza entrare nel dettaglio prova anche priorità intorno a 60 oppure 70

noltre, per verificare che non ci siano ancora quei bug di cui ti parlavo nell'MP sul driver della Fast Track Ultra, fai questa prova:
fai partire jack e tieni aperto il log dei messaggi di qjackctl senza suonare nulla o fare nulla... se ti viene dato un xrun ogni tot secondi (l'intervallo di tempo varia a seconda delle configurazioni di jack) ma l'intervallo è regolare (ad esempio ogni 1:30 secondi), alora probabilmente non hanno ancora risolto il bug i ragazzi di ALSA

Fammi sapere,
Munny

questo é l'output del comando cat /proc/interrupts:

Codice:


          CPU0      CPU1     
  0:        119          2  IO-APIC-edge      timer
  1:          0        19  IO-APIC-edge      i8042
  7:          1          0  IO-APIC-edge   
  8:          0          1  IO-APIC-edge      rtc0
  9:          0          0  IO-APIC-fasteoi  acpi
12:      5410        352  IO-APIC-edge      i8042
14:          0        205  IO-APIC-edge      pata_amd
15:          0          0  IO-APIC-edge      pata_amd
16:          5        301  IO-APIC-fasteoi  nouveau
19:          0          5  IO-APIC-fasteoi  firewire_ohci
21:          0          0  IO-APIC-fasteoi  ohci_hcd:usb2
22:    200606      9270  IO-APIC-fasteoi  ehci_hcd:usb1, hda_intel
23:      3021      4637  IO-APIC-fasteoi  sata_nv, sata_nv
43:        381        92  PCI-MSI-edge      eth0
NMI:          0          0  Non-maskable interrupts
LOC:      50844    200194  Local timer interrupts
SPU:          0          0  Spurious interrupts
PMI:          0          0  Performance monitoring interrupts
IWI:          0          0  IRQ work interrupts
RES:      10458      61855  Rescheduling interrupts
CAL:        334        228  Function call interrupts
TLB:        512        381  TLB shootdowns
TRM:          0          0  Thermal event interrupts
THR:          0          0  Threshold APIC interrupts
MCE:          0          0  Machine check exceptions
MCP:          1          1  Machine check polls
ERR:          1
MIS:          0

Ciao Munny,

anchio ho Ardour che crasha ogni tanto, ora ho seguito i consigli del post e vediamo come va ..

del discorso degli interrupt non ci capisco una cippa .. ma credo che il mio pc sia ..la scheda audio è la ice1712 .. mi confermi che è ?

Codice:


rossano@rossano-record-studio:~$ cat /proc/interrupts
            CPU0      CPU1     
  0:        138          0  IO-APIC-edge      timer
  1:          2          0  IO-APIC-edge      i8042
  6:          3          0  IO-APIC-edge      floppy
  7:          0          0  IO-APIC-edge      parport0
  8:          0          0  IO-APIC-edge      rtc0
  9:          0          0  IO-APIC-fasteoi  acpi
  12:          4          0  IO-APIC-edge      i8042
  14:          0          0  IO-APIC-edge      pata_via
  15:      13194          0  IO-APIC-edge      pata_via
  16:    141374      1805  IO-APIC-fasteoi  via@pci:0000:01:00.0
  17:        348    126255  IO-APIC-fasteoi  ICE1712
  20:          0          0  IO-APIC-fasteoi  uhci_hcd:usb2
  21:      4021      58533  IO-APIC-fasteoi  ehci_hcd:usb1, uhci_hcd:usb4, sata_via
  22:      59778        511  IO-APIC-fasteoi  uhci_hcd:usb3
  23:      64834          0  IO-APIC-fasteoi  uhci_hcd:usb5, eth0
  28:          0          0  IO-APIC-fasteoi  ahci
  29:          0          0  IO-APIC-fasteoi  pata_jmicron
  64:        722        134  PCI-MSI-edge      hda_intel
NMI:          0          0  Non-maskable interrupts
LOC:    2500438    2477500  Local timer interrupts
SPU:          0          0  Spurious interrupts
PMI:          0          0  Performance monitoring interrupts
PND:          0          0  Performance pending work
RES:      27920      26547  Rescheduling interrupts
CAL:      21930        762  Function call interrupts
TLB:      3278      5958  TLB shootdowns
TRM:          0          0  Thermal event interrupts
THR:          0          0  Threshold APIC interrupts
MCE:          0          0  Machine check exceptions
MCP:          8          8  Machine check polls
ERR:          1
MIS:          0
rossano@rossano-record-studio:~$

di el_Felix il 11.11.11, 09:52:16

Ah hem...qui si sta facendo del crossposting?? avevamo parlato dell'ottimizzazione del sistema per la produzione audio già in un altro post, peraltro praticamente con gli stessi "consigli" e con quasi esclusivamente le stesse considerazioni. Devo mettere mano alla cartucciera?
ovviamente sto scherzando, però volendo si può continuare la discussione di là e lasciare questo post per le questioni legate esclusivamente al kernel di munny e alle sue caratteristiche: quelle di cui state parlato sono cose abbastanza generali che valgono su tutti i sistemi!
Per chi non lo ricordasse, il post è questo

di Rael il 12.11.11, 00:42:33

... meno male che c'è gatto Felix che ci riporta sulla retta via ..

di Rael il 20.11.11, 09:25:08

... ci sono notizie sul kernel di Munny a 32 bit?

di saguan67 il 20.11.11, 12:14:10

al momento non ne so nulla... sono in attesa anch'io...

di el_Felix il 20.11.11, 12:22:04

Ma perché non usate i sistemi a 64 bit? a meno che non abbiate 500 mb di ram non vedo un valido motivo per non usare il 64 bit

di Rael il 20.11.11, 12:46:17

Perchè sono un pivello!

I primi tempi che usavo Linux avevo letto da qualche parte che sui i 64 c'era qualche problema e ho sempre usato 32

........ ri installare tutto da capo non ne ho molta volgia ........ a meno che tu non mi dica che i 64 sono bug esenti

di saguan67 il 20.11.11, 13:39:25

Dunque, pare che i sistemi a 64 bit abbiano ancora qualche problemino (e non solo su linux) più che altro per i software/hardware pensati, ancora, per sistemi a 32 bit. Proprio la settimana scorsa sono andato in un negozio di strumenti musicali di Forlì (per via della "benedetta/maledetta" fast track ultra), e lì mi dicevano che ancora oggi molti preferiscono i sistemi a 32 bit...

Detto questo, sul pc fisso uso un sistema a 64 bit, mentre sul portatile devo per forza usare un 32. Sinceramente non noto particolari differenze (forse qualche stramaledetto xrun di meno sul 32 ?????)

di el_Felix il 20.11.11, 14:04:48

Ma dai, i 64bit sono il futuro! anzi, in realtà sono il presente...
il problema vero dei 64bit sono proprio tutte quelle persone che vanno in giro a sconsigliarlo perché "l'amico del cugino dice che effettivamente è meglio il 32bit"

Ok, siamo tutti d'accordo che:
- con hardware vecchiotto è più la perdita che il guadagno;
- a livello di prestazioni ANCORA non c'è grossa differenza;
- alcuni (ma ormai davvero pochissimi) programmi non girano sui 64bit NATIVAMENTE, ma ci sono moltissimi modi per farlo senza dover impazzire;
- alcune, ma davvero poche poche poche periferiche danno problemi sui sistemi a 64bit, ma io trovo che dovremmo abbandonare QUELLE periferiche e non i sistemi a 64bit.

Purtroppo, nei momenti di grosso cambiamento ci sono sempre incompatibilità, problemi, bug, qualche (neanche troppo) piccolo programma irriducibile che non si vuole aggiornare (basti pensare che programmi come Cubase e Pro Tools sono sbarcati al 64bit da poco su windows e su mac ancora non completamente) per non si sa quale ragione, eccetera. Ma finché noi che siamo gli utenti finali non decidiamo di utilizzare solo ed esclusivamente macchine che girano coi 64bit, i produttori di hardware e software continueranno a dare più attenzione ai prodotti pensati per il 32bit (che non hanno bisogno di riscritture o reimplementazioni) piuttosto che rifarli tutti per girare sui 64bit.
E, oltrettutto, il discorso che sulle prestazioni non c'è molta differenza è sempre legato al fatto che vogliamo stare "con un piede in due scarpe".
Molliamo sti 32bit che hanno fatto la storia, siamo d'accordo, ma che ormai sono antiquati, e cominciamo a utilizzare solo e soltanto i 64bit: senza questo tipo di atteggiamento staremmo ancora con le telescriventi e i sistemi a 8bit (o, probabilmente, avremmo ancora paura del fuoco e dei fulmini)

Rael, se non hai ancora sistemato l'installazione di Ubuntu 10.04, reinstalla tutto a 64bit, il futuro ti ringrazierà! (ok, sono un buffone )

di saguan67 il 20.11.11, 14:18:43

Oh, calma, calma! Non m'ero mica schierato!!! Ho semplicemente riportato quello che mi é stato riferito non dall'amica della cognata di una cugina, bensì da uno che (almeno sulla carta) dovrebbe capirci...

Per quanto riguarda lasciare i pc a 32 per passare a quelli a 64.. C'é sempre da fare i conti con le tasche, e c'è chi almeno per il momento deve accontentarsi di quello che passa il convento...

di el_Felix il 20.11.11, 14:32:41

No no ma mica mi riferivo a te/voi, semplicemente alle "voci che girano" che non hanno molto fondamento.
A prescindere dal capirci o meno, secondo me non è minimamente pensabile di dire ancora, nel 2011 "conviene che metti il 32bit, con il 64bit è più facile che ci sono problemi!", almeno riferendosi a macchine "normali" e non particolarmente datate o problematiche.

Il discorso tasche è un altro paio di maniche (bella battuta) ma già un pc del 2006 o giù di lì dovrebbe poter supportare senza problemi un sistema a 64bit, i processori supportavano già tali istruzioni credo. Poi certo c'è il fattore RAM, sotto a 1 Gb, 1Gb e mezzo non vale la pena usare sistemi a 64bit, questo è inconfutabile!

Comunque la pianto che siamo già ampiamente , e dato che siamo i due moderatori e l'amministratore del forum, questo non è certo un bell'esempio

di saguan67 il 20.11.11, 14:48:01

OT ma comunque...