MameCab Avvio e spegnimento come un ArcadeCab

[glstar]

.
Non credo che l 'ibernazione, che sia normale, o Horm possa scrivere sull ' HDD se l ' EWF Ram è attivato.

Invece si, l'horm ha i permessi su ewf x poter scrivere su hd, l'unico servizio che puo' quindi scrivere effettivamente su disco.

A parte le sottigliezze ripeto, io ho sempre ibernato, nn conto piu' le volte, x registrare le modifiche fatte durante questi anni ed il sistema e' fluido come appena creato

Io invece l'ho dovuto abbandonare perchè evidentemente non andava molto in sintonia con l'hyperspin.
Sai quante volte è successo che dopo qualche tempo il sistema ripartisse facendo sentire l'audio correttamente ma con il processo hyperspin impallato (non si muoveva praticamente niente del menu grafico...andava come una lumaca), costringendo ad armarsi di tastiera e chiudere il processo hyperspin e rilanciarlo e poi rimandare in ibernazione (ricreando quindi l'immagine horm) il tutto.....
Senza contare le volte che gli emulatori non partivano più perchè si erano sputtanati i file .ini di configurazione......
Probabilmente il fatto di avere l'hyperlaunch (il sistema di lancio degli emulatori, di hyperspin) che legge e scrive sui file .ini non va d'accordo con l'horm.
Anche se non ho mai capito il motivo, visto che in teoria le scritture dovrebbero rimanere solo in memoria e poi essere cancellate al successivo riavvio.....

[PaTrYcK]

Io ho avuto qualche problema con vecchie versioni di mala, mi saltavano le liste dei preferiti e dei vari emu impallando il sistema, evidentemente il fatto di nn poter scrivere effettivamente su hd creava qualche conflitto, ora con le ultime versioni piu' stabili tutto ok...
Nel caso di hyperspin (viste la configurazione minima richiesta x farlo andare) puo' essere che richiedesse un uso spropositato di risorse mandando in tilt tutto il sistema.
In ogni caso la maggior parte degli utenti vedo che utilizza questo metodo senza nessun problema e con tutti i benefici del caso

[dR.pRoDiGy]

A mio parere il dubbio di CarloB è legittimo.. Tutte le operazioni del disco vanno in RAM, e di per certo uno dei punti a sfavore è che in caso di richieste di scrittura abbondanti su disco la memoria può andare a saturazione, fino al crash del sistema..
http://en.m.wikipedia.org/wiki/Enhanced_Write_Filter

Anche cosa succede nell'ibernare non è chiaro (se riesco a trovare doc ve la riporto..) visto che oltre a salvare su disco lo stato della memoria, per fare una copia "giusta" della macchina l'horm deve chiedere all'ewf di fare il cosiddetto "flush" delle operazioni del disco dalla RAM, cioè rifarle tutte in fila sull'hd, per salvarle.
Se non lo facesse (tu Pat sai per certo che è così?), si limiterebbe a dumpare la memoria, col risultato che il sistema è ok perche anche le info dell'ewf vengono ibernate anche loro, ma solo fino al prox riavvio senza ewf, quando ti trovi col disco "rimasto indietro".
Sinceramente mi pare strano che ci sia un buco così grosso, ma chi lo sa.. Non sarebbe il primo di MS

[PaTrYcK]

Andrebbe visto per bene cosa effettivamente avviene durante l'ibernazione, ma secondo me alcuni servizi non utilizzati non vengono presi in considerazione nel pagefile che viene creato durante l'ibernazione, questo il motivo di un avvio cosi rapido, inoltre nei nostri mamecab i vari soft attivi non influiscono piu' di tanto sullo stesso, idem i vari cambiamenti di configurazione . Ripeto io ho fatto diverse modifiche nel tempo ibernando x registrare le stesse ed il sistema rimane sempre "snello", questa problematica inoltre si avrebbe anche nell'ibernazione classica senza ewf e nn mi pare che chi la utilizzi sempre come metodo di spegnimento abbia notato differenze di velocita' nel proprio sistema.

[glstar]

Io ho avuto qualche problema con vecchie versioni di mala, mi saltavano le liste dei preferiti e dei vari emu impallando il sistema, evidentemente il fatto di nn poter scrivere effettivamente su hd creava qualche conflitto, ora con le ultime versioni piu' stabili tutto ok...
Nel caso di hyperspin (viste la configurazione minima richiesta x farlo andare) puo' essere che richiedesse un uso spropositato di risorse mandando in tilt tutto il sistema.
In ogni caso la maggior parte degli utenti vedo che utilizza questo metodo senza nessun problema e con tutti i benefici del caso

