Ottimizzazioni player MPD Embedded (RaspBerry, HackBerry...)

Non sono riuscito ad approfondire perché la nas è in un'altra stanza e i miei adattatori powerline fanno pena
Riuscire a riprodurre continuamente più di 10 secondi è un problema. Domani vado a comprare degli altri adattatori e faccio altri test.

Comunque mi sembra ogni tanto ci sia qualche picco di mpd ma in generale rimane stabilmente molto basso. Non vedo picchi di altri processi, escludendo top, ssh e altro legato alla connessione via terminale.
Ora faccio subito un bel backup dell'SD, non penso modificherò molto altro.

Ciao, come ti dicevo l'altra volta, prova a portare a 0% la CPU con picchi per caricare i buffer. Ci fai l'elenco dei processi attuali con le loro priorità e ci mostri il contenuto di mpd.conf per favore? Ricordati di mettere a -20 la priorità di mpd. Inoltre, se usi il modulo snd_usb_audio, prova a cambiare il suo parametro nrpacks.

Ciao
Roberto

Menestrello ha scritto:

Menestrello ha scritto:Migliorato un pochino

Codice:



root@(none):~# free -m
            total      used      free    shared    buffers    cached
Mem:          815        70        745          0          3        31
-/+ buffers/cache:        35        779
Swap:            0          0          0


La Cpu in riproduzione si attesta intorno al 7/8% per mpd. Non ci sono altri processi evidenti.
Mi sembra buono, ora si deve ascoltare

robertopisa ha scritto:Ciao, come ti dicevo l'altra volta, prova a portare a 0% la CPU con picchi per caricare i buffer. Ci fai l'elenco dei processi attuali con le loro priorità e ci mostri il contenuto di mpd.conf per favore? Ricordati di mettere a -20 la priorità di mpd.

Ciao
Roberto

Menestrello ha scritto:

La Cpu in riproduzione si attesta intorno al 7/8% per mpd. Non ci sono altri processi evidenti.
Mi sembra buono, ora si deve ascoltare

0% durante la riproduzione musicale la vedo dura
Domani faccio delle altre prove e ti dico; ora il collegamento di rete è pessimo, ho degli adattatori powerline indecenti .
Vista la discreta quantità di memoria libera, che ne dici se aumento di molto il buffer?

* se aumenti i buffer nella misura giusta, e
* se dai priorità -20 solo a mpd e priorità -18 agli altri processi che avevano -20 (in modo che solo mpd abbia priorità massima),
=> puoi ottenere 0% CPU (tranne i picchi di mpd per ricaricare i buffer e del sistema per monitorare i trasferimenti dalla rete) perché lavora soprattutto la parte hw del driver usb che trasferisce i dati dal buffer alla porta USB senza impegnare la CPU (probabilmente devi cambiare anche il parametro nrpacks). Feci così con il mio Synology quest'estate.

Menestrello ha scritto:
0% durante la riproduzione musicale la vedo dura
Domani faccio delle altre prove e ti dico; ora il collegamento di rete è pessimo, ho degli adattatori powerline indecenti .
Vista la discreta quantità di memoria libera, che ne dici se aumento di molto il buffer?

Cambiare la priorità lo vedo fattibile. Ottimizzare nrpacks e altri parametri è più difficile, non conosco la parte hardware di questi mini computer e spesso vedo che i trasferimenti dati sono affidati alla cpu.
La stessa ethernet non usa il dma :-\
Vediamo sin dove si arriva

Per utilizzare il power button se non ricordo male ho installato il supporto ACPI tramite i pacchetti acpid e acpi-support-base.
A me il comando free -m mi da';

Codice:


          total      used      free    shared    buffers    cached
Mem:          846        55        790          0          7        29
-/+ buffers/cache:        19        827
Swap:            0          0          0


Menestrello ha scritto:La stessa ethernet non usa il dma :-\

Buttalo

Ottenere 0% la vedo molto dura...

Riguardo al comando nrpacks..è obsoleto...
http://ubuntuforums.org/showthread.php?t=1608913

robertopisa ha scritto:

Menestrello ha scritto:La stessa ethernet non usa il dma :-\

Buttalo

No dai!
Mi sembra di aver letto a proposito del driver ethernet che non usa il driver DMA per via della dimensione del pacchetto Ethernet, più piccolo delle dimensioni minime del frame dma. O qualcosa del genere. Magari domani me lo rileggo meglio

In ogni caso stasera ho fatto un breve test e con il comando top vedo pochi processi attivi e mpd con cpu decisamente bassa, molto meno del 7% dell'ultima volta. Ho cambiato la dimensione del buffer aumentandola parecchio, vista la quantità di memoria libera.
Siamo scesi allo 0-1-2% con qualche picco quando ricrea il buffer. Mi sembra buono come risultato
Comunque se ci vediamo da Federico porto con me il piccolo, non ho però un trasporto USB da provare.

