Banda larga de 100 Mbps via FTTH da GVT (atualizado)

Quando soube que a GVT iria oferecer serviços de banda larga via fibra óptica, comecei a pesquisar para tentar descobrir qual tecnologia a empresa utilizaria: GPON ou active ethernet. Nesse processo, passei por vários fóruns, blogs e reportagens, que nem sempre divulgavam informações factíveis – a quantidade de "achismos" é muito grande.

Através da análise de informações colhidas da imprensa em geral e de algumas fontes da área de telecom, além da análise dos equipamentos utilizados pela empresa (nos postes, prédios, clientes, etc), é possível fazer uma espécie de "engenharia reversa mental" da rede da GVT.

Ao tentar entender a rede da GVT e fazer algumas inferências, percebi que a GPON não se encaixava naquele modelo. Em um dos fóruns pelos quais passei, uma pessoa escreveu como se tivesse certeza absoluta que a tecnologia utilizada pela GVT era GPON. Naquela época (há uns 2 ou 3 anos) a GPON, segundo algumas opiniões, estava quase se concretizando como o padrão de facto para fornecer triple play via fibra óptica no mundo todo – inclusive no Brasil. Entretanto, nunca vi a GPON fazendo sentido para uma empresa como a GVT, que desde o início de suas operações comerciais no ano 2000 já possuía uma rede NGN, que vem sendo expandida ano após ano.

Mas porque a GPON não faz sentido para a GVT? Segundo os proponentes das tecnologias xPON, a grande desvantagem do active ethernet é que ele necessita de componentes "ativos" no campo, isto é, equipamentos eletricamente ativos acomodados em gabinetes ou armários em algum lugar "nas ruas". E o custo de ter componentes ativos "nas ruas" é alto – isto é, necessita um capex (gasto inicial de capital) maior – o que tornaria a tecnologia não tão atraente do ponto de vista financeiro. Entretanto, esse é justamente o fator que torna o active ethernet atraente para a GVT, visto que ela já possui componentes ativos no campo – a infraestrutura foi criada assim desde o início da empresa.

Utilizando armários multisserviço, a GVT pode oferecer tanto voz quanto banda larga através das várias tecnologias oferecidas pela empresa, como ADSL, ADSL2+, VDSL2 e FTTH. Os armários da GVT geralmente ficam situados em lugares protegidos, como prédios residenciais ou comerciais e não "nas ruas". Sendo assim, adicionar um switch ethernet modular ao armário não é mais difícil ou complicado que adicionar módulos ADSL, ADSL2+ ou VDSL2. Mas como eu sei que a GVT utiliza armários multisserviço? Sinceramente, não achei nenhuma informação direta a respeito disso, mas é fácil inferir: se a empresa utiliza um mesmo armário terrestre para atender clientes com conexões ADSL, ADSL2+, VDSL2 e FTTH, esse armário só pode ser multisserviço.

Então, para a GVT, o active ethernet cabe perfeitamente em sua infraestrutura, ao contrário da GPON. Nenhum fator tecnológico impediria a GVT de utilizar GPON mesmo tendo componentes ativos no campo, mas se o propósito de utilizar splitters passivos - inerentes às tecnologias xPON - é justamente evitar o uso de equipamentos eletricamente ativos no campo, não faria nenhum sentido. Mas a prova definitiva de que esta inferência está correta veio quando achei este site, que confirma o active ethernet como a tecnologia FTTH utilizada pela GVT. Trata-se de um site com informações para investidores, onde constam informações públicas sobre a GVT, incluindo as tecnologias utilizadas pela empresa (esta informação está na página 33 do documento online).

Mas a melhor maneira de analisar estas informações e colocar as inferências à prova é utilizando a tecnologia em si. Ao contratar o serviço Power GVT de 100 Mbps (eles usam o termo "Mega", mas me recuso a fazer o mesmo) tive a possibilidade de conhecer um pouco mais sobre a infraestrutura da GVT.

No caso do FTTH, se o cliente é o primeiro a solicitar o serviço na área servida pelo armário correspondente (nem sempre é o armário mais próximo do cliente), a fibra é trazida do armário até uma "bolsa coletora" (ou fiber dome closure), instalada na rede aérea em frente ao endereço do cliente. A figura abaixo mostra a bolsa coletora instalada na rede aérea em frente a empresa.

A finalidade da bolsa coletora é trazer um ponto de conexão tanto para o cliente que solicitou o serviço quanto para futuros clientes na área. A partir dela sai uma fibra até o DG (Distribuidor Geral) da empresa – não porque necessite de uma conexão via DG, mas porque o DG é (geralmente) o ponto de entrada para os cabos de telecomunicação em um prédio – e dali até o local especificado pelo cliente para a instalação dos equipamentos.

O cabo de fibra que vem da bolsa coletora é então cortado e é realizada uma emenda a dois outros cabos (um para downstream e outro para upstream) conectados a uma interface mini-GBIC. Na foto abaixo, os dois cabos azuis estão conectados à interface mini-GBIC:

A interface mini-GBIC é então conectada a um conversor de mídia (foto abaixo), que converte o gigabit ethernet óptico em gigabit ethernet elétrico.

É interessante notar que a GVT optou por fornecer um link com capacidade de até 1 Gbps para os clientes FTTH, mesmo oferecendo um serviço de no máximo 100 Mbps. O motivo é óbvio: no futuro, velocidades maiores poderão ser oferecidas aos clientes, apenas utilizando o devido software de gerência da rede, desde que haja capacidade nos anéis (ou subanéis) ópticos que interligam os armários ao CO (Central Office). Prova disto, é esta matéria do Estadão, afirmando que a GVT pretende oferecer até 200 Mbps para assinantes residenciais nas novas redes metropolitanas sendo construídas (como em SP, por exemplo).

Outro fato marcante a respeito das escolhas tecnológicas da GVT, é que o protocolo utilizado para dar acesso ao cliente é o "bom e velho" ethernet: ao contrário da GPON, não existe necessidade de equipamentos customizados, caros e complexos (ONU/ONT) no lado do cliente, bem como camadas de protocolos complexos (ex. GFP) para encapsular o ethernet – apenas um conversor de mídia e ponto final. Aliás, se o cliente possuir um servidor ou roteador com uma interface gigabit ethernet óptica (1000BASE-LX/SX), nem precisará do conversor de mídia.

A GVT também fornece um roteador wireless em comodato, que pode variar de fabricante (assim como o conversor de mídia). No meu caso esse roteador não foi utilizado, uma vez que a interface gigabit ethernet do conversor de mídia foi conectada diretamente a um servidor proxy.

A autenticação é feita da mesma maneira que nas conexões xDSL – através de PPPoE. Basta configurar o usuário e senha do provedor (no caso da GVT, não é necessário um provedor externo – apenas se o cliente assim desejar) e a conexão é autenticada. Em tese, a autenticação não seria necessária, mas provavelmente aconteça por uma questão de segurança e/ou contabilização do acesso.

Depois de toda essa "teoria", a pergunta que permanece é: "e a qualidade do serviço?". Bom, neste quesito a GVT manteve o padrão que possui (pelo menos aqui na região Sul) – de muito bom à excelente. Sobre o padrão da GVT: a esmagadora maioria dos clientes GVT que conheço – incluindo a mim mesmo – está plenamente satisfeita com os serviços da operadora, tanto de telefonia quanto de banda larga.

Ao realizar o teste de velocidade da GVT (www.testepower.com.br) a velocidade não apenas alcança os 100 Mbps como quase sempre excede-os, como era de se esperar. Certa vez, a velocidade alcançada foi de mais de 500 Mbps. Entretanto, gosto de realizar testes de velocidade mais "realísticos", utilizando o www.speedtest.net ou mesmo efetuando download de imagens ISO de DVD (geralmente do Gentoo Linux, no mirror da UFMG). A figura abaixo representa um print screen de um teste realizado no servidor speedtest.net do PoP (Point of Presence) da RNP (Rede Nacional de Pesquisas) em Florianópolis, Santa Catarina:

Atualização: a figura abaixo exibe o print screen do teste realizado no servidor speedtest.net hospedado pela COPEL, disponível neste link, conforme sugestão do amigo Maurício Brixner:

Sendo que o contrato de serviço prevê 100 Mbps de downstream e 10 Mbps de upstream, esses valores podem ser considerados excelentes.

Já a figura abaixo mostra um download sendo realizado do servidor FTP da UNICAMP:

Com uma taxa de transferência de 8,3 MBps (megabytes por segundo), temos uma velocidade de 8,3 x 8 = 66,4 Mbps (megabits por segundo), ou 66,4% da velocidade máxima possível. Estes 8,3 MBps foram alcançados no pico da transferência – a taxa média ficou em 5,5 MBps. Obviamente, o fator limitante aqui foi o servidor FTP e não o link da GVT. A prova disto é que em outros testes já realizados onde foi efetuado download do mesmo arquivo, porém no servidor HTTP da UFMG, o pico da taxa de transferência alcançou pouco mais de 11 MBps (sendo que o máximo para 100 Mbps é 100 / 8 = 12,5 MBps).

A conclusão a que podemos chegar, baseando-nos nestes fatos, é que a GVT tem feito uma série de boas escolhas tecnológicas nestes 10 anos de operação, que proporcionam uma boa (senão ótima) qualidade de serviço aos clientes e que hão de proporcionar um caminho tranquilo para o futuro, inclusive com a oferta de IPTV, já anunciada em vários sites de notícias desde 2008 (por exemplo, aqui).

Alterando a cor das células de uma QTableView no Qt 4.7

Quando precisei achar alguma informação sobre como alterar a cor de uma célula em uma QTableView, fiquei surpreso com a falta de material "completo". Existem muitos posts pela Web sobre como realizar esta tarefa de diferentes maneiras, mas sem mostrar a solução na sua totalidade. Neste post, espero poder contribuir de maneira efetiva para a solução deste problema.

