Configurando o modem SpeedStream 4200 para ADSL2 mais confiável

Complementando um post recente em inglês sobre o assunto, segue uma dica derivada das minhas desventuras recentes com ADSL2. Em resumo, se a sua ADSL estiver com aparentes problemas de lentidão, isto pode ser causado por excesso de perda de pacotes, e uma forma de tentar diminuir eesta perda é desligar o modo ADSL2+ no modem, deixando apenas como ADSL2 (sem o sinal de +).

Cada modem tem uma forma de fazer isto. O D-Link 500B permite fazê-lo via Web mesmo. O SpeedStream 4200 só permite alterar o modo ADSL padrão via Telnet, e não encontrei um manual dos comandos Telnet. Mas pelo menos existem dicas de como alterar a configuração:


O script acima é exatamente o que fiz com meu modem. Esta simples alteração dobrou a relação sinal-ruído, de 6 para 11dB (depois vou oferecer uma explicação dos porquês).


Outros modos DSL do modem


O SpeedStream tem diversos modos ADSL a escolher:


Cada telecom implementa apenas alguns protocolos, portanto apenas um subconjunto das opções disponíveis vai funcionar. As opções interessantes são:

AUTO: o nome diz tudo, e é o padrão que vem com o modem. Aqui esta opção faz o modem escolher ADSL2+, o que no meu caso causa muitos erros e perda de pacotes.

AD2P: ADSL2+, velocidade máxima de 24Mbps.

DSL2: ADSL2 sem o sinal de +, velocidade máxima de 12Mbps.

DMT: ADSL1, codificação DMT (o padrão mais comumente utilizado).

ANSI: ADSL1, codificação ANSI (não é o padrão mas funciona).

LITE: ADSL1 "lite", limitada a apenas 1,5Mbps e mais robusta.

RED2: RE-ADSL2, um anexo da ADSL2 com alcance melhorado. Muitas telecoms não implementam-no por usar mais energia e causar mais crosstalk (vazamento de sinal para fios paralelos no cabo). Ativar este padrão aqui simplesmente faz fallback para ADSL2.

Embora alguns posts mundo afora recomendem configurar o modem para ADSL1 quando a ADSL2+ estiver com muita perda de pacotes devido a erros, é mais vantagem tentar ADSL2, que usa a mesma largura de banda da ADSL1 e tem correção de erros mais forte. Talvez haja um motivo para tentar ADSL1 em lugar de ADSL2 numa linha ruim, mas não consigo imaginar nenhum.

O único modo ADSL1 que pode ser interessente é o "Lite", lento e robusto, que ao contrário do RE-ADSL2 parece ser suportado pelas telecoms daqui, já que foi o padrão utilizado nos primórdios da banda larga. No meu antigo plano ADSL1, o modo "lite" era o único no qual o D-Link 500B conseguia funcionar com uma taxa de erros tolerável. (O modem 3Com funcionava perfeitamente na mesma linha, sem tocar na configuração.) Num caso extremo, este modo pode significar a diferença entre ter e não ter banda larga.


Por que é importante diminuir a taxa de erros?


O quadro abaixo é um screenshot das estatísticas do meu modem ADSL, o SpeedStream 4200:


Note que o mesmo número de erros -- onze -- aparece em dois quadros diferentes: ATM e AAL. Porém quase 2 milhões de pacotes ATM, ou melhor, células ATM foram trafegadas, enquanto o número de pacotes Internet (PDUs) é apenas 94217.

Num nível muito baixo, a tecnologia ADSL é baseada no protocolo ATM, cujos "pacotes", chamados de células, têm tamanho fixo de 53 bytes -- 5 de cabeçalho mais 48 de dados. Como os pacotes Ethernet e TCP/IP costumam ter tamanho variável de 32 a 1500 bytes, diversas células ATM podem ser necessárias para transportar um pacote TCP/IP.. Esta quebra e remontagem de pacotes é especificada pelo protocolo AAL5 (ATM Adaptation Layer 5), e a responsabilidade de implementar o AAL5 é sempre do modem ADSL, mesmo em modo bridge.

O uso de ATM e AAL5 é a causa de diversas "esquisitices" da ADSL. Primeiro, você paga pela banda "bruta", sobre a qual trafega ATM. Como o overhead de cada célula de 53 bytes é 5 bytes, de cara há uma perda de 10%. Em cima disso há as perdas do AAL5, do PPPoE, e a taxa líquida vai ser 16% menor que a taxa bruta.

