Tag: gps

Duas dicas rápidas: Uber e GPS em Android AOSP

Posted by – 31/01/2017

Faz tempo que não posto nada, mas tenho de passar para deixar duas dicas rápidas:

Se você está cansado de demorar para obter a localização GPS no seu Android AOSP (no meu caso, CyanogenMod), talvez queira configurar seu gps.conf direito. Na maioria dos casos esse arquivo aponta para servidores lentos ou para NTPs muito longe do ponto em que se pretende obter o fix. Enquanto existem diversas maneiras de fazer isso, se seu celular está rootado e você tem um recovery do tipo ClockworkMod, a mais fácil é simplesmente baixar o arquivo adequado para seu país e aplicá-lo usando a recovery. Nessa thread do XDA-Developers você vai encontrar o arquivo para o Brasil que eu utilizei. Meu GPS fix (antes obtido aleatoriamente entre 1 a 15 minutos!) passou a ser obtido em 15 segundos na pior da hipóteses!

A segunda dica é sobre o Uber. Como meu AOSP não tem GApps (sim, eu não tenho conta no Google vinculada ao meu celular), não tenho Google Play Services. Isso me limita em diversas aplicações, no entanto estou confortável com essas limitações… Na maioria dos casos tenho alternativas que eu uso e prefiro… Faltava uma, no entanto: Uber. Na verdade, nenhum aplicativo de Taxi funciona para quem não tem Google Play Services, mas sempre se pode ligar para um Taxi… O mesmo não acontece para o Uber. A solução foi utilizar o Uber-Mobile. Sim, o Uber tem um aplicativo que funciona via browser, mas você precisa solicitar acesso ao mesmo. A dica está no próprio site do Uber. O processo é feito por email com o Suporte deles e, no meu caso, demorou cerca de 20 minutos desde o envio da primeira solicitação e uma troca de 3 emails com o atendente…

NTP-Pool: aumentando a participação brasileira

Posted by – 12/03/2009

Você conhece o NTP Pool? Provavelmente não, mas se você estiver usando uma das distribuições de GNU/Linux mais recentes, incluindo as maiores, e estiver atualizando o relógio pela rede, provavelmente está usando o NTP Pool.

Manter o relógio certo é um problema bastante comum e crucial para a computação atual. Muita coisa depende de sincronia, e de manter dados fidedignos quanto ao momento exato em que determinada ação ocorreu. O que parece um desafio, na realidade tem uma solução muito simples: Network Time Protocol, um protocolo padrão da Internet que mantém o relógio do computador local sincronizado com o de um computador remoto.

Simples sim, mas com um custo: existem relativamente poucos computadores ligados a fontes de sincronia temporal fidedignas (como GPS, ou relógios atômicos). Logo, o acesso a um desses computadores acabava sendo um privilégio de poucos. O NTP também tem resposta a isso… uma vez que um computador obtenha a sincronia com um desses servidores centrais (ou de camada 1 – stratum 1 – na terminologia do NTP) pode exportar essa mesma sincronia uma camada abaixo (efetivamente tornando-se stratum 2), num sistema que é escalável exponencialmente, sem perda significativa da precisão.

No entanto, um problema ainda ficava em aberto: que servidor NTP usar? Aí é que entra o NTP Pool, um conglomerado de servidores públicos, com banda doada pelos seus mantenedores, integrando um circuito cada vez maior de sincronia temporal, monitorados para garantir a precisão e a disponibilidade.

Sou usuário de NTP há muito tempo, tendo mantido um servidor NTP para uso interno em cada rede que monto. Esse servidor interno aponta sempre para o NTP Pool. Recentemente me interessei por saber mais sobre o NTP Pool, e fiquei bastante surpreso ao saber que dos mais de 1700 servidores de NTP que integram o NTP Pool, menos de 20 estão na América do Sul (e desses, apenas 13 no Brasil!). É impressionante! Eu mesmo mantenho um servidor NTP no Pool (ntp.nardol.org), no entanto, como ele se localiza fisicamente nos EUA, serve para aumentar as estatísticas de lá.

Vamos aumentar a participação brasileira? Se você possui um servidor no Brasil pode instalar facilmente o ntp server. Instruções mais detalhadas podem ser encontradas no próprio site do NTP Pool. O consumo de banda ocorre via protocolo UDP, e é ridículo. Para garantir que esse consumo nunca exceda a capacidade do meu servidor, por exemplo, uso simples regras de IPTables, como as abaixo:

bash$ iptables-save
(...)
-A INPUT -p udp -m udp --dport 123 -j ntp
(...)
-A ntp -m limit --limit 10/sec --limit-burst 6 -j ACCEPT
-A ntp -j LOG --log-prefix "ntp flood: " --log-level 7
-A ntp -j DROP
(...)
bash$

No entanto veja que as regras de limitação de conexões no meu servidor nunca foram atingidas (pelo menos desde o último reboot 🙂 ):

bash$ uptime
 15:20:00 up 23 days, 17:32,  1 user,  load average: 0.04, 0.12, 0.18
bash$ iptables -vnL
(...)
Chain ntp (1 references)
 pkts bytes target     prot opt in     out     source               destination
 233K   18M ACCEPT     0    --  *      *       0.0.0.0/0            0.0.0.0/0         limit: avg 10/sec burst 6
    0     0 LOG        0    --  *      *       0.0.0.0/0            0.0.0.0/0         LOG flags 0 level 7 prefix `ntp flood: '
    0     0 DROP       0    --  *      *       0.0.0.0/0            0.0.0.0/0
(...)
bash$

ntp_pool

Happy hacking!