Zapping Time

[lemene]

Fui medir o QoE (Quality of Experience) e QoS (Quality of Service) na mudança de canal.
Já tinha feito uns testes por aí perdidos como este tópico.

Quando mudamos canal há esta troca de mensagems:
Origem BOX: IGMP V2 Leave Group <actual_ip_do_canal>
Origem BOX: IGMP V2 Membership Report / Join group <novo_ip_do_canal>

Entre estas mensagens poderão existir outras mensagens UDP:
- uma ou duas com um frame destinado ao canal anterior conforme exemplo abaixo;
- um vazio com cerca de 6 frames de controlo, omitidos mas que contabilizados nos tempos.

Exemplo
Destino ...:: Protocolo ::.... Informação
224.0.0.2 :: IGMP V2 Leave Group 232.0.21.150..[delta: 0.000391000 sec]
232.0.21.150 :: UDP..........................................[delta: 0.001116000 sec]
232.0.21.150 :: UDP..........................................[delta: 0.001965000 sec]
232.0.21.25 :: IGMP V2 Join group 232.0.21.25....[delta: 0.207682000 sec]
232.0.21.25 :: UDP............................................[delta: 0.044863000 sec]
-----------------------------------------------------Soma: 0.256017 sec


Efectuei 7 zappings sem que a box perdesse algum e obitve estas médias:
- 0.030235167 sec, Leave Lactency, tempo desde o ultimo frame do canal anterior ao pedido de abandono.
- 0.175921429 sec, tempo para que se peça o Join Group ao novo canal.
- 0.088279 sec, Join Lactency, soma ao tempo que leva o primeiro frame do canal novo.
- 0.267496143 sec, ZAP Time, desde o abandono até surgir o primeiro frame do canal novo.
- 0.003295714 sec, é a media de outras mensagems UDP quer surgem no meio.

O grande guloso é o tempo para se juntar (JOIN GROUP) ao novo canal mais a latência até o receber.

Que mais factores estão aqui dados a estes valores:
- buffer da box não parece ser o problema.
- DSLAM ocupado.
- fragmentação do MPEG2 em vez do optimizado MPEG4

Resultado QoE e QoS:
Do ponto de vista de QoE o resultado é uniforme em vários testes e como tal aceitável,
já o QoS o desempenho da mudança de canal LEAVE/JOIN é razoável, mas podia ser melhorado 0.267496143 sec. de ZAP Time,
O resto na mudança de canal o QoS do serviço é mau atinge ~2s.

Edit: "O IGMP Membership Report / Join group" é ainda um pedido para se juntar ao grupo do novo canal.
Edit2: Por um lapso estupido tratei os 0,26sec como 2 secs (enfim), corrigi e acrecentei a parte que faltava e responsável pelos 2 secs a seguir.
_________________
ooo(@@)ooo
|||||||||||||||
http://www.aquinaoentras.haha
http://vaestamaisfacil.eheh

[AdSense]

[Dracula]

Na minha opinião, creio que a box faz algum buffering, antes de começar a fazer o display do canal. Aliás, é notório que primeiro vem o som, seguido de uma imagem parada e finalmente imagem em movimento.

Creio que o problema está mesmo na forma com o software trabalha na box, para fazer este buffering, antes de fazer o output da imagem...

Mais uma vez continuo convencido que a plataforma corre em java, por cima de um SO linux, sendo isso que contribui para esta maior lentidão (o java, não o linux)
_________________
Be sure to engage your brain before open your mouth!

[lemene]

Sim, todo o SW deverá ser javascript

Pode ter algo haver com buffering, mas no sentido limpar, pois pelos meus testes a demora está entre o abandono e o pedir novo canal.

A acreditar no wiki há vários factores.
http://en.wikipedia.org/wiki/Zap_time

Já agora cada Box pelo seu respectivo IP/MAC pedirá para se abandonar e juntar a determinado grupo (canal).

Source ................... Dest
172.17.177.XXX ....... 232.0.21.25 ...... IGMP V2 Membership Report / Join group 232.0.21.25

Já que o DSLAM adiciona e corta os canais a enviar ao cliente.
Não sei se isto torna mais rapida a mudança de um canal onde a outra box já a recebe.
_________________
ooo(@@)ooo
|||||||||||||||
http://www.aquinaoentras.haha
http://vaestamaisfacil.eheh

[lemene]

A informaão do referido link do wiki pode ser melhor entendido por um PDF da Cisco.
http://www.teamlightbulb.com/Rajah%20Cisco.pdf

Numa imagem da página 6 circulo a cores vermelho, amarelo e verde onde está a demora com base nos meus testes.


Os piores tempos estão relacionados com a gestão dentro da STB (box).

~0.17sec, com circulo amarelo, delta entre o LEAVE e o JOIN do canal que ocorre na STB, que inclui limpeza de buffer antigo.

~0.08sec, com circulo verde, delta relacionado com a rede (NETWORK) e com a lactência do LEAVE/JOIN à chegada do primeiro pacote.

~2sec com circulo vermelho e com base na percebção, representa o buffering da imagem completa e o decoding. Muito por culpa do tratamento ao MPEG2.

Neste PDF e outros documentos realçam a importância do buffer na aceleração do decoding que é feito à posterior e na qualidade de imagem sem jitter.

A solução da cisco passa por durante o zapping haja unicast do canal a mudar a custo de maior largura de banda e depois voltar normalmente ao multicast.
Complicado.
_________________
ooo(@@)ooo
|||||||||||||||
http://www.aquinaoentras.haha
http://vaestamaisfacil.eheh