PT-CODE

Este texto surge na sequência de um processo de optimização na “Região Portugal Lisboa” do Second Life, onde está localizada a sede do PT-Code In-World.  Frequentemente os utilizadores queixam-se de problemas de performance, e do tão odiado “Lag” que causa a lentidão. É aquela sensação de avatares “congelados” ou a “patinar em seco”, com o Mundo cinzento ou parado à sua volta.

Certamente que todos os utilizadores regulares do Second Life,  já ouviram expressões como “está um Lag desmedido hoje!” ; “o meu avatar não se mexe com tanto lag” ; “neste Sim depois das 22:30 ninguém se mexe” ou  ”estavam tantos avatares, que o sim crashou”…

Antes de mais, é necessário entender o que é isso do “Lag”, e quais as suas causas,  para depois se encontrarem soluções,  tanto ao nível do viewer (Navegador do SL), como ao nível do servidor (onde são armazenados, geridos e feita a simulação dos conteúdos da região).

Mas afinal o que é isso do LAG?

Em termos muito gerais e simplistas, Lag é um termo em inglês, que se refere a atrasos verificados na comunicação entre computadores, como por exemplo um cliente e um servidor,  que muitas vezes levam a observar fenómenos de congelamento de texto, imagens ou soluços em vídeo.

No caso específico do Second Life, o Lag pode ser causado por  diversos factores de diferentes naturezas, ou mesmo pela conjugação desses mesmos factores:

• Sim - Diminutivo de simulador – as àreas quadradas de terreno que aparecem no mapa também chamadas de regiões, e os servidores em que  correm
• edfaHardware - PC do utilizador
• Rede -  Largura de banda ou tráfego da ligação à Internet ou aos servidores do Second Life
• Cliente - Configuração das características de navegação ou visualização no Viewer do utilizador

O facto de  o Lag ser normalmente uma experiência conjunta, sentida  por todos os avatares que se encontram num determinado Sim ou Região, pode levar à ideia errada de que “a culpa” é do próprio “Sim”, ou da quantidade de Avatares. Isso nem sempre é verdade, como teremos oportunidade constatar mais à frente neste texto.

Posso ser só eu sentir “Lag” enquanto os outros estão sem problemas? Porquê?

Na simulação do Mundo Second Life há uma clara separação de “responsabilidades” entre o a grid(conjunto de sims/servidores) e o cliente(viewer). Há coisas que causam trabalho ao cliente e que não dão trabalho ao sim, e vice versa. Por exemplo objectos(prims) flexíveis e a iluminação (Luzes), são um bom exemplo disso.O sim não se importa se o objecto é flexível ou não, pois no sim, são tratados como objectos rígidos iguais aos outros.É o cliente que se encarrega de criar a ilusão de flexibilidade e movimento do objecto.O mesmo se passa com a maioria dos scripts de rotação. O sim não lhes presta atenção  a menos que seja mesmo mesmo necessário, o que normalmente não acontece.É também o cliente que se encarrega disso. Por outro lado, scripts que causem outros movimentos dos objectos e simulação de física,  requerem mais esforço e trabalho do sim.

Tal como o PC do utilizador que corre o viewer, também o servidor que corre o sim  tem uma capacidade limitada. O servidor tem um relógio interno que bate 45 vezes por segundo. Em cada uma dessas batidas, tem de ser gerido toto o trabalho necessário, para não causar atrasos na simulação. Tudo tem de ser actualizado desde que a batida anterior finalizou o processamento. A estas batidas passaremos a chamar “frames”, e serão medidos em frames por segundo(fps) , embora não se trate dos frames por segundo que se fala habitualmente num video ou cinema.Neste caso trata-se de frames por segundo em termos de tempo de processamento.

Facilmente podemos concluir, que para o servidor fazer as coisas “a tempo e horas” e fazer 45 actualizações num segundo, é necessário que faça cada uma dessas actualizações em 0.022(2) segundos, ou seja em menos de 22.3ms (milissegundos). Assim sendo, tudo o “stress” aplicado ao sim, tanto por complexidade, quantidade, ou características dos objectos ou avatares(Agentes), poderá impedi-lo  de fazer tudo em menos de 22,3 ms, e causará Lag.

Exemplo prático

Podemos agora ilustrar com um exemplo prático, o modo como se poderá fazer uma análise estatística, detalhada do comportamento do Second Life e  motivos que possam causar lag. Em primeiro lugar, é necessário entrar no Second Life, e pressionar a combinação de teclas SHIFT CONTROL 1ou então ir ao menu view(ver) -estatísticas(statistics). O respectivo painel irá aparecer de imediato no lado direito do ecrã. Repetindo o mesmo procedimento, fará desaparecer o painel.

 fig.1

  Simulador

Na parte superior, abaixo da Zona Simulador, poderemos encontrar um conjunto de indicadores que serão uma preciosa ajuda para determinar o comportamento do simulador e identificar eventuais factores causadores de Lag.

