Categoria: Benchmark

RaspberryPi overclocking e benchmark

 

Sul mostriciattolo da qualche tempo, ho messo mano al file config.txt, per aumentarne le prestazioni. L'overclock che ho fatto non è stato aggressivo, e riguarda cpu e sdram, mentre per la gpu ho lasciato l'opzione di default. Di defaul il RaspberryPi "gira" a :

 

  • CPU – 700MHz
  • RAM – 400MHz
  • GPU – 250MHz

 

prima di fare le modifiche è meglio fare un benchmark, giusto per avere dei dati da confrontare.

 

# apt-get install bc

# time echo "scale=3000;4*a(1)" | bc -l

 

come risultato ho ottenuto:

 

real    1m8.918s
user    1m8.440s
sys    0m0.000s

 

per effettuare l'overclock, bisogna mettere mano al file /boot/config.txt, che di default non esiste, quindi bisogna crearlo:

 

# nano /boot/config.txt

 

ed aggiungere, come nel mio caso:


arm_freq=800
sdram_freq=500
gpu_freq=250

 

quindi reboot, ed il benchmark successivo è stato:
 

real    1m0.384s
user    1m0.000s
sys    0m0.030s

 

quindi con un aumento del 14%

 

 

p.s: è inutile ricordare che non bisogna esagerare 🙂

 

enjoy 😉

Velocizzare boot e prestazioni su Debian Squeeze con e4rat 0.2.3

 

 

 

 

Un anno e mezzo fa circa avevo fatto una guida divisa in due parti, qua e qua, su come velocizzare il boot e le prestazioni su Debian Squeeze, a distanza di tempo ho provato anche la soluzione e4rat (Reducing Access Times), che promette di velocizzare il boot di ben 3 volte. Questo è un tool che si occupa della riallocazione dei blocchi dei programmi caricati all'avvio, e precaricare i programmi usati frequentemente. Questa è una guida semplice, che è fatta di 3 fasi:

 

  1. e4rat-collect – raccoglie informazione sui file caricati (default 120 secondi)
  2. e4rat-realloc – riallocazione files
  3. e4rat-preload – precaricamento programmi

 

Download ed installazione di e4rat_0.2.3_amd64.deb oppure e4rat_0.2.3_i386.deb

 

$ sudo nano /boot/grub/grub.cfg

 

e dopo ro quiet passare il parametro seguente al kernel:

 

init=/sbin/e4rat-collect

 

salvare e riavviare. Da questo momento si hanno 120 secondi per usare i programmi di proprio interesse, e nel contempo e4rat raccoglierà le informazioni in /var/lib/e4rat/startup.log. Se 120 secondi per qualcuno non sono abbastanza, si possono modificare editando il file /etc/e4rat.conf. Adesso bisogna andare a rimuovere il parametro precedente inserito, e poi:

 

$ sudo init 1

 

inserire password di root, e poi lanciare il comando:

 

# e4rat-realloc  /var/lib/e4rat/startup.log

 

una volta finita la reallocozione:

 

init 2

 

loggarsi ed inserire permanentemente il parametro e4rat-preload:

 

$ sudo nano /etc/default/grub

 

e modificare la stringa in questo modo:

 

GRUB_CMDLINE_LINUX_DEFAULT="init=/sbin/e4rat-preload"

 

salvare, aggiornare grub e riavviare:

 

$ sudo update-grub

$ sudo init 6

 

questo è tutto.

 

 

enjoy 😉

Iceweasel 10.0.2 VS Firefox 13

 

 

Chiaramente, essendo una versione superiore, vince Firefox 13, rispetto ad Iceweasel 10.0.2. I test eseguiti sono:

 

https://peacekeeper.futuremark.com/

https://www.webkit.org/perf/sunspider-0.9.1/sunspider-0.9.1/driver.html

 

 

                                                            Firefox 13.0a1 (24/02/2012)

 

 

                                                         Firefox 10.0.2

 

 

                                Firefox 13.0a1 (24/02/2012)                                                                   Firefox 10.0.2

  

 

 

                                   Firefox 13.0a1 (24/02/2012)                                                          Firefox 10.0.2

                                      

 

enjoy 😉

Scoprire limitazioni di banda (ISP) con Debian e Gnu/Linux

 

 

 

 

Per scoprire se il proprio ISP limita la banda, in ambienti Gnu/Linux si può utilizzare DiffProbe Shaper Module.

 

$ wget

$ tar xvf shaperprobe.tgz

$ cd shaperprobe

$ make

$ ./prober

 

il test dura un paio di minuti, e se tutto è andato bene, si avrà qualcosa di simile.

 

edmond@Debianbox:~/shaperprobe$ ./prober
DiffProbe release. January 2012.
Shaper Detection Module.

Connected to server 74.63.50.40.

Estimating capacity:
Upstream: 54 Kbps.
Downstream: 547 Kbps.

The measurement will last for about 2.5 minutes. Please wait.

Checking for traffic shapers:

Upstream: No shaper detected.
Median received rate: 112 Kbps.

