Da più parti sento echeggiare periodiche lamentele per il lag che affligge la nostra land. Lo sento da commenti diretti, da segnalazioni di amici e amiche, e qualche volta anche da dialoghi che gli SPY inseriti nei collari delle mie ragazze mi riportano. La nostra engineer, Pene Seetan, creatrice di quasi tutti gli script della prigione (e socia di Andromeda nella realizzazione di apprezzatissime trappole e gabbie RLV, alcune delle quali vedete nell’immagine in chiusura di post) ha fatto una ricerca per capire quale fosse il problema, e ha inviato alle responsabili del WCF un rapporto dettagliato. Lo traduco qui sotto per chi fosse interessato, perché la verità è che, come accade spesso, il lag è quasi sempre nell’occhio di guarda! Prima di lasciare la parola a Pene, segnalo però a chi parla inglese una pagina utilissima che mi è stata segnalata su Facebook la scorsa settimana, e che offre numerosi suggerimenti per alleggerire il compito al proprio processore, migliorando notevolmente la performance del client di Second Life. Concludo con un’ultima segnalazione che riguarda il Green Life Emerald Viewer, che in tempi recenti si è diffuso a macchia d’olio anche nella nostra land (io per prima ne sono stata sponsor). Dopo una conversazione con Marine Kelley, personalmente ho deciso di abbandonare l’Emerald per tornare al classico Restrained Life Viewer, oppure al Cool Viewer di Boy Lane. L’Emerald NON usa il codice di Marine e chi lo adotta rischia quindi di esporsi a bug su cui la Kelley non può e non vuole garantire il funzionamento impeccabile dei suoi prodotti. Ritengo che chi usa il RLV farebbe bene a fare altrettanto, utilizzando un client come il RLV – collaudato e aggiornato con passione costante dalla stessa persona che ha inventato per noi il concetto stesso di Restrained Life. Ma ora mi taccio e faccio un passo indietro. Grazie, Pene Seetan: ti ascoltiamo.

(Un effetto molto singolare del lag, ma che descrive bene il mio attaccamento per Lella)

Il Lag è la piaga di tutte le nostre esistenze…

In occasione delle lamentele di alcune persone che hanno crashato entrando nella sezione oasi vicino alla prigione, ho fatto un’indagine sul lag di Winsconsin. Si direbbe che ci siano molti errori nel capire che cosa voglia dire lag. La gente registra una reazione lenta del suo viewer e presuppone che la regione abbia un problema di lag sul lato server.

Che tipi di lag esistono?

Lag è il termine colloquiale con cui si indica un tempo di reazione lento quando si usa Second Life. Ma a provocare il lag ci possono essere tre diversi livelli di cause. Il client, la rete (network) e i server linden. Il lag basato sul client deriva dall’hardware dei computer (memory/cache), dalla performance della cpu e dai settaggi grafici. Il lag della rete-network dipende dalla qualità della connessione internet. Infine, il lag da server è determinato dal conteggio nella regione degli oggetti fisici, dal numero degli agenti, naturalmente, dal conteggio dei cambiamenti di texture e da quello degli script attivi (tempo di esecuzione).

Usare il lag meter (nel menu del vostro client: Help-> Lag Meter):

Il lag meter è uno strumento meraviglioso e semplice che consente a chiunque di determinare quali siano i propri problemi di lag. Mostra in modo visivo lo stato di ciascuno dei tre livelli sopra indicati, e dà un messaggio testuale quando si incorre nel lag. Nell’entrare in alcune aree di Winsconsin otterrete segnalazioni di lag per il livello client. Dapprima, il viewer deve caricare le texture necessarie a visualizzare l’ambiente. Quindi arriva l’allarme lato client: “Too many complex objects in scene” (Troppi oggetti complessi nell’ambiente).

Che cosa significa? Beh, che il client non è in grado di renderare un numero sufficiente di fotogrammi al secondo perché la scena contiene molti oggetti – pertanto il client riesce a generare meno fotogrammi al secondo, e quindi i movimenti rallentano e la reazione del viewer mostra dei difetti.

PER FAVORE, PRENDETE NOTA DEL FATTO CHE SI TRATTA SOLO DI UN PROBLEMA  DI PERFORMANCE DELL’HARDWARE DEL COMPUTER E DEI SETTAGGI DELLA GRAFICA, E NON UN PROBLEMA DEI SERVER!

Provate voi stessi questo esperimento: quando vi accorgete di avere un frame rate basso (pochi fotogrammi al secondo, o FPS), limitatevi a puntare la camera verso il suolo. Vedrete che il frame rate aumenta subito e che la reazione del viewer torna ad essere normale.

Non starò qui a spiegare come fare ad ottimizzare i settaggi del viewer per risolvere questi problemi e non voglio discutere con quelli che usano viewer alternativi. Ci sono già abbastanza bug nel client originale di Second Life!

Usare il pannello delle region statistic per avere dettagli (nel menu del vostro client: View->Statistic Bar):

Nel pannello delle statistiche troverete altri dettagli importanti sulla performance della regione dal lato server. I valor importanti sono la Time dilation, il SimFPS (fotogrammi al secondo nella Sim) e lo script time. (http://wiki.secondlife.com/wiki/Statistics_Bar_Guide).

Ho fatto qualche paragone con Stonehaven. Ho registrato periodicamente, per poterli analizzare, il conto degli agenti, la time dilation e il SimFPS. Stonehaven è una regione utile per fare confronti perché ha un rapporto simile al nostro nel conteggio degli oggetti e quello degli script attivi, e so che il proprietario dedica molto tempo a mantenere sana la sua regione. Ecco alcuni risultati.

Quello che si vede nella immagine qui sotto sono i fotogrammi al secondo della regione, lato server, in situazioni diverse. (Il massimo è di 45 fotogrammi al secondo, che equivale a una salute del 100%)

La curva WCF-A l’ho registrata una settimana fa. La curva WCF-B mostra la situazione dopo aver disabilitato le collisioni. Infine, la curva WCF-C è stata registrata dopo aver ripulito l’area oasi. L’ultima curva (SH) è stata registrata a Stonehaven per avere un metro di paragone. Le parti depressionarie delle curves sono causate da agenti in arrivo e da agenti che stanno lasciando la regione. I valori statistici medi per questi dati sono:

WCF-A =42.72 FPS.
WCF-B = 42.15 FPS.
WCF-C = 41.56 FPS.
SH = 41.76 FPS.

Come si vede, non ci sono cambiamenti significativi fra questi valori.

Il conto medio di agenti all’interno della regione era di 13 durante ciascuna registrazione.

Conclusioni e suggerimenti:

–   In rapporto al conteggio degli script attivi (e a Winsconsin ce ne sono molti), la regione è sana.
–   Non è possibile far crashare il viewer di qualcun altro mediante script.
–   Per rendere le cose più facili a quelli che hanno computer lenti, gli ambienti più complessi potrebbero essere ricostruiti rimpiazzando le palme sculpted con cubi di legno.
–   La gente che racconta storie sul lag andrebbe tradotta in cella o, semplicemente, sculacciata.

Cordialità,
Pene