Segundo, cada pacote TCP/IP, por menor que seja, vai dar causa ao tráfego de no mínimo 2 células ATM, totalizando 106 bytes "no fio". Aplicações que usam muitos pacotes pequenos como Skype e VoIP comem muito mais banda do que poderíamos supor. Se uma aplicação VoIP usa pacotes de 64 bytes e trafega 100kbps, isto vai representar perto de 200kbps "no fio".

Terceiro e pior de tudo, o protocolo AAL5 não retransmite pacotes perdidos (enquanto outros padrões como AAL3 e AAL4 parece que o fazem). Se uma célula ATM for perdida devido a erros, ruídos etc. o pacote TCP/IP a que ela pertencia também estará perdido. Se por azar a célula perdida for a última, que "fecha" o pacote TCP/IP, dois pacotes estão perdidos: o que estava sendo remontado, e também o próximo.

Como um pacote TCP/IP de 1500 bytes consome 31 células ATM, uma taxa de erros de apenas 0,3% na camada ATM significará uma perda de 10% de pacotes no nível TCP/IP. Há uma "amplificação da taxa de erros". E quem conhece um pouco de TCP/IP sabe que a velocidade cai muito com perdas acima de 1%.

Para que a perda de pacotes não seja um problema, ela deve ser menor que 0,5%, o que significa que a camada ATM da ADSL não pode apresentar perdas acima de 0,016% -- ou seja, zero perdas para todos os efeitos práticos. Por conta disso a banda larga ADSL começa a ficar muito ruim mesmo na presença de perdas aparentemente moderadas.

Tendo isso em vista, a camada física da ADSL trabalha muito duro para evitar perdas de céulas ATM, e elas quase nunca acontecem se a velocidade está dentro dos limites da linha telefônica. Por outro lado, a ausência de retransmissão na camada de enlace faz a situação piorar rapidamente quando a linha é "marginal".

Pacotes TCP/IP pequenos têm mais chance de passar incólumes; por exemplo, se adotássemos um tamanho máximo de pacote de 300 bytes, cada pacote precisa de apenas 6 células ATM, e uma taxa de erros ATM de 0,3% amplificaria para apenas 2% no TCP/IP. Ainda é uma perda que incomoda, mas é suportável. Isto significa que diferentes aplicações sofrerão de forma bem diferente quando a linha ADSL é ruim. Aplicações que usam pacotes pequenos e muitas conexões em paralelo quase não tomam conhecimento do problema, enquanto Web e downloads ficam horrivelmente lentos.

Este fato também permite mensurar indiretamente a perda de pacotes devido a problemas na ADSL. Basta fazer "ping" com tamanhos diferentes de pacote:

$ ping yahoo.com

$ ping -s 1400 yahoo.com

Se o segundo ping perder consideravelmente mais pacotes que o primeiro, a principal suspeita é a sua ADSL. Outros problemas (como o congestionamento dos links internacionais das nossas "queridas" telecoms) perdem pacotes grandes e pequenos da mesma forma, na mesma taxa.


Atenuação, relação sinal/ruído e velocidade máxima


Atenuação é a perda do sinal conforme ele viaja pelo fio. No caso da ADSL, que usa sinais de freqüência muito mais alta que a voz, essas perdas são sempre altas. Uma perda de 30dB significa que o sinal chega 1000 vezes mais fraco; e isto seria considerado um patamar muito bom. A estatística do meu modem mostra que a perda na minha linha é 53dB, bastante alta, o que caracteriza uma linha ruim. Mas isto não é o mais importante, já que sempre se pode injetar mais potência para compensar a perda.

Importante mesmo é a relação sinal/ruído, ou SNR. Este valor informa quanto o sinal em que estamos interessados é mais forte que o ruído de fundo. No caso da minha linha, o SNR é de 14dB, o que significa que o sinal é 10^14/10 = 25 vezes mais forte que o ruído de fundo. Dizem que o SNR cai muito no início da noite, o que equivale a dizer que o ruído de fundo é mais forte à noitinha.