Downstream: Burst size: 130-135 KB; Shaping rate: 373 Kbps.

For more information, visit:
 

 

enjoy 😉

Test velocità su Iceweasel Opera Epiphany Chromium

 

 

 

 

Confronto di velocità tra Chromium, Opera, Iceweasel, Epiphany, senza tener conto quindi di altre differenze come la sicurezza ecc ecc. I test sono stati eseguiti con questi strumenti, ed i risultati sono stati i seguenti:

 

Chromium 14.0.835.202

Score: 7046
Richards: 9856
DeltaBlue: 9290
Crypto: 13046
RayTrace: 8827
EarleyBoyer: 18382
RegExp: 1833
Splay: 2427

 

Iceweasel 7.0.1

 

Score: 3591
Richards: 5592
DeltaBlue: 3947
Crypto: 4103
RayTrace: 3179
EarleyBoyer: 3244
RegExp: 1480
Splay: 5574

 

Opera 11.52


Score: 2848
Richards: 2764
DeltaBlue: 1651
Crypto: 3280
RayTrace: 4184
EarleyBoyer: 3426
RegExp: 1212
Splay: 5843

 

Epiphany 3.0.4

 

Score: 2532
Richards: 2663
DeltaBlue: 2024
Crypto: 2907
RayTrace: 3474
EarleyBoyer: 3868
RegExp: 1137
Splay: 2784

 

Chromium risulta vincitore, doppiando Iceweasel…azz 🙁

 

enjoy 😉

Velocizzare boot e prestazioni su Debian Squeeze parte 2

 

 

Nella guida precedente ho iniziato a sperimentare la possibilità di velocizzare Debian Squeeze ed LMDE, partendo dalla fase di boot, fino ad arrivare in questa seconda parte ad aumentare, ove possibile, la reattività del sistema. Già con l'installazione di preload si cerca di aumentare la reattività dei programmi usati più spesso, ma per ottenere questo bisogna dare a preload alcune ore di utilizzo, affinche memorizzi le abitudini. Le modifiche successive io le ho testate sul mio sistema, senza problemi, ma ciò non toglie che è meglio stare attenti.

 

atime ed /etc/fstab:

la prima modifica riguarda  /etc/fstab e l'inserimento dell'opzione noatime e nodiratime. Linux di default tende a tenere traccia di tutto quello che si fà, non solo delle modifiche dei file, ma anche della solo lettura, e scrive tutto sul disco. Questo sicuramente è d'obbligo su un server, ma su un pc Desktop secondo me non è necessario. C'è da tenere conto che una minore scrittura, significa anche aumento della durata dell' hard disk. Quindi /etc/fstab dovrebbe essere così:

/dev/sdaxx    /    ext4    rw,noatime,nodiratime,errors=remount-ro    0    0

lo stesso discorso vale per la partizione di /home separata.

 

vm.swappiness:

un'altra modifica che si può fare riguarda /etc/sysctl.conf e cioè andare a modificare il file, ed inserire un valore  a vm.swappiness che andrà a dire al kernel se tenere tutto in Ram oppure nella cache su disco.  Oggi ci si ritrova ad avere tanta Ram che nemmeno si utilizza, quindi cerchiamo di sfruttarla. Di default questo valore in Debian è 60, e la modifica si può fare da 0 a 100, io ho optato per 20. Per chi ha un pc portatile, può essere utile diminuire la scrittura su disco, in quanto la durata della batteria ne gioverebbe.

# echo 'vm.swappiness=20' >> /etc/sysctl.conf

 

vm.vfs_cache_pressure:

anche questa opzione da inserire in /etc/sysctl.conf aiuta a velocizzare il sistema, il valore di default in Debian è 100, si può provare a dimezzarlo:

# echo 'vm.vfs_cache_pressure=50' >> /etc/sysctl.conf

 

per le mie esigenze queste opzioni vanno benissimo e mi ritrovo con un pc veloce e reattivo:

 

Boot=25 secondi circa

Halt=5 secondi circa

 

ps: in LMDE consiglio di rimuovere il mintMenu dal pannello, che è pesantissimo, ed aggiungere la classica Barra del menu di Gnome.

 

enjoy 😉

Velocizzare boot e prestazioni su Debian Squeeze parte 1

 

 

Questa guida si propone di rendere più veloce e performante Debian Squeeze, partendo dalla fase di boot. Allo stesso tempo ho voluto provare questi stessi passi anche su LMDE che di default, a mio avviso, è più lenta di Debian Squeeze. Questa guida è adatta chiaramente in ambito Desktop, io stesso sono alla ricerca di un compromesso accettabile, quindi è da considerarsi "sperimentale", di conseguenza da usare a proprio rischio e pericolo. Questa guida ho deciso di dividerla in due parti, nella prima parte si parlerà di come velocizzare  la fase di boot, mentre nella seconda parte di come aumentare le prestazioni del sistema. Quindi c'è la possibilità di provare singolarmente queste due guide e farsi un idea dei vantaggi e degli svantaggi.

 