C'è un metodo diverso dal comando top per fare un minimo di profiling dei processi?Che magari scriva su file così posso riportare i risultati qui e ne discutiamo?

@francoiacc: mi puoi di cosa hai compilato e eventualmente mandarmi il tuo config? Non capisco come fai ad avere tutta quella memoria libera, anche se ho una mezza idea.

C'è anche il comando ps, provalo con l'opzione ps axjf oppure

ps -eo pid,tid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm

questo qui sopra l'ho preso di pacca dal manuale di ps (man ps ).

se ti serve un file puoi redirigere l'output di ps (e di tutto quello che vuoi) su un file, col semplice segno >

Ad esempio ps -axjf> /home/federico/Scrivania/file2.txt

fritznet ha scritto:C'è anche il comando ps, provalo con l'opzione ps axjf oppure

ps -eo pid,tid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm

questo qui sopra l'ho preso di pacca dal manuale di ps (man ps ).

se ti serve un file puoi redirigere l'output di ps (e di tutto quello che vuoi) su un file, col semplice segno >

Ad esempio ps -axjf> /home/federico/Scrivania/file2.txt

ps -eo pid,tid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm

urca


No dai, il simbolo > no... lo so dal 1989 quando usavo il system V

Eee ma viene proprio da lì, credo

Funziona, perchè no?

fritznet ha scritto:Eee ma viene proprio da lì, credo

Funziona, perchè no?

Nel senso che conosco cosa fa il simbolo > dal lontano 1989

Però ps esegue uno snapshot dei processi; sarebbe interessante vedere nell'arco di 1/2 minuti cosa succede.
Quindi non solo vedere l'elenco e l'uso della cpu per i processi, ma come si evolve nell'arco del tempo.
Magari uno script che ogno mezzo secondo esegue ps e accoda su file però poi lo vedo di difficile lettura il risultato.

Menestrello ha scritto:
...
:lol:Nel senso che conosco cosa fa il simbolo > dal lontano 1989
...

Ah, ok, scusa ho frainteso

fritznet ha scritto:

Menestrello ha scritto:
...
:lol:Nel senso che conosco cosa fa il simbolo > dal lontano 1989
...

Ah, ok, scusa ho frainteso

Figurati, è che a quest'ora sono molto sintetico
E forse non solo a quest'ora

Conosco quei post, c'è scritto che è obsoleto usare nrpacks=1 per avere bassa latenza perché ci pensano i driver delle schede.

kurt10 ha scritto:Ottenere 0% la vedo molto dura...

Riguardo al comando nrpacks..è obsoleto...
http://ubuntuforums.org/showthread.php?t=1608913

Noi invece vogliamo aumentare quei parametri (insieme a buffer_time e period_time di alsa) per lo scopo contrario, avere il massimo buffer possibile. Per ascoltare musica non serve avere bassa latenza, perché non stiamo usando il computer come digital audio workstation o per spedire l'audio di un film sulla scheda audio.

Vogliamo massimizzare i buffer per portare a 0% il cpu time se non quando ricarica i buffer o gestisce le poche attività del SO: tutto il resto va a caricare il direct memory access (DMA) attraverso il sotto-sistema di I/O. Come puoi leggere, Menestrello è già sceso tra lo 0% e il 2%... ci si può arrivare, l'ho già fatto con il mio Synology.

Ottimo, sei sulla strada giusta... in realtà ricorda che devi ottimizzare "il sistema" anche a livello hw: dovresti integrare hackberry, trasporto USB e DAC, utilizzando connettori o cavi di max 5-6 cm, e alimentazione dedicata. A quel punto finisci di ottimizzare i parametri del SO perché dovresti fare le prove man mano e vedere come si sente.

In fondo top (o htop) sono semplici e si trovano sui sistemi e non perturbano troppo il sistema quando misurano. Esistono altri tool ma che credo che consumino CPU... prova a vedere in questo sito (e ignora i consigli per real time e low latency, tanto a noi non servono per produrre musica ma per ascoltarla):

http://wiki.linuxmusicians.com/doku.php?id=system_configuration

Da Federico abbiamo tutti hiface1 come trasporto (oppure la mia scheda rossa), per cui ti conviene installare i suoi driver Linux, non dovresti avere problemi a compilarli sotto Debian:

https://github.com/panicking/snd-usb-asyncaudio/wiki

Menestrello ha scritto:In ogni caso stasera ho fatto un breve test e con il comando top vedo pochi processi attivi e mpd con cpu decisamente bassa, molto meno del 7% dell'ultima volta. Ho cambiato la dimensione del buffer aumentandola parecchio, vista la quantità di memoria libera.
Siamo scesi allo 0-1-2% con qualche picco quando ricrea il buffer. Mi sembra buono come risultato
Comunque se ci vediamo da Federico porto con me il piccolo, non ho però un trasporto USB da provare.

C'è un metodo diverso dal comando top per fare un minimo di profiling dei processi?Che magari scriva su file così posso riportare i risultati qui e ne discutiamo?