A velocidade máxima de uma linha é construída com dois "ingredientes": SNR e largura de banda. No caso da ADSL, a largura de banda é fixa, ditada pelo padrão ITU. Assim resta apenas esperar que o SNR seja alto para acomodar velocidades também altas.


A fórmula de Shannon permite calcular a capacidade teórica máxima de um canal:

Banda (bits/s) = Largura * Log2(1 + SNR)

A fórmula representa numericamente um fato que qualquer um pode constatar empiricamente. Quanto mais ruidoso o ambiente, mais alto e/ou mais devagar você tem de falar para ser ouvido e entendido pelo seu interlocutor. E sua voz tem de ser ao menos um pouquinho mais forte que o ruído, ou que as demais vozes, para haver qualquer chance de você ser ouvido.

No caso da minha linha em particular, considerando ADSL2 (não 2+), a capacidade máxima é

Banda = 1000000 * Log2(1 + 25) = 4,7Mbps

A fórmula de Shannon estabelece um limite teórico, além do qual nenhuma tecnologia pode ir. Tecnologias práticas ficam sempre abaixo deste patamar teórico. Outro detalhe é que a fórmula não leva ruído impulsivo em consideração, embora ele certamente vá existir na prática.

Se o SNR é dado em decibéis, a fórmula pode ser simplificada para

Banda = 1000000 * SNR / 3 

Para cada 3dB de SNR, ganhamos 1Mbps em ADSL1/ADSL2, ou 2Mbps em ADSL2+. Bem mais fácil de memorizar.

Em resumo, não daria muito certo tentar usar 4Mbps nesta minha linha telefônica, pois está muito próximo do limite de Shannon, e qualquer piora na SNR ou a ocorrência de ruídos impulsivos causaria enorme quantidade de erros ATM, que por sua vez causam perdas de pacotes e lentidão. O próprio modem ADSL faz uma "reserva" de 6dB de SNR para precarver-se, o que redundava em no máximo 2,4Mbps downstream no meu caso, mesmo assinando um plano de 4. (Sem piadinhas, por favor!)

Como a ADSL2+ usa largura de banda de 2MHz, teoricamente a velocidade obtenível seria o dobro, certo?

O problema é que usar mais banda "espalha" a potência total numa faixa mais larga, diminuindo a quantidade de energia que chega na outra ponta para uma mesma "fatia" de banda, e portanto diminuindo o SNR.

No meu caso aqui, o SNR fica entre 4 e 9dB usando ADSL2+. A taxa de erros aumenta muito, a ponto de incomodar; foi por isso que eu mexi na configuração do modem. Mas o principal problema é a pouca "folga" de SNR; se a linha sofrer uma queda brusca de qualidade, talvez por conta de um ruído elétrico nas imediações, o SNR fica negativo e fatalmente a conexão cai. Usar ADSL2 evita todos esses problemas, e ainda vai longe o dia em que haverá planos de 24Mpbs por aqui, que me obriguem e usar ADSL2+.

Curiosamente, o upstream nunca incomoda. Nunca. Por pior que estivesse a ADSL aqui, por pior que fosse o modem, o upstream sempre fluía sem problemas na velocidade máxima contratada. Creio que isto acontece porque o upstream faz uso de frequências relativamente baixas (vide gráfico mais acima), que são as que menos sofrem atenuação e ruídos.

Interleaving

Um outro fator que pode estar ajudando minha conexão funcionar melhor com ADSL2 em vez de ADSL2+, é que o modo "interleaved" sempre é ativado no primeiro caso, enquanto no segundo caso geralmente a conexão fica em "fast mode" (modo rápido).

O modo interleaved transmite diversos frames ao mesmo tempo, com os bits "embaralhados". Assim, se ocorrer um ruído impulsivo, o estrago será dividido entre diversos frames, e o algoritmo de correção de erros tem mais chances de consertar cada frame. Já o modo rápido transmite um frame depois do outro, e um erro de rajada pega o frame de jeito.

Mas nada é de graça neste mundo. Como o modo interleaved trasmite diversos frames ao mesmo tempo, cada frame individual demora mais para chegar no outro lado. O que aumenta a latência, mais conhecida pelos jogadores on-line como "ping". Aqui, o "ping" é de 13ms em modo rápido, ou 50-60ms em modo interleaved. Além da latência ser maior, ela varia bastante -- esta variância é conhecida como "jitter".

