Comments for Kiwi's Blog http://kiwized.net Things and other interesting things Wed, 03 Feb 2010 21:46:37 +0100 http://wordpress.org/?v=2.8.5.2 hourly 1 Comment on Un piccolo hack di un LCD (KL SN102) by kiwi http://kiwized.net/2009/10/15/un-piccolo-hack-di-un-lcd-kl-sn102/comment-page-1/#comment-58 kiwi Wed, 03 Feb 2010 21:46:37 +0000 http://kiwi.tastybra.in/blog/?p=32#comment-58 ora come ora non lo trovo.. sinceramente non è mi stato nemmeno tanto utile. Se lo ritrovo ti rispondo qui. Se ti serve solo il pinout è quello di un HD44780 (v. link nell'articolo), con i piedini da 1 a 14 standard, 15 e 16 sono per la backlight (15 +V_led e 16 GND). Ti servivano altri dati? ora come ora non lo trovo.. sinceramente non è mi stato nemmeno tanto utile. Se lo ritrovo ti rispondo qui. Se ti serve solo il pinout è quello di un HD44780 (v. link nell’articolo), con i piedini da 1 a 14 standard, 15 e 16 sono per la backlight (15 +V_led e 16 GND). Ti servivano altri dati?

]]> Comment on Un piccolo hack di un LCD (KL SN102) by Zanky http://kiwized.net/2009/10/15/un-piccolo-hack-di-un-lcd-kl-sn102/comment-page-1/#comment-57 Zanky Wed, 03 Feb 2010 21:23:05 +0000 http://kiwi.tastybra.in/blog/?p=32#comment-57 Ciao. Ho comprato anche io uno di questi "malfamati" display. non è che avresti la famosa fotocopia della fotocopia della fotocopia con i dati di targa? :) grazie mille per l'aiuto Ciao. Ho comprato anche io uno di questi “malfamati” display. non è che avresti la famosa fotocopia della fotocopia della fotocopia con i dati di targa? :) grazie mille per l’aiuto

]]> Comment on How to make Psi logout on suspend in KDE by kiwi http://kiwized.net/2009/12/13/how-to-make-psi-logout-on-suspend-in-kde/comment-page-1/#comment-28 kiwi Wed, 16 Dec 2009 23:15:47 +0000 http://kiwi.tastybra.in/blog/?p=72#comment-28 So is it now working or not? if not, does the command alone work? Note that you need the latest stable version of Psi. So is it now working or not? if not, does the command alone work?
Note that you need the latest stable version of Psi.

]]> Comment on How to make Psi logout on suspend in KDE by jirik http://kiwized.net/2009/12/13/how-to-make-psi-logout-on-suspend-in-kde/comment-page-1/#comment-27 jirik Wed, 16 Dec 2009 21:51:54 +0000 http://kiwi.tastybra.in/blog/?p=72#comment-27 Everything checked... Both Enable notifications and Enable warning notifications, also Run command in Performing a suspension job. Did the suspend to ram again with some other arbitrary command and it is working now; strange. Thanks Everything checked… Both Enable notifications and Enable warning notifications, also Run command in Performing a suspension job.

Did the suspend to ram again with some other arbitrary command and it is working now; strange.