• Time Dilation- A taxa  de simulação física em relação ao tempo real. 1.0 significa que o simulador está a correr à velocidade total; 0.5 significa que a simulação física é feita a metada da velocidade.Em termos práticos será ver os objecto físicos em “camara lenta”
• Sim FPS - Taxa de actualização do sim. Deverá sempre ser 45.0 se tudo estiver a correr bem.
• Physics FPS- É a taxa de actualização do motor Havok. O normal , é um valor de 45.0.
• Agent Updates/Sec - É a taxa de actualização dos agentes no sim. O normal será 20 actualizações por segundo, e irá decrescer se o sim tiver muitos avatares ligados.
• Main Agents- Número de agentes (avataress) presentes no simulador.
• Child Agents- Número de agentes que não estão no sim, mas que o podem ver.Por exemplo Avatares nos sims vizinhos.
• Objects- Número total de prims(primitivas) do simulador.Não estão as prims vestidas ou anexadas aos avatares.
• Active Objects- Número de objectos contendo scripts activos no sim.Não inclui scripts anexados aos avatares.
• Active Scripts - Número de scripts a correr no sim nesse momento,incluindo scripts anexados aos avatares.
• Script Events - Número de instruções LSL de scripts  executados no ultimo segundo no sim.
• Packets In – Pacotes UDP que estão a ser recebidos pelo sim.
• Packets Out – Pacotes UDP que estão a ser enviados pelo sim.
• Pending Downloads- Número de downloads de inventário que estão à espera para baixarem para o servidor.Se este valor for superior a 1, isso significa que há atrazos a largar(rezzing) objectos a partir do inventário.
• Pending Uploads- Numero de recolhas de objectos para o inventário que estão pendentes.Valores diferentes de 0 indicam também problemas nos “teleports”.
• Total Unacked Bytes -Dimensão dos dados em espera entre o viewer e o sim. Um valor elevado aqui revela problemas na comunicação entre o viewer e o sim.

Tempo

Na zona posterior da figura 1, encontramos a secção “Time”, que nos dará um conjunto de indicadores, que possiblitam determinar com exactidão as causas dos atrasos na taxa de actualização. Clicando uma vez e ainda outra sobre o título dos indicadores o painel irá expandir-se, e mostrar uma ilustração gráfica do indicador respectivo.

fig.2  

• Total Frame Time – É o somatório de todos os tempos em milisegundos. conforme já foi explicado, se fôr 22.4ms,  então o sim estará com um pouco de Lag. 22.3ms significa que o simulador está com a capacidade esgotada.Se este número for 22.3ms ou menos, isso significa que o simulador está sem Lag.
• Net Time - É o tempo dispendido na comunicação através da rede entre o sim e outros sims, outros servidores ou com o cliente. Na arquitectara de base do simulador Second Life este valor era aumentado se estivessem clientes lentos ligados ao sim ou clientes com pouca largura de banda. Desta forma involuntária todos os utilizadores são afectados com lag causado por outros clientes, uma vez que todo o sim é afectado. Não encontrei documentação que indique que esta situação tenha sido alterada.
• Physics Time  - É o tempo gasto pelo simulador de fisica  Havok.Com o motor de física Havok 1 esta situação era demasiado complicada em termos de Lag. Qualquer simulação de física para um simples object poderia causar atrazos dramáticos nos fps do sim. com a introdução do motor Havok 2 a simulação física tornou-se numa coisa muito mais leve e foi reduzido o Lag.Não deverá ser mais de 5 milisegundos.
• Simulation Time   - Indica o tempo de processamento necessário para movimentos do Avatar, estado do tempo, sistemas de nuvens e WindLight, posição do sol e da lua , etc.
• Agent Time -Tempo gasto na transmissão ao Agente/avatar das actualizações dos objectos. dados das prims, posições , anexos , etc. é também contabilizado aqui o tempo de rede (Net time) para as operações aqui descritas.
• Images Time- Tempo gasto com transmissão de texturas e respectivo tempo de rede, é também contabilizado aqui.
• Script Time -É o tempo dispendido pelo sim com o processamento  de scripts. Não necessariamente a correr os scripts mas a gerir a memória , os eventos “listens” e etc.Não existem regras práticas para redução de Lag nos scripts.Alguns scripts cheios de timers sensores e “listens”, poderão ter pouco impacto no Lag global do simulador e alguns scripts simples podem ter um impacto dramático se forem usados de forma errada ou maliciosa.Aqui tudo depende da experiência e conhecimento do programador. Com a introdução do Mono, a gestão de memória e processamento dos scripts passou a ser centenas de vezes mais rápida e eficaz, e o limite de 16 Kb deixou de existir.

Uma análise detalhada, observação e registo de todas estas variáveis, permitirá ao responsáveis pela performance e aos técnicos uma melhor compreensão sobre os eventuais congestionamentos de Lag, e permitirá identificar, se o Lag apregoado pelos avatares tem a ver com o viewer, a rede de comunicação com a Linden Lab ou o servidor/sim.