Não descobri ainda se é possível configurar o interleaving no SpeedStream, ou mesmo em qualquer outro modem.

First WebGL program

Based on lessons 1, 2 and 10 of the excellent "Learning WebGL" blog (http://learningwebgl.com/blog/). I began to throw a lot of triangles since my final objective is to draw a 3D chart. My example can be found here, and of course demands a WebGL-enabled browser (Firefox Minefield, Webkit daily biuld, or perhaps Google Chrome).

(Para leitores brasileiros: lembrou vagamente a vinheta de entrada do Video Show, seria só uma questão de botar texturas em cada pedacinho para ficar mais parecido.)

ADSL modem soap opera :)

In the last weeks, I migrated from a rock-solid Internet connection to the typical uncertainty of most ADSL users seem to be plagued by. But crisis leads to solutions, and bits of new knowledge.

Everything began when I lost a discount in my phone bill in my old ADSL plan, which used to be the "best in the city", 1.5Mbps. (Don't laugh, lots of people in Brazil would have an orgasm by having access to such plan!). Well, I called to complain about the bill, and they said the discount was a time-limited offer... but the region got brand new ADSL2+ ports, so I could migrate to a new, faster, and cheaper plan. I could opt between 2, 4 and 8 Mbps, I chose 4. (I don't understand why ADSL2+ plans are cheaper, I guess it may have relationship to the fact that ADSL2 can "hibernate", saving electrical power, while ADSL1 is full-throttle all the time. If someone knows the answer, please comment.)

Flashback

My line was said to be marginal by the telco guy that came here when ADSL was first installed. The D-Link 500b modem reported a high downstream attenuation (55dB). It did not cause ADSL link falldown, it did not cause latency increase, but it seemed to cause packet loss in ATM level, something around 0,3%. Problem is, one 1500-byte IP packet is assembled from 30 ATM packets, and AAL5 does not do any retransmission, so any loss is magnified 30 times, resulting in 10% packet loss at IP level, for big packets. So, losses in ATM level must be *really* low. ADSL works a lot to avoid those losses, but they still happen sometimes.

The way I found to test for ATM-related packet loss was to ping the nearest telco router in two fashions: plain, and -s 1400 (that is, with a big packet). If packet loss is different between them, ATM and therefore link quality may be the problem. A variation is to ping a distant site (like google.com), so the plain ping shows the "baseline" packet loss -- but you will not be sure whether the "big ping" packet loss is really an ADSL problem. (Actually, google.com is not a good ping target because they don't answer "big pings" with packets of the same size. Since ADSL tends to have more problems in downstream, due to higher frequencies involved, it is better to choose a site that "pongs" packets as big as the ones that were pinged).

As most people know, TCP/IP assumes that packet loss is caused by congestion, so any packet loss makes bandwidth to fall sharply, something like having -90% speed under a 10% packet loss. That's why wireless level 2 protocols like 802.11 actually do packet retransmission, even though this task does not fall in this layer, not in classroom at least... The sympthom here was that things like YouTube did not work well, since they stream video over a single TCP/IP connection. But loading a page worked well because they use several parallel and short-lived TCP connections, which mitigates the effects of packet loss. (SCTP protocol has the concept of "streams" and every one of them has a separate congestion control, plus a "urgent" flag for messages, exactly because of these things.)

Well, fiddling a lot with 500b configurations, I found that DMT mode had the biggest packet loss at IP level: 5%. I don't remember exactly but I think that G.lite had 3% and ANSI had 1% -- the latter one is within the limit that TCP/IP tolerates without delivering lackuster bandwidth.

Other random facts: my father's ADSL router, which looks like the cheapest in the Universe, maintained a perfectly lossless link here. And the 500b modem behaved very well in my father's phone line. And the most important: upload speed was NEVER affected in any moment, it is always the contracted one, probably because upstream uses lower frequencies in phone line, which are less victimized by line losses.

But the ultimate solution was put my old and trusted 3Com HomeConnect modem back into service. For some reason, this modem offered undetectable packet losses over the same line. I never bothered again about this, until some weeks ago.

WiFi

After two years of veeeeery smooth Internet experience, some problems with heavy packet loss began to happen from time to time, in particular when powering up the iMac. Disabling WiFi and re-enabling tended to solve the problem. If not once, but in two or three toggles the things went straight again.

No other WiFi device here has this problem, so it must be some incompatibility between iMac's WiFI and my access points here. This one I could never solve completely, but abolishing WDS improved things a lot. Now, exactly one turn off/turn on solves the problem on iMac, while sometimes I had to do it 20 times in the past. Let's just pray my next router pleases the iMac better and does away with this little problem.

Packet losses

Some weeks before my phone bill problem, I began to have serious performance issues while communicating with certain sites, but not with others. Ping was normal, and packet loss was the same for any packet size, so the packet loss was happening either at remote end or by some intermediate router. Indeed a intermediate route of Traceroute was losing packets.

Funny thing is that, going to epx.com.br or to google.com means getting a different route as early as at 4th hop. The loss was happening at 5th hop in the path to epx.com.br. The path to google.com never had problems. After I heard that anycast exists for IPv4 too, and Google uses is actively to serve content in Brazil using Brazilian servers, the problem boils down to a simple international link overcommitment :) This conclusion is corroborated by the fact that losses increased in "peak" hours (which means from 18:00 to 00:00 in Internet usage).