Velocizzare Boot

 

Step 1 servizi:

Indubbiamente la base da cui partire è sempre l'eliminazione dei servizi di avvio che non si utilizzano, a questo proposito esistono nei repository degli strumenti come Bum è sysv-rc-conf. quest'ultimo molto potente, per ottenere uno snellimento dei servizi.

 

Step 2 insserv:

installare insserv se non già presente, ed abilitare l'esecuzione in parallelo dei servizi:

 

# echo 'CONCURRENCY=makefile' >> /etc/default/rcS

 

Step 3 preload:

installare preload che si occuperà di monitorare le applicazioni lanciate dagli utenti e dalle analisi di questi dati predice quali applicazioni potrebbero eseguire gli utenti, di conseguenza recupera e porta in memoria i relativi binari e le loro dipendenze in modo da velocizzarne l'avvio (programmi).

 

Step 3 readahead-fedora:

installare readahead-fedora, uno strumento che precarica file, in questo caso quelli usati durante il processo di boot, per accelerare l'avvio del sistema. Il file di configurazione è in /etc/readahead.conf, assicurarsi che readahead punti a preload:

 

RAC_EXECIGN="/sbin/readahead /usr/sbin/preload"

e passare da 300 a 100 in:

RAC_MAXTIME="100"

quindi:

# reboot

all'avvio di grub bisogna passare un parametro al kernel per avviare il processo:

init=/sbin/readahead-collector

 

Per concludere questa prima parte mi soffermo su dei numeri appena testati su LMDE, e ne ho fatto una media, il tempo è stato preso dal push del tasto invio fino alla comparsa del desktop (musichetta e compiz) il mio OS è settato senza password, quindi login automatico.

Boot in 23.8 secondi

Halt/Reboot in 10 secondi netti.

Certo ci sono i pro ed i contro con un boot veloce 🙂 Nei prossimi giorni la parte 2.

 

enjoy 😉

Benchmark Debian GNU/kFreeBSD con ZFS VS Debian GNU/Linux

 

 

 

Dopo vari Benchmark fatti da Phoronix su Debian GNU/kFreeBSD, ed alcuni fatti anche da me, in privato, questa volta mi sono deciso ad anticipare (forse) Phoronix, facendo dei test su Debian GNU/kFreeBSD kernel 8.1-1_amd64 con filesystem ZFS e Debian Gnu/Linux con kernel 2.6.36_amd64 e filesystem ext4. La mia prima impressione, lo dico subito, è che la musica sta cambiando e cioè, Debian GNU/kFreeBSD pian pian sta crescendo e con il nuovo filesystem ZFS si sta "avvicinando" a Debian GNU/Linux, anche se c'è ancora tanto lavoro da fare. I test li ho eseguiti su un pc con queste caratteristiche:

 

 

 

Immagine 1 = Debian GNU/Linu

Immagine 2 = Debian GNU/kFreeBSD

e così via per tutti i test:

 

Dai test di compressione risulta che Debian GNU/kFreeBSD è più performante nella compressione LZMA e Gzip, del 17% e del 19%.

 

In questo test di processione dell'immagine si equivalgono, addirittura rispetto ai test fatti da Phoronix , in proporzione c'è un incredibile recupero da parte di Debian GNU/kFreeBSD nei confronti di Debian GNU/Linux.

Leggi tutto “Benchmark Debian GNU/kFreeBSD con ZFS VS Debian GNU/Linux”

La Patch funziona però…. Benchmark su Debian

 

 

In questi ultimi giorni in rete non si parla altro che di una piccola Patch da applicare al kernel che ne migliora sensibilmente le prestazioni, e che addirittura Linus Torvalds n'è soddisfatto. Sono venuto anche a  conoscenza di un metodo alternativo per ottenere gli stessi risultati. Quello che ancora non avevo visto erano dei benchmark che provassero se tutto questo fosse vero. Mi sono deciso quindi di fare questo sporco lavoro 🙂 e sinceramente avrei voluto fare molti più test, ma purtroppo in questi giorni di continua pioggia, e le vecchie linee di merda che ci sono in Italia, la ADSL risulta molto degradata, e non ho potutto fare dei test che richiedevano il download di un paio di giga. Comunque per il momento sono riuscito a fare 8 test, ma non escludo di farne degli altri. Questi 8 test comunque ci danno un indirizzo, e cioè, che la patch funziona.,  ma secondo me non fa sfracelli. Questi test li ho fatti, come si può vedere in figura sopra, su Debian Squeeze , kernel 2.6.36 (x86_64), con compiz attivo ed iceweasel aperto.

Benchmark:

La prima immagine di ogni serie si riferisce al benchmark senza patch:

Esempio:

7-zip prima immagine = senza patch

7-zip seconda immagine = con patch

e così via per tutte le altre.

 

 

 

Da questi primi test si evince che questa patch effettivamente funziona, ma proverò a farne degli altri per avere una visione completa di dove e quanto effettivamente sono i miglioramenti.

enjoy 😉