Francamente non saprei, comunque non è abbinabile ad un sistema hyperspin....anche se continuo a domandarmi come è possibile, visto che in teoria tutte le operazioni di scrittura ecc...dovrebbe farle solo in ram e non veramente.....ma forse non è proprio cosi....
Si poteva risolvere questo problema mettendo in sola lettura tutti gli ini di hyperlaunch, hyperspin e dei vari emulatori di modo da evitare la scrittura e la possible corruzione dei files.....
Ma il problema del freeze alla partenza del menu grafico, con conseguente necessità di killare il processo e farlo ripartire e ricreare il file immagine invece non sono mai riuscito a capire perchè e come risolverlo......
Pace....

A mio parere il dubbio di CarloB è legittimo.. Tutte le operazioni del disco vanno in RAM, e di per certo uno dei punti a sfavore è che in caso di richieste di scrittura abbondanti su disco la memoria può andare a saturazione, fino al crash del sistema..
http://en.m.wikipedia.org/wiki/Enhanced_Write_Filter

Si è quello che succede....
Ma non un crash di sistema (perlomeno non ho mai verificato un problema del genere), bensi un out of memory dell'applicazione che si sta facendo partire....
Tipo mame con qualche gioco pesante tipo metal slug 5 ecc....
Se la memoria non basta, il processo mame va in out of memory e si chiude....tornando poi al menu grafico senza problemi.
Sicuramente un procedimento del genere richiede almeno un paio di gb di ram per funzionare.
Perchè bisogna anche tenere in considerazione che durante un utilizzo intenso, cambiando giochi, emulatori ecc....la memoria utilizzata dal sistema tende inesorabilmente a salire decisamente di più rispetto a quella utilizzata appena il sistema parte.

[CarloBlanch]

Esatto, era quello che dicevo.
Molta RAM? Il freeze ci mette più tempo a ripristinare, meno RAM si rischia l'out of memory.
No la cosa migliore é il solo ewf disabilitandolo quando vanno fatte modifiche.
Con un SSD l'avvio con il feel é di 17 secondi, con il ripristino dal freeze poco di meno, non ne vale la pena.

Domanda: ma se la cartella é condivisa, e da un altro PC vengono fatte le modifiche il sistema scrive sempre in RAM con ewf attivato giusto?

[biasini]

Perdonatemi se magari non ho seguito tutto per filo e per segno e magari sparo qualche inesattezza.
Vi porto la mia esperienza: caro DR. Prodigy, mai avuto mai problemi con l'ibernazione in accoppiata con FEEL...almeno in versione 1.2.1 (l'ultima non l'ho testata): 3 cabinati con hardware datato viaggiano felici e contenti con 1 gb di ram da molto tempo, con soddisfazione rispettivi proprietari.
Le configurazioni sono le seguenti: due macchine simili con processore Sempron 3000 su socket 754, 1gb di ram, hd ide, scheda video ATI serie 7000 e 7500. Il terzo P4 2.4 socket 478, 1gb di ram, hd ide e ATI 9200.
Win XP al netto di servizi e configurazioni superflue, Frontend FEEL 1.2.1 emulatori (su 2 pc su 3) MAME 0.148, Daphne, Colem, Nestopia, Snes9x, Fusion, Magic Engine, Epsxe.
Nessun problema di sorta con l'ibernazioine...
La mia considerazione è questa: se un sistema è correttamente configurato, per quale motivo (problemi collaterali a parte) un sistema dovrebbe presentare problemi dal momento che il sistema di ibernazione scrive un'immagine su disco fisso che viene poi puntualmente ricaricata ogni volta, fin tanto che non la si modifica successivamente?
Il problema della ram è a se stante, dal momento in cui viene disattivato il file di paging che normalmente "appoggia" i dati in eccesso sullo spazio riservato allo scopo nel disco rigido.
Se In una configurazione XP con pochissimi processi di sistema, un frontend pulito e leggero + l'esecuzione di un emulatore 1 gb di ram non basta per gestire, il problema è altrove, XP avrà i suoi bei limiti, ma non siamo su windows 95, la ram è gestita sufficientemente bene e non si satura tanto facilmente.