Ao criar uma aplicação para exibir registros de log de um firewall utilizando o framework Qt 4.7, tive a necessidade de utilizar uma QTableView para exibir os registros extraídos de um SGBD PostgreSQL. O objetivo era utilizar o tag (também podemos chamar de rótulo) de cada registro para definir a cor das células da QTableView utilizadas para exibí-lo. A figura abaixo mostra uma parte destes registros exibidos em uma QTableView, com uma cor por registro (ou uma cor para vários tipos de registros).

Na figura acima, os tags são mostrados na terceira coluna, após o campo "Hora". Dependendo do valor do registro contido neste campo, será definida uma cor para todas as células que compõe a linha (row).

O primeiro problema foi descobrir como se altera a cor de uma linha ou coluna de uma QTableView. A documentação do site não explica diretamente como realizar esta tarefa, mesmo no extenso artigo intitulado "Model/View Programming". Então, decidi pesquisar a API do Qt para encontrar os métodos (ou funções, como queiram) responsáveis por esta tarefa. Apesar dos exemplos, também não foi possível encontrar uma solução completa.

Aqui vale uma nota: "encontrar uma solução completa" não significa encontrar uma resposta pronta, do tipo "copiar e colar", mas de uma orientação ou exemplo que fosse objetivo, mostrando como esta tarefa poderia ser realizada. Por exemplo, ao ser deparado com um problema semelhante em Java ou C#, a informação foi encontrada mais rapidamente, e a solução foi mais direta.

No final das contas, existem duas soluções "aconselháveis" para resolver este problema: criar uma subclasse da QTableView ou uma subclasse do QItemDelegate (responsável por renderizar as células de uma QTableView) e reimplementar um determinado método. Optei por criar uma subclasse do QItemDelegate e reimplementar o método paint, e esta será a solução demonstrada aqui.

Em primeiro lugar, é necessário criar uma subclasse do QItemDelegate (chamada "ColorDelegate" no exemplo), começando pelo header:

A seguir, a implementação:

Outra nota: a intenção deste post não é ensinar melhores práticas de engenharia de software ou ensinar como programar em C++ utilizando o framework Qt ou sequer afirmar que esta é a única (ou a melhor) solução para este problema, mas simplesmente mostrar de uma maneira direta e completa uma das soluções possíveis. Sendo assim, o código aqui apresentado é uma simplificação do código de produção, a fim de torná-lo mais objetivo.

Antes de poder alterar a cor de um conjunto de células, seria necessário buscar o tag na sua devida célula. Acontece que o método paint do delegate é utilizado pela QTableView para renderizar cada uma de suas células. Se o tag está inserido na terceira coluna de uma linha, como é possível alterar a cor das células já processadas, da primeira e segunda colunas? Este era o segundo problema.

A solução está na linha 16 da implementação: é necessário buscar o modelo que está alimentando a QTableView, e então buscar os dados deste modelo. Uma vez que temos acesso aos dados do modelo, basta buscar o registro desejado através do seu índice. O método index() do modelo necessita de dois parâmetros: linha (row) e coluna (column). A "linha" é a linha do modelo que está sendo processada pelo delegate – acessada através do método row() do QModelIndex fornecido como parâmetro – e a "coluna" é a de número dois (a primeira coluna é a de número zero).

Uma vez que o tag é encontrado, pode ser utilizado para decidir qual cor aplicar às células. A partir da linha 19 temos uma série de if ... else if que atribuem a cor das células baseados no valor do tag. É importante notar que na comparação de igualdade do tag com as strings pré-definidas (linhas 19, 22 e 24) é uma boa prática usar a classe QLatin1String de forma a evitar hidden mallocs, conforme demonstrado neste site.

Na linha 29 é decidido se a cor do texto exibido na célula deve ser invertida – isto é, definida como branca ao invés de preta – para torná-la mais legível. Dependendo da cor aplicada ao tag será necessário inverter a cor da fonte.

Na linha 34 é definido o alinhamento do texto dentro da célula – neste caso, o texto é alinhado ao centro, tanto horizontalmente (Qt::AlignCenter) quanto verticalmente (Qt::AlignVCenter).

Na linha 37 a célula é efetivamente preenchida com a cor definida, e na linha 40 o método paint da classe pai (ou superclasse) é invocado para continuar a renderização da célula.

Também vale notar que as operações de alteração de cor e alinhamento do texto da célula são feitas sobre uma cópia do objeto QStyleOptionViewItem informado como parâmetro, uma vez que ele é const e não permite alterações.

Após ter criado a classe ColorDelegate, basta atribuí-la à um objeto QTableView previamente criado. Abaixo é demonstrado um exemplo simplificado deste processo:

Para concluir, gostaria de enfatizar que os exemplos aqui demonstrados também não são do tipo "copiar e colar". Entretanto, acredito que tudo que é necessário para permitir a customização na renderização das células de uma QTableView foi demonstrado.