Dopo aver installato Quake Wars dal DVD usando la patch 1.2, ho messo a confronto i tre sistemi Linux a 32bit installati sul mio Asus A6Tc; era giunto il momento di verificare effettivamente quali livelli di prestazioni poteva raggiungere il portatile, anche se avrei voluto compiere questo test molto tempo fa, poiché lo comprai nell’estate del 2006 (magari con Doom 3 o Quake 4). Sul banco di prova ho messo così la distribuzione OpenSUSE 10.3, Linux From Scratch 6.2 e Linux From Scratch 6.3. Soltanto questi ultimi due sistemi avevano l’opzione CONFIG_HZ_1000 e il modello preemption LOW LATENCY, dato che ne suggeriva l’attivazione Timothee Besset sia per il server che il client di Quake Wars. OpenSUSE usava invece il parametro CONFIG_HZ_250 e un modello preemption VOLUNTARY ma, come ho potuto già osservare in precedenza (rif. OpenSUSE 10.3, distro tuttofare), sono caratteristiche che non hanno spinto piu’ di altre il gioco. Le versioni del kernel erano 2.6.16.26, 2.6.23.1, 2.6.22.5-31 rispettivamente per LFS 6.2, LFS 6.3 e OpenSUSE. Eccetto LFS 6.3 che usava la versione 100.14.19, sugli altri due sistemi era installato durante il benchmark il vecchio driver 1.0-9755, dimostratosi “affidabile” per tutto il 2006 e 2007.
Il driver 1.0-9755 non si installava su Linux From Scratch 6.3, a causa di incompatibilità con la versione del kernel. Mi è dispiaciuto questo perché la serie 100.XX.XX faceva i capricci mentre girava il
timedemo. Avvenivano congelamenti dello schermo improvvisi e fatali che mi lasciavano di fronte a una sola alternativa per riavere il controllo sul sistema… riavviare (si legga anche Zander in “
100.14.19 nvidia geforce go 7200 flashing and freezing“).
L’opzione
irqpoll per il kernel pare risolvere parzialmente il problema, per lo meno ora avvengono solo brevi interruzioni, della durata di 2 o 3 secondi mediamente, dei programmi in esecuzione. Per questo motivo dai diagrammi LOW QUALITY il LFS 6.3 esce con un rendimento peggiore rispetto agli altri due sistemi analizzati; esso ha un deficit anche di 4 FPS.
Dunque la patch 1.2 installa Quake Wars automaticamente dal DVD; quando si carica il gioco per la prima volta, occorre creare un account online, ovvero scegliere un nome e una password che identificheranno il giocatore nelle gare sui server con le statistiche (RANKED).
La demo usata nelle prove era stata registrata per circa tre minuti con il comando toggleNetDemo (F12) durante la terza fase di una partita in corso sulla mappa Salvage. In essa l’azione si svolgeva sia all’interno degli edifici che all’esterno e quindi secondo me era perfetta per valutare il comportamento dell’engine con diversi livelli di dettaglio, illuminazione e ambientazione. Per un minuto ho sorvolato come spettatore la zona dove la guardia GDF faceva il suo ingresso nel gioco, nei pressi della struttura di salvataggio delle informazioni top-secret (Salvage). Dopo di che sono passato a osservare l’azione dal punto di vista del giocatore, in First Person Shooter come si suol dire, cambiandola spesso repentinamente.
Il comando timeNetdemo carica una partita precedentemente registrata e al termine calcola il frame rate medio. L’ho eseguito con configurazioni diverse, ma stessa risoluzione schermo di 800×600 pixels: la prima per ottenere una qualità grafica il piu’ povera di effetti e dettagli, la seconda con valori impostati a “normal” nella maggior parte delle opzioni disponibili, per avere una grafica di buona qualità. Ho ripetuto due volte il timedemo per ciascuna configurazione e i tempi di caricamento della mappa variavano, a seconda delle distribuzioni esaminate, da 58 a 64 secondi (senza cache).
Con OpenSUSE ho preferito scaricare dalla memoria XDM e lanciare Quake Wars direttamente da una console con
(startx :0 -- /usr/games/etqw/etqw)
Tuttavia un ulteriore test l’ho condotto in una finestra dell’ambiente GNOME e Compiz-Fusion, con un risultato che non dico sia considerevole, ma neppure oso scartare: 29.3 Frame per Secondo.
Quando registro una partita, il file viene salvato con estensione ndm in $HOME/.etqwcl/base/demos, per caricarlo con timeNetDemo è sufficiente però passare il nome del file, per esempio
timeNetDemo Salvage
Di solito i nomi dei file sono demo_00000.dnm, demo_00001.dnm, e così via. Nell’esempio ho usato Salvage, perché avevo precedentemente rinominato demo_00000.dnm.
I sistemi hanno restituito valori simili con entrambe le configurazioni, anche se mi sarei aspettato qualcosa di piu’ da LFS, perché aveva nel kernel i parametri suggeriti da TTimo per migliorare le prestazioni generali. LFS 6.2, LFS 6.3 e OpenSUSE occupavano tre partizioni root sul disco rigido da 80GB del portatile, mentre il gioco e i dati dell’utente stavano su due partizioni separate del disco rigido esterno; si tratta di un disco da 200GB alloggiato in un LAN Drive di Extreme Technology collegato alla porta USB 2.0. Nel diagramma 40 FPS sono segnalati con il colore arancione, perché non lo ritengo, in base alla mia esperienza, un valore accettabile per giocare online (nota: quando offline l’engine è bloccato a 30 FPS). La mia scala di misura dà invece il via libera (segnalato con il colore verde) attorno a 64 FPS, per salire verso l’ebrezza totale (colore blu) degli 80 FPS e oltre.
C’era da aspettarselo, a qualità media i valori calcolati da timedemo si sono quasi dimezzati per tutti i sistemi. In questo caso LFS 6.2 ha primeggiato con 22.2 ma le differenze erano, ancora una volta, minime.