Tipo mame con qualche gioco pesante tipo metal slug 5 ecc....

I NeoGeo non sono pesanti e MAME in generale non utilizza molta ram, semmai è avido di CPU: purtroppo sono passati anni e le versioni di questo emulatore sono un pò cambiate, ma da diversi test che feci (giochi 3d a parte) il più esoso in termini di Ram mi risultò essere Street Fighter 3, che arrivava a "succhiare" oltre 500mb da solo ed aveva quindi problemi in configurazioni con sole 512mb di ram.
L'ibernazione funziona con successo e senza conseguenze da anni sui portatili, ogni volta che la batteria si abbassa a valori prossimi allo zero ed il sistema provvede a mettere a nanna.

[biasini]

Molta RAM? Il freeze ci mette più tempo a ripristinare, meno RAM si rischia l'out of memory.
No la cosa migliore é il solo ewf disabilitandolo quando vanno fatte modifiche.
Con un SSD l'avvio con il feel é di 17 secondi, con il ripristino dal freeze poco di meno, non ne vale la pena.

Non è che si fa confusione tra sospensione o stand-by ed ibernazione: perchè nel primo caso la RAM è l'unico componente che resta attivo, mentre con l'ibernazione, com'è ovvio staccando la corrente, la memoria si svuota.
Non si può paragonare certo l'hardware da me preso in considerazione ad esempio, con uno moderno dotato di SSD: lì in fatto di tempi di avvio cambia davvero poco o niente, resta il fatto che non si può spegnere brutalmente il cab.

[dR.pRoDiGy]

Andrebbe visto per bene cosa effettivamente avviene durante l'ibernazione, ma secondo me alcuni servizi non utilizzati non vengono presi in considerazione nel pagefile che viene creato durante l'ibernazione, questo il motivo di un avvio cosi rapido, inoltre nei nostri mamecab i vari soft attivi non influiscono piu' di tanto sullo stesso, idem i vari cambiamenti di configurazione . Ripeto io ho fatto diverse modifiche nel tempo ibernando x registrare le stesse ed il sistema rimane sempre "snello", questa problematica inoltre si avrebbe anche nell'ibernazione classica senza ewf e nn mi pare che chi la utilizzi sempre come metodo di spegnimento abbia notato differenze di velocita' nel proprio sistema.