At least, this particular problem seems to have been solved these days. So good, because the ATM packet loss made a comeback:

ADSL2+

Ok, so I migrated to 4Mbps, ADSL2+ plan. Thinking that my 3Com modem would not be able to connect, I plugged my D-LInk 500b to the line. The link got the bought speed, it said my line could go up to 9Mbps... but the packet loss problem was back.

After I heard that ADSL2+ equipment should be backwards-compatible, and ADSL1 goes up to 8Mbps, I put the 3Com modem back in service once more, and the packet loss was one more gone. The only (and new) problem: link tended to fall often, in particular when no traffic was being exchanged. This 3Com modem always had a problem with phone line disconnections: when the link falls (e.g. when you disconnect the phone connector and plug it again), it sometimes does not restablish communication, even if light goes green. You need to cycle the modem.

Perhaps the telco equipment was "hibernating" the connection a la ADSL2, which exercized this particular 3Com bug? Or the line actually worsened in those 3 years and modem was showing a instance of the "cliff effect", the all-or-nothing nature of communications with forward error correction. Or the line sometimes goes bad because of some intermitent noise source, like a big motor somewhere. I'm still looking for answers...

Fiddling a bit with 500b configuration again, I found that disabling ADSL2+, leaving only ADSL2 and RE-ADSL2 enabled, reduced the packet loss problem to 0,5% at IP level, which means of course much less in ATM level. And this modem did not have the problem of disconnecting often. The downside: downstream did not go over 1.1Mbps in this mode.

So I had the choice of using the old modem that delivered maximum speed but disconnected from time to time (and my VPN does not like this), or using the newer modem with reduced speed and non-zero packet loss.

In time, RE-ADSL2, or ADSL2 Annex L is an extended range mode which uses more power and more redundancy. Some users have reported better link condition with ADSL2 than with ADSL2+, either because of RE-ADSL2 or because ADSL2+ uses frequencies up to 2MHz, which are more victimized by noise and line losses.

So I bought a SpeedStream 4200 modem (Siemens), which has a local reputation of working well in long, noisy telephone lines. Unfortunately it turned me down. The packet loss was about the same as 500b, and synced in a slower speed (around 2.5Mbps). Great deal... the only parameter that was better than before was the latency (11ms RTT).

Moreover, the line condition seemed to change all the time. Time to try the same trick as I did in 500b: force some particular connection mode different from ADSL2+. SpeedStream 4200 does not have this kind of configuration via Web, but it has a telnet CLI mode. After trying several modes, and reviewing all phone connections at home (and soldering connections that seemed to be rusty/corroded), I settled with RE-ADSL2:

> cfg dsl{mode=red2
> cfg save
> do reboot

This mode made my link to settle in the following condition: 2.4Mbps, packet loss is absolute zero, latency is a bit jittery (40ms RTT with 30ms stddev, for small packets). Link is not falling "for free". Upstream is the contract 400Kbps -- as I mentioned before, upstream is always perfect (ironically, upload is the very thing I don't care about, I am not a Torrent guy).

Not the 4Mbps I was expecting, but good enough, and paying less than I used to pay for 1.5Mbps. Too bad that a future upgrade to 8Mbps or more will have to deal with the attenuation problem.

UPDATE 10/Dec: had a sharp decline in line quality this morning, which only allowed a stable link using G.lite (which limits speed to 1.5Mbps). After one hour, line got ok again. Actually, it got better than last few weeks. (Has telco fixed something? I called telco today to change my plan to 2Mbps due do those problems, and they said that former change to 4Mpbs was still being processed by tech team, which I hope means that they are monitoring problems too.) Now it runs at full 4Mbps connection again in ADSL2. ADSL2+ still goes just to 2Mpbs. Packet loss is around zero (1 in 10000 packets) in either mode.

Next steps

Since the telco guy said back then that buildings with underground phone lines tended to have high attenuation, and I have to reroute the line (it is currently laid over the ground so it reaches my office, coming from the original point), current plan for next year is to replace the whole line all the way to the pole. I didn't like the "rusty" aspect of wires today, I thought that copper would not rust! Maybe electrolitic corrosion? Or low-quality wire?

If this does not improve the attenuation sharply, then it will be the time for a call to telco asking for a line replacement. And who knows what can happen in 1 or 2 years, maybe the telcos will show up here in a sunny morning with a fiber optics cable? Or they decide to put a cabinet between central and distant phones like mine. We'll see.

Nerd analógico

Depois de constatar que termômetros digitais não são lá muito precisos, nem mesmo aqueles para medir febre, e os bimetálicos menos ainda, decidi arrumar um termômetro analógico a álcool.

O medidor de umidade relativa "de cabelo" também não estava dizendo coisa com coisa, assim parti logo para um "termo-higrômetro", conforme o que se vê na foto.

O princípio de funcionamento é o seguinte: um bulbo é seco, o outro é mantido molhado. A evaporação remove calor, portanto o termômetro "de bulbo úmido" vai marcar sempre uma temperatura menor que o "de bulbo seco". Quanto mais seco o ar, maior a evaporação e maior a diferença de temperatura. A tabelinha e o gráfico ao lado dos termômetros servem para achar a umidade relativa em função das temperaturas.

Para mais informações, a Wikipedia está sempre a postos :) E não esqueça de fazer a sua doação.

Eu já tinha visto termo-higrômetros antigões, enormes, e achei que não ia achar uma versão analógica hoje em dia senão num antiquário. Mas, por incrível que pareça, existe até uma fábrica de termômetros analógicos no Brasil, a Incoterm.

Como eu quis colocar 2 aparelhos desses em casa (um dentro, um fora), comprei a versão mais barata, mas há outro modelo da Incoterm, mais alto e mais bonito, e com tabela de fácil consulta impressa no próprio corpo, entre os dois bulbos. Dá um bom presente.

Festa do Javascript

Dois brinquedos novos para quem se interessa por Javascript:

1. Estudo gráfico de operações com opções. Embora o conteúdo vá interessar apenas a investidores, o gráfico é feito usando a biblioteca Flot, que tornou a tarefa muito fácil.

Outras bibliotecas que vi fazem gráficos muito mais bonitos "out of the box", ideais para ilustrar evolução de vendas de comida de cachorro, porém elas tornam as coisas difíceis na hora de adicionar recursos de ajuda visual para uso sério, como os grids, a "mira", um segundo eixo etc. O Flot dá acesso quase direto à superfície cartesiaana sem ser pobre em recursos.

Em (não muito) breve, uma nova versão deste estudo será lançada em WebGL. Estou querendo aprender um pouco de 3D, e esta vai ser a oportunidade. Pensei em fazer em PyOpenGL, em Qt com OpenGL... mas bom é se o negócio pode ser acessado de qualquer lugar, e aí tem de ser Web e Javascript. (A consciência não dói muito por não usar Qt, porque já circulou videos demonstrando o WebGL no Mozilla do Nokia N900...).

2. Brinquedo escrito em server-side Javascript. Muita gente já conhece o gerador de nomes de repartições públicas Febeapá -- as eleições estão aí, não custa mencionar de novo para os políticos criarem mais uns empregos pra galera!

Sério agora: a tecnologia subjacente da página foi mudada de um vergonhoso iframe+php+popen(script.python) para um descolado AJAX+server-side Javascript. Dentre os diversos projetos de SSJ disponíveis, estou usando o V8CGI.