Thanks

]]> Comment on How to make Psi logout on suspend in KDE by kiwi http://kiwized.net/2009/12/13/how-to-make-psi-logout-on-suspend-in-kde/comment-page-1/#comment-26 kiwi Tue, 15 Dec 2009 23:59:47 +0000 http://kiwi.tastybra.in/blog/?p=72#comment-26 Hi jirik, check in KDE System Settings -> Advanced -> Power Management -> General Settings -> Settings and profile| that "Enable Notifications" is well.. enabled. Hi jirik,
check in KDE System Settings -> Advanced -> Power Management -> General Settings -> Settings and profile| that “Enable Notifications” is well.. enabled.

]]> Comment on How to make Psi logout on suspend in KDE by jirik http://kiwized.net/2009/12/13/how-to-make-psi-logout-on-suspend-in-kde/comment-page-1/#comment-25 jirik Tue, 15 Dec 2009 19:52:33 +0000 http://kiwi.tastybra.in/blog/?p=72#comment-25 Hmm, interesting... Tried that, was not working. Then I tried to put a simple touch command into the Run Command and nothing happened. Do you have any idea why my command is not being started? Hmm, interesting… Tried that, was not working. Then I tried to put a simple touch command into the Run Command and nothing happened. Do you have any idea why my command is not being started?

]]> Comment on Impostare l'IO scheduler per le SSD by kiwi http://kiwized.net/2008/08/31/impostare-lio-scheduler-per-le-ssd/comment-page-1/#comment-23 kiwi Wed, 25 Nov 2009 02:08:50 +0000 http://blog.kiwized.net/2008/08/31/impostare-lio-scheduler-per-le-ssd/#comment-23 Ciao Max, molto interessante l'articolo su OCZ. Se capiamo quanto è il blocksize si potrebbe provare l'approccio 1, cioè quello di allineare la partizione, così possiamo anche fare il boot. Anzi, adesso prendo il portatile e cerco il datasheet! Il mio SSD è il p-ssd1800 (per vedere il tuo hdparm -i /dev/sda) Sono fortunato è il Samsung, quello "veloce". Non voglio sapere quello "lento" Intel che prestazioni ha... Intanto ho trovato questo: http://www.ssdflashdrivereviews.com/flash-drive-review/Acer-Aspire-One-P-SSD1800-Ver2-8GB-Windows-7.php Guarda in fondo, il grafico sulle performance di scrittura. Questo benchmark suggerisce una dimensione di 64KB (vedi che la write speed non migliora usando blocksize più grandi? è un dato statistico molto significativo) Riguardo NILFS devo ancora farmi un idea precisa. Ho letto rapidamente il paper del test, scritto della Samsung. Loro hanno comodamente allineato il filesystem alla blocksize flash :) NILFS è strutturato a log quindi se non altro evita di scrivere troppo spesso negli stessi posti. In teoria poi le scritture sono sequenziali, e se vengono flushate non troppo spesso c'è anche il rischio che le prestazioni aumentino (richieste molto grandi di settori contigui -> meno blocchi flash riscritti per niente) Ad esempio due scritture grandi 4KB (di due file diversi) scriverebbero due volte blocchi flash da 64KB su un ext3 (senza contare i metadati, probabilmente arriveremmo a 3 blocchi flash). Su NILFS (e qualsiasi filesystem a log), se le richieste vengono unite prima di essere scritte dovremmo avere una sola richiesta in append al log probabilmente grande <64KB, scrivendo un solo blocco flash. Guardando il paper originale http://www.usenix.org/event/lsf08/tech/shin_SSD.pdf si vede che le richieste sono sempre di 128KB! Questo vuol dire che ogni volta che il filesystem scrive, (se ha abbastanza dati ovviamente), scrive due blocchi flash alla volta. Notare che nel paper manca il case study per NILFS.. Peccato! Avrei voluto confrontare (magari confermare) la mia ipotesi. Comunque la prima impressione è buona. I miei dubbi sono: è abbastanza stabile come filesystem? (non ha neanche un fsck). Cosa succede se faccio una richiesta piccola (un file di pochi byte, ad esempio quelli creati al boot in /var) e lascio che venga scritta, cioè la lascio isolata nel tempo? Non è che si disallineano le richieste successive rispetto ai blocchi? Il benchmark è qualcosa di artificiale che va a riempire le code di scrittura per alcuni secondi o minuti. Nell'utilizzo normale questo succede "solo" quando si copia un file grosso o si estrae un archivio. Non vorrei che in usi più tipici le cose peggiorino. Mai quanto usando ext3 o anche ext2 comunque :) É comunque sorprendente quanto sia performante nonostante non sia un filesystem volutamente nato per le SSD. Nel TODO c'è "ottimizzazioni per SSD". Devo dire che gli manca veramente poco. Grazie del link! Io avevo sempre cercato filesystem che supportassero blocchi (del fs) grandi, ma in realtà quello che serve è riuscire a fare richieste grandi ed allineate al blocco flash. Non è necessariamente la stessa cosa :) Non avrei paura del wear, sono sicuro che è meglio su un filesystem a log che su qualsiasi altro non a log. Ora che ho anche un altro portatile posso pensare di pasticciare con reinstallazioni e test. :) Ciao Max,
molto interessante l’articolo su OCZ.
Se capiamo quanto è il blocksize si potrebbe provare l’approccio 1, cioè quello di allineare la partizione, così possiamo anche fare il boot.
Anzi, adesso prendo il portatile e cerco il datasheet!
Il mio SSD è il p-ssd1800 (per vedere il tuo hdparm -i /dev/sda)
Sono fortunato è il Samsung, quello “veloce”. Non voglio sapere quello “lento” Intel che prestazioni ha…
Intanto ho trovato questo:
http://www.ssdflashdrivereviews.com/flash-drive-review/Acer-Aspire-One-P-SSD1800-Ver2-8GB-Windows-7.php
Guarda in fondo, il grafico sulle performance di scrittura.
Questo benchmark suggerisce una dimensione di 64KB (vedi che la write speed non migliora usando blocksize più grandi? è un dato statistico molto significativo)

Riguardo NILFS devo ancora farmi un idea precisa.
Ho letto rapidamente il paper del test, scritto della Samsung. Loro hanno comodamente allineato il filesystem alla blocksize flash :)
NILFS è strutturato a log quindi se non altro evita di scrivere troppo spesso negli stessi posti. In teoria poi le scritture sono sequenziali, e se vengono flushate non troppo spesso c’è anche il rischio che le prestazioni aumentino (richieste molto grandi di settori contigui -> meno blocchi flash riscritti per niente)
Ad esempio due scritture grandi 4KB (di due file diversi) scriverebbero due volte blocchi flash da 64KB su un ext3 (senza contare i metadati, probabilmente arriveremmo a 3 blocchi flash). Su NILFS (e qualsiasi filesystem a log), se le richieste vengono unite prima di essere scritte dovremmo avere una sola richiesta in append al log probabilmente grande <64KB, scrivendo un solo blocco flash.
Guardando il paper originale http://www.usenix.org/event/lsf08/tech/shin_SSD.pdf si vede che le richieste sono sempre di 128KB!
Questo vuol dire che ogni volta che il filesystem scrive, (se ha abbastanza dati ovviamente), scrive due blocchi flash alla volta.
Notare che nel paper manca il case study per NILFS.. Peccato! Avrei voluto confrontare (magari confermare) la mia ipotesi.
Comunque la prima impressione è buona.
I miei dubbi sono: è abbastanza stabile come filesystem? (non ha neanche un fsck). Cosa succede se faccio una richiesta piccola (un file di pochi byte, ad esempio quelli creati al boot in /var) e lascio che venga scritta, cioè la lascio isolata nel tempo? Non è che si disallineano le richieste successive rispetto ai blocchi?
Il benchmark è qualcosa di artificiale che va a riempire le code di scrittura per alcuni secondi o minuti. Nell'utilizzo normale questo succede "solo" quando si copia un file grosso o si estrae un archivio. Non vorrei che in usi più tipici le cose peggiorino. Mai quanto usando ext3 o anche ext2 comunque :)
É comunque sorprendente quanto sia performante nonostante non sia un filesystem volutamente nato per le SSD. Nel TODO c'è "ottimizzazioni per SSD". Devo dire che gli manca veramente poco.
Grazie del link! Io avevo sempre cercato filesystem che supportassero blocchi (del fs) grandi, ma in realtà quello che serve è riuscire a fare richieste grandi ed allineate al blocco flash. Non è necessariamente la stessa cosa :)
Non avrei paura del wear, sono sicuro che è meglio su un filesystem a log che su qualsiasi altro non a log.
Ora che ho anche un altro portatile posso pensare di pasticciare con reinstallazioni e test. :)

]]> Comment on Impostare l'IO scheduler per le SSD by Max http://kiwized.net/2008/08/31/impostare-lio-scheduler-per-le-ssd/comment-page-1/#comment-22 Max Tue, 24 Nov 2009 11:49:11 +0000 http://blog.kiwized.net/2008/08/31/impostare-lio-scheduler-per-le-ssd/#comment-22 ciao Kiwi :) volevo il tuo parere su una idea balzana che mi è venuta in mente leggendo questo post sul forum di OCZ: http://www.ocztechnologyforum.com/forum/showpost.php?s=313aff9f1fe2ef1c86af597440d6f320&p=373226&postcount=98 dato che li si dice chi si può evitare il problema dei blocchi saltando la tabella delle partizioni e scrivendo il filesystem direttamente sul device, ho pensato che per chi ha un netbook che vede al boot il card reader come disco usb (non chi come noi ha un aspire one :( ) potrebbe mettere la partizione di boot sulla scheda shdc e poi formattare direttamente il device /dev/sda e montarlo su / in quanto al filesystema, stavo leggendo questo articolo su linux-mag: http://www.linux-mag.com/id/7345/2/ che magnifica le doti di nilfs. che ne pensi? ciao Kiwi :)
volevo il tuo parere su una idea balzana che mi è venuta in mente leggendo questo post sul forum di OCZ:
http://www.ocztechnologyforum.com/forum/showpost.php?s=313aff9f1fe2ef1c86af597440d6f320&p=373226&postcount=98