Nell'ibernazione avviene, semplificando, questo: i dischi rigidi vengono sincronizzati (i.e.: vengono completate tutte le scritture ancora in cache), tutti i programmi in esecuzione vengono "freezati", e poi tutto il contenuto della memoria RAM viene travasato su disco (sotto forma di un file nascosto enorme, grande esattamente come la RAM). Finito questo il pc si spegne.
Alla riaccensione avviene l'esatto contrario: dal disco viene ricaricato tutto in RAM, vengono accesi i device driver, e si "ridà vita" a tutto.
Di conseguenza, più o meno servizi e programmi attivi non fanno alcuna differenza sui tempi di ibernazione e riavvio: la RAM viene dumpata tutta, a prescindere se usata o meno; in breve le variabili in gioco sul tempo di boot da ibernazione sono la quantità di RAM presente sul sistema (più ce n'è e più è lento il boot), e la velocità del disco (più veloce è, e più è veloce il boot).

A mio parere il dubbio di CarloB è legittimo.. Tutte le operazioni del disco vanno in RAM, e di per certo uno dei punti a sfavore è che in caso di richieste di scrittura abbondanti su disco la memoria può andare a saturazione, fino al crash del sistema..
http://en.m.wikipedia.org/wiki/Enhanced_Write_Filter

Si è quello che succede....
Ma non un crash di sistema (perlomeno non ho mai verificato un problema del genere), bensi un out of memory dell'applicazione che si sta facendo partire....
Tipo mame con qualche gioco pesante tipo metal slug 5 ecc....
Se la memoria non basta, il processo mame va in out of memory e si chiude....tornando poi al menu grafico senza problemi.

Un programma - magari pesante - che non starta è solo un primo sintomo di memoria che scarseggia.. se anche in questa condizione continuassi a fare attività sul disco (che con EWF portano via altra RAM) consumeresti tutta la memoria fino all'ultimo byte, bloccando nel caso più grave l'intero OS.
(Edit: È un'ipotesi molto remota su un cab)

Molta RAM? Il freeze ci mette più tempo a ripristinare, meno RAM si rischia l'out of memory.
No la cosa migliore é il solo ewf disabilitandolo quando vanno fatte modifiche.
Con un SSD l'avvio con il feel é di 17 secondi, con il ripristino dal freeze poco di meno, non ne vale la pena.

Non è che si fa confusione tra sospensione o stand-by ed ibernazione: perchè nel primo caso la RAM è l'unico componente che resta attivo, mentre con l'ibernazione, com'è ovvio staccando la corrente, la memoria si svuota.
Non si può paragonare certo l'hardware da me preso in considerazione ad esempio, con uno moderno dotato di SSD: lì in fatto di tempi di avvio cambia davvero poco o niente, resta il fatto che non si può spegnere brutalmente il cab.

La questione non è l'ibernazione in sè, ma bensì l'ibernazione collegata all'EWF.
Con l'EWF attivo hai che il disco rigido non viene mai toccato, col risultato che:
- non è possibile avere file di paging, e così tutto deve girare nella RAM fisica, che va via via sempre più consumandosi per via delle scritture "virtuali" sul disco (di qui l'esaurimento della memoria)
- un'ibernazione "normale" (ovvero senza flush delle operazioni disco scritte in RAM) produrrebbe un disco rigido disallineato rispetto alla situazione dei programmi in esecuzione. Al momento la cosa non si noterebbe, perchè le scritture disco in RAM vengono ripristinate anche loro in memoria al riavvio, ma al primo riavvio senza HORM andrebbero perse, lasciando il sistema in una condizione potenzialmente non pulita.

Ultimo, credo che questa cosa sia confermabile, in quanto Microsoft stessa consiglia di disabilitare l'HORM se si devono fare modifiche a un sistema con EWF:
http://msdn.microsoft.com/en-us/library ... .5%29.aspx

[PaTrYcK]

L'idea di utilizzare l'ewf + l'horm parte dai sistemi embedded che sfruttavano questo sistema nei pc che dovevano avere come punto di forza la poca manutenzione, vedi biglietterie automatiche, punti informazione ecc, sistemi che non potevano essere messi fuori uso dai tanti utenti che li utilizzavano anche in modo non proprio professionale.
Ho quindi riversato l'idea con alcune modifiche sul mamecab, poter avere un sistema immune da modifiche involontarie e successivi crash era perfetto dato che questo viene spesso utilizzato da bambini o cmq persone che nn fanno molta attenzione al mantenimento dello stesso...
Il sistema ha sempre funzionato perfettamente, dal 2010 che lo utilizzo stabilmente, unico punto dolente e' stata l'implementazione con alcuni front end, su alcuni di questi infatti si avevano inaspettati blocchi o errori tra le liste ecc...fortunatamente episodi isolati.
Per quanto riguarda le modifiche da apportare al sistema, nella guida avevo riportato che era obbligatorio disattivare ewf, riavviare, eseguire le modifiche e poi riattivare l'ewf, ma avendo notato che queste venivano (ovviamente) registrate con una semplice ibernazione ho sempre utilizzato questo metodo, sicuramente piu' comodo e veloce, ora passati 4 anni il sistema rimane sempre perfetto, credo quindi sia ipotizzabile che si possa utilizzare tranquillamente sul proprio mamecab con tutti i benefici del caso

[dR.pRoDiGy]

L'idea di utilizzare l'ewf + l'horm parte dai sistemi embedded che sfruttavano questo sistema nei pc che dovevano avere come punto di forza la poca manutenzione, vedi biglietterie automatiche, punti informazione ecc, sistemi che non potevano essere messi fuori uso dai tanti utenti che li utilizzavano anche in modo non proprio professionale.
Ho quindi riversato l'idea con alcune modifiche sul mamecab, poter avere un sistema immune da modifiche involontarie e successivi crash era perfetto dato che questo viene spesso utilizzato da bambini o cmq persone che nn fanno molta attenzione al mantenimento dello stesso...
Il sistema ha sempre funzionato perfettamente, dal 2010 che lo utilizzo stabilmente, unico punto dolente e' stata l'implementazione con alcuni front end, su alcuni di questi infatti si avevano inaspettati blocchi o errori tra le liste ecc...fortunatamente episodi isolati.
Per quanto riguarda le modifiche da apportare al sistema, nella guida avevo riportato che era obbligatorio disattivare ewf, riavviare, eseguire le modifiche e poi riattivare l'ewf, ma avendo notato che queste venivano (ovviamente) registrate con una semplice ibernazione ho sempre utilizzato questo metodo, sicuramente piu' comodo e veloce, ora passati 4 anni il sistema rimane sempre perfetto, credo quindi sia ipotizzabile che si possa utilizzare tranquillamente sul proprio mamecab con tutti i benefici del caso

Ma lo so Patrick, ci mancherebbe!
Vorrei chiarire che a parte tutto reputo il sistema validissimo (seguo questo 3d fin quasi dalla sua nascita! ) e, anche se non l'ho mai usato, penso anche parecchio stabile ed enterprise (di fatto come dici giustamente tu nasce per i sistemi windows embedded, che devono durare mesi/anni senza manutenzione)..
Ci tengo a dirti che il mio vuole essere solo un contributo per capire meglio pregi e limiti della soluzione per usarla al meglio. Detto ciò, penso che cmq rimanga la migliore, se si cerca la "perfezione" nel mamecab.. solo che, come tutte le soluzioni spinte, richiede comprensione e attenzioni extra

[CarloBlanch]

a dR.pRoDiGy :

Ho imparato una cosa nuova, non sapevo che l 'ibernazione dumpasse tutta la ram fisica, anche quella non utilizzata (in effetti è ovvio a pensarci, poiché la memoria non è uno stack, non usa il lifo e viene impiegata dal sistema in maniera random a seconda delle esigenze e della grandezza dei dati, come accade negli hard disk quindi va dumpata tutta)
Quindi la cosa migliore è avere un sistema con poca ram, meglio non andare oltre i 2 Gb, per non rallentare troppo il ripristino.
Secondo me va studiato bene il comportamento del cabinet nell 'uso quotidiano.
Magari viene fuori che un solo giga di ram basta e avanza, e con un ssd il ripristino scende sotto i 10 secondi.
Io uso "trigone system monitor" che invia i dati al telefono, in modo da monitorare l 'utilizzo della memoria e il carico cpu in tempo reale.
In effetti uso anche motherboard monitor e un plugin di lcdsmartie, ho un display lcd collegato al cab.

Cmq questo 3d è davvero interessante, si imparano un sacco di cose.

[biasini]

Il sistema ha sempre funzionato perfettamente, dal 2010 che lo utilizzo stabilmente, unico punto dolente e' stata l'implementazione con alcuni front end, su alcuni di questi infatti si avevano inaspettati blocchi o errori tra le liste ecc...fortunatamente episodi isolati.

Date di funzionamento a parte, sono perfettamente in linea con quanto dici in queste due righe.

Aggiungo un paio di considerazioni: per quanto, come detto da Dr. Prodigy, la RAM venga dumpata in blocco su HD, la natura dei processi attivi e delle applicazioni utilizzate può cambiare le carte in tavola...evidentemente l'idiosincrasia di alcuni frontend (o magari altre applicazioni) con l'EWF e l'ibernazione, può creare noie.
Ipotizzo: ci sono programmi che necessitano del file di paging obbligatorio o se ne creano addirittura uno proprio (photoshop mi pare). In tal caso il sistema operativo può riportare un errore. Personalmente con l'utilizzo di FEEL + Emulatori + driver e servizi strettamente necessari, non ho mai avuto problemi di sorta, mentre magari il tale frontend, la tale applicazione o il tale emulatore non prescinde dall'esistenza della memoria virtuale su disco o mal ci si adatta.

Sempre a proposito della RAM...per quanto non ottimizzato come in altri sistemi oprativi, l'utilizzo della memoria su XP permette di non saturare mai, se non nel caso di richiesta eccessiva, condizione che normalmente in un cab non avviene. Programmi come RAM Idle erano in "voga" ai tempi di win 98, già con il 2000 e NT problemi di memoria inutilmente intasata non ve ne erano più, per quanto mi risulta.

[dR.pRoDiGy]

Ipotizzo: ci sono programmi che necessitano del file di paging obbligatorio o se ne creano addirittura uno proprio (photoshop mi pare). In tal caso il sistema operativo può riportare un errore. Personalmente con l'utilizzo di FEEL + Emulatori + driver e servizi strettamente necessari, non ho mai avuto problemi di sorta, mentre magari il tale frontend, la tale applicazione o il tale emulatore non prescinde dall'esistenza della memoria virtuale su disco o mal ci si adatta.

Attenzione, la memoria virtuale su disco è una risorsa che il sistema operativo gestisce autonomamente, e di cui i programmi "non sanno nulla"; questi si limitano a chiedere memoria all'OS: se la memoria fisica (RAM) è sufficiente il sistema gliela dà.
In caso contrario, secondo ragionamenti suoi, prende un pò della RAM occupata da altri programmi, e ove possibile non in uso (es.: programma in background), la trasferisce temporaneamente nel file di swap (memoria virtuale), e riassegna la RAM liberata al processo che gliel'ha chiesta.
Ad esaurimento anche del file di swap, o in sua assenza, cominciano a partire gli errori "Out of memory".
Nel caso, molto particolare, di Photoshop, la memoria virtuale viene invece gestita direttamente dal sw stesso in maniera custom, ma questo caso non riguarda lo swap di sistema.

Sempre a proposito della RAM...per quanto non ottimizzato come in altri sistemi oprativi, l'utilizzo della memoria su XP permette di non saturare mai, se non nel caso di richiesta eccessiva, condizione che normalmente in un cab non avviene. Programmi come RAM Idle erano in "voga" ai tempi di win 98, già con il 2000 e NT problemi di memoria inutilmente intasata non ve ne erano più, per quanto mi risulta.

Riguardo la gestione della memoria, i processi, i servizi, il multitasking pre-emptive etc., il grande balzo generazionale è arrivato per la precisione con Windows NT 4. Tutti i Win successivi, esclusi 98 e il terrificante ME condividono il medesimo core di sistema di NT appunto, che ha effettivamente fornito una stabilità finalmente molto buona all'OS, e per tutti questi (NT, 2000, XP, Vista, 7, 8, WinServer) è *abbastanza* vero quel che dici.
In realtà la saturazione della memoria è sempre teoricamente possibile, nel caso in cui la RAM e lo swap file finissero.

Con l'EWF attivo hai anche altri 2 aspetti che concorrono all'esaurimento della RAM:
- lo swap file è disattivato
- tutte le operazioni su disco vengono scritte in RAM e, a differenza di quella usata dai programmi (che alla chiusura la scaricano), non viene mai più rilasciata fino allo spegnimento del sistema

Come già detto si tratta di casi limite, ma nel caso vengano eseguite molte operazioni su disco e su file grandi, o nel caso di multi-tasking molto aggressivo (entrambe condizioni abbastanza improbabili su un cab) e la macchina non viene mai spenta, la RAM può comunque terminare.

[Smanettone]

Scusate ma fatemi capire sta cosa: se io volessi farmi un PC apposito da montare nel cab con Hypefspyn, Hyperlaunch ed emu vari, quale e soprattutto quanta memoria ram mi converrebbe montare, sempre partendo dal presupposto di allestirlo con ewf+horm?

[biasini]

Magari un paio di GigaByte...bisognerebbe controllare i consumi di ram del frontend e degli emulatori in questione, comunque utilizzando XP 32bit di più proprio non serve (il massimo utilizzabile è comunque 3 e spicci)

[Smanettone]

Si Biasini monto XP infatti il dubbio era se metterne il max quindi 3 gb oppure meno (1 o 2)...

[biasini]

Dipende dai thread in esecuzione e dal consumo di ram in determinati emulatori e a questo punto, dopo tante chiacchiere fatte in proposito, anche dall'eventuale utilizzo dell'ibernazione: se non arrivi ad utilizzare neanche 2gb, in un sistema con EFW + HORM ogni volta ricarichi da disco un immagine di 3Gb, di cui magari 1 e mezzo inutilmente.
Puoi sempre fare qualche esperimento in merito...

[CarloBlanch]

esperimento fatto: ho scaricato il Vpinball 173 mb circa, con l ' efw attivo, me ne ero dimenticato.
quando l' ho estratto il sistema è andato in crash.
Non conosco il messaggio, perché il monitor ha perso il sincronismo.
Ma era attivo chrome che consuma tanta ram.
Ho 2Gb di ram, il mio sistema però non è proprio pulito, perché uso la chiavetta wifi e il VNC per contollarlo dal portatile.
Quindi di memoria ne uso di più del solito.

[PaTrYcK]

173mb nn sono tanti, forse come dici il tuo sistema nn e' molto performante ma mi paiono cmq un po' pochini, x curiosita' potresti riprovare ad estrarre lo zip e leggere l'eventuale msg direttamente da remoto