@francoiacc: mi puoi di cosa hai compilato e eventualmente mandarmi il tuo config? Non capisco come fai ad avere tutta quella memoria libera, anche se ho una mezza idea.

Menestrello ha scritto:Magari uno script che ogno mezzo secondo esegue ps e accoda su file però poi lo vedo di difficile lettura il risultato.

Se t'interessa solo mpd alla fine del comando puoi aggiungere "| grep mpd | grep -v grep".
Puoi provare anche con vmstat 1 1000, però non credo sia possibile agganciarlo a un solo processo.

Ora non ho molto tempo per sperimentare, quindi mi sono limitato a fare uno screen shot



Mpd viaggia intorno a 1.5-1.6 con picchi a 3.7% e 4.8%

Mi sembra anche di notare che tra i vari demoni ci sono un po' di cose che si possono rimuovere, anche se non usano cpu.

Configurazione di mpd:

Codice:

audio_buffer_size              "65535"
buffer_before_play              "15%"


Dimenticavo: ancora non ho capito come fare in modo che all'avvio mpd abbia priorità -20 e gli altri -19
Per ora faccio il renice via ssh

sshd usa CPU ma lo puoi uccidere (non rimuovere)
Ma hai altri parametri in mpd.conf?
Per renice, ci vuole uno script, lo scriviamo insieme quando ci vediamo.
-R

Menestrello ha scritto:Mpd viaggia intorno a 1.5-1.6 con picchi a 3.7% e 4.8%

Mi sembra anche di notare che tra i vari demoni ci sono un po' di cose che si possono rimuovere, anche se non usano cpu.

Configurazione di mpd:

Codice:

audio_buffer_size              "65535"
buffer_before_play              "15%"


Dimenticavo: ancora non ho capito come fare in modo che all'avvio mpd abbia priorità -20 e gli altri -19
Per ora faccio il renice via ssh

robertopisa ha scritto:sshd usa CPU ma lo puoi uccidere (non rimuovere)
Ma hai altri parametri in mpd.conf?
Per renice, ci vuole uno script, lo scriviamo insieme quando ci vediamo.
-R

Roberto,
se uccido sshd non mi collego più alla macchina
Gli altri parametri in mpd.conf:

Codice:



audio_output {
        type            "alsa"
        name            "USBDAC"
        device          "plughw:2,0"    # plughw:2,0
        mixer_type      "none"          #
#      mixer_device    "default"     
        use_mmap        "yes"         
        replay_gain_handler    "none"
        auto_resample  "no"
        auto_channels  "no"
        auto_format    "no"

        period_time    "524288"
        buffer_time    "2097152"
}


Il supporto acpid è installato ma non succede nulla.
se provo ad eseguire /etc/init.d/acpid ottengo

Codice:

root@(none):/etc/init.d# acpid
RTNETLINK1 answers: No such file or directory
acpid: error talking to the kernel via netlink


Meno male che ti diverti facendo tutto questo, perchè per semplicità un vecchio nb o un nuovo netbook con mpdpuppy ti creava meno problemi.

Imparare ad ottimizzare linux/mpd è comunque un bene.


Ho raddoppiato il buffer e ora la CPU è praticamente a zero dopo i primi 5/8 secondi.

Peccato che non si possa dire lo stesso durante la riproduzione dei file 24/96

Mi sa che si deve passare a cpu più performanti. urge provare una nuova scheda

Menestrello ha scritto:

Codice:

root@(none):/etc/init.d# acpid
RTNETLINK1 answers: No such file or directory
acpid: error talking to the kernel via netlink


Non é che hai disabilitato anche il supporto Netlink ricompilando il kernel?

O ciccio uccidi sshd dopo che hai finito, per ascoltare, tanto,riparte con boot

Di solito gli script in etc init.d prendono start stop o restart come argomento

Menestrello ha scritto:

robertopisa ha scritto:sshd usa CPU ma lo puoi uccidere (non rimuovere)
Ma hai altri parametri in mpd.conf?
Per renice, ci vuole uno script, lo scriviamo insieme quando ci vediamo.
-R

Roberto,
se uccido sshd non mi collego più alla macchina
Gli altri parametri in mpd.conf:

Codice:



audio_output {
        type            "alsa"
        name            "USBDAC"
        device          "plughw:2,0"    # plughw:2,0
        mixer_type      "none"          #
#      mixer_device    "default"     
        use_mmap        "yes"         
        replay_gain_handler    "none"
        auto_resample  "no"
        auto_channels  "no"
        auto_format    "no"

        period_time    "524288"
        buffer_time    "2097152"
}


Il supporto acpid è installato ma non succede nulla.
se provo ad eseguire /etc/init.d/acpid ottengo

Codice:

root@(none):/etc/init.d# acpid
RTNETLINK1 answers: No such file or directory
acpid: error talking to the kernel via netlink