dato che li si dice chi si può evitare il problema dei blocchi saltando la tabella delle partizioni e scrivendo il filesystem direttamente sul device, ho pensato che per chi ha un netbook che vede al boot il card reader come disco usb (non chi come noi ha un aspire one :( ) potrebbe mettere la partizione di boot sulla scheda shdc e poi formattare direttamente il device /dev/sda e montarlo su /

in quanto al filesystema, stavo leggendo questo articolo su linux-mag:

http://www.linux-mag.com/id/7345/2/

che magnifica le doti di nilfs.
che ne pensi?

]]> Comment on Impostare l'IO scheduler per le SSD by kiwi http://kiwized.net/2008/08/31/impostare-lio-scheduler-per-le-ssd/comment-page-1/#comment-18 kiwi Thu, 12 Nov 2009 16:02:27 +0000 http://blog.kiwized.net/2008/08/31/impostare-lio-scheduler-per-le-ssd/#comment-18 Ciao Max, quella che hai determinato è la velocità di lettura, ed è normale che scenda. 17 MB al secondo sono comunque tanti rispetto a quella di scrittura (che sarà sotto il MB/sec). Quello che fa quel settaggio è evitare di perdere molto tempo a fare letture potenzialmente inutili (read ahead, letture "speculative" per intenderci), sapendo che il problema grosso delle SSD è la scrittura. In questo modo durante un utilizzo tipico (letture e scritture miste) si evita che si accodino tante richieste di lettura durante una scrittura. Comq ho scritto nel post, questa non è una soluzione proprio ideale, ma credo sia il meglio che si possa fare ora. In realtà si potrebbe capire quale è la dimensione dei blocchi delle SSD e allinearci il filesystem (e magari se lo supporta mettere i blocchi della stessa dimensione). Ora il mio "acerone" non lo sto usando molto, ma quando lo riprenderò in mano farò delle prove con <a href="http://btrfs.wiki.kernel.org" rel="nofollow">brtfs</a> che sembra supportare blocksize belli grandi (64k, devo verificare). Vale la pena fare delle prove perchè gli stessi risultati si possono applicare alle chiavette USB. Quando ho novità farò un nuovo post :) Ciao Max,
quella che hai determinato è la velocità di lettura, ed è normale che scenda.
17 MB al secondo sono comunque tanti rispetto a quella di scrittura (che sarà sotto il MB/sec).
Quello che fa quel settaggio è evitare di perdere molto tempo a fare letture potenzialmente inutili (read ahead, letture “speculative” per intenderci), sapendo che il problema grosso delle SSD è la scrittura.
In questo modo durante un utilizzo tipico (letture e scritture miste) si evita che si accodino tante richieste di lettura durante una scrittura.
Comq ho scritto nel post, questa non è una soluzione proprio ideale, ma credo sia il meglio che si possa fare ora.
In realtà si potrebbe capire quale è la dimensione dei blocchi delle SSD e allinearci il filesystem (e magari se lo supporta mettere i blocchi della stessa dimensione).
Ora il mio “acerone” non lo sto usando molto, ma quando lo riprenderò in mano farò delle prove con brtfs che sembra supportare blocksize belli grandi (64k, devo verificare).
Vale la pena fare delle prove perchè gli stessi risultati si possono applicare alle chiavette USB. Quando ho novità farò un nuovo post :)

]]> Comment on Impostare l'IO scheduler per le SSD by Max http://kiwized.net/2008/08/31/impostare-lio-scheduler-per-le-ssd/comment-page-1/#comment-17 Max Thu, 12 Nov 2009 11:46:51 +0000 http://blog.kiwized.net/2008/08/31/impostare-lio-scheduler-per-le-ssd/#comment-17 ciao Kiwi e grazie per il tuo post. volevo solo chiederti qualche informazione, dato che ho provato i tuoi suggerimenti sul mio aspier one con risultati che sono andati all'opposto rispetto a quanto mi aspettavo. utilizzando 8 come valore per /sys/block/sda/queue/read_ahead_kb, mi si è dimezzata la velocità di scrittura che è passata da 38.55 Mb/s a 17. come test ho usato un semplice: hdparm -Tt /dev/sda mi puoi piegare il motivo? sto cercando di decidere se usare deadline o noop comne scheduler ma non riesco a sbrogliare molto la matassa... ciao Kiwi e grazie per il tuo post.
volevo solo chiederti qualche informazione, dato che ho provato i tuoi suggerimenti sul mio aspier one con risultati che sono andati all’opposto rispetto a quanto mi aspettavo.
utilizzando 8 come valore per /sys/block/sda/queue/read_ahead_kb, mi si è dimezzata la velocità di scrittura che è passata da 38.55 Mb/s a 17.
come test ho usato un semplice:
hdparm -Tt /dev/sda

mi puoi piegare il motivo? sto cercando di decidere se usare deadline o noop comne scheduler ma non riesco a sbrogliare molto la matassa…

]]>