Mais bugs graves no Android!

Há uns dias voltou a surgir mais um problema grave no sistema operativo Linux. Mas, enquanto na maioria dos PCs é possível actualizar o Linux de forma fácil, o mesmo não se verifica no Android. Segundo os investigadores que descobriram o problema, 66% dos Androids estarão vulneráveis, embora tal seja discutido.

O problema de muitos de nós não podermos actualizar os nossos equipamentos electrónicos começa a tornar-se demasiado grave. Já o havíamos referido neste artigo do Stagefright. Agora volta a acontecer, e não admira que as pessoas a mudar para os iPhones seja cada vez maior!

Um site que acompanha a evolução destas falhas no Android é o AndroidVulnerabilities.org. Eles produzem um gráfico muito interessante, visível abaixo, que permite ver qual a percentagem de dispositivos seguros, e os inseguros, ao longo dos últimos anos. Como podem observar, a grande  maioria permanece insegura:

Evolução vulnerabilidades em Android

Evolução vulnerabilidades em Android

170º bug: o da falha de segurança nos Android e da programação para o Pebble Time

Podcast do Poupar Melhor

Esta semana falamos sobre um defeito importante que afetou 66% dos equipamentos com sistema operativo Android. Terminamos a falar sobre aquilo que vamos passar a contar acerca da programação para o Pebble Time.

Podem aceder aqui à lista completa de episódios do Podcast. O Podcast do PouparMelhor está também no iTunes.

Play

Menos Velocidade, mais Poluição?

A ideia que todos temos interiorizada é que o consumo de combustível de um automóvel aumenta, com o aumento da velocidade. E com o aumento do consumo de combustível, aumenta naturalmente a poluição. Na proposta da Câmara para a Segunda Circular, é por isso assumido que a redução do limite de velocidade máxima de circulação contribuiria para uma redução dos impactes ambientais.

Por outro lado, é nos dito que para minimizar o consumo, é necessário engrenar a velocidade mais elevada, e conduzir nessa engrenagem sem deixar o carro ir abaixo. Acontece que na maioria dos carros, não se consegue fazer isso com um limite de 60 Km/h. Eu no meu não consigo…

A verdade é que a eficiência de um motor vai melhorando à medida que vamos inicialmente subindo a velocidade. Tal é verdade no arranque inicial, e tal mantém-se até determinada velocidade. Mas, a partir dessa velocidade, a potência necessária para o veículo se mover a uma velocidade superior aumenta mais que a melhoria de eficiência no motor, pelo que o consumo voltará a subir.

O ponto em que se verifica a inflexão de consumos é dependente das várias marcas/modelos, mas também de um conjunto diverso de factores variáveis, conforme temos referido em múltiplos artigos do Poupar Melhor. A melhor compilação que conheço no domínio desta área é a dada pelo documento “Transportation Energy Data Book”, que na sua página 126 tem o seguinte gráfico:

Consumo vs. velocidade, ao longo das últimas décadas

Consumo vs. velocidade, ao longo das últimas décadas (atenção às medidas imperiais)

Os dados deste gráfico evidenciam que actualmente os automóveis estarão próximos do seu melhor consumo quando circularem a quase 100 Km/h. E isto para os automóveis americanos, que sabemos não são tão eficientes como os europeus, que tipicamente utilizamos em Portugal. Esse valor está também de acordo os melhores consumos que consigo no meu automóvel. Notem ainda como as velocidades onde os automóveis têm os seus melhores consumos, tem vindo a subir nas últimas décadas. Tal não é obviamente surpreendente dadas as melhorias em termos de motorizações, mas também de aerodinâmica.

Os valores que a literatura consagra como óptimos, na zona dos 80 Km/h, não são válidos para todos os automóveis. Os mais recentes de uma forma geral ficam acima, mas com a notável excepção dos carros híbridos e eléctricos. Nestes, a velocidade óptima é genericamente bastante inferior, mas também não contam significativamente para o aumento das emissões de gases poluentes.

Assim sendo, o que a proposta da Câmara vai conseguir, ao reduzir a velocidade máxima da Segunda Circular, de 80 Km/h para 60 Km/h, é aumentar a poluição, o contrário obviamente do que é desejável!

Raspberry e diferentes cartões micro SD

Temos vindo aqui a analisar diferentes aspectos relacionados com o desempenho dos Raspberry, nomeadamente entre as versões Raspberry Pi model B e a Raspberry Pi model B versão 2.

Quando configurei o mais recente Raspberry Pi model B versão 2 cá em casa, a velocidade era bastante sofrível. Na verdade, o OSMC arrastava-se e ficava mesmo bloqueado. Foi então que me lembrei que não havia sido boa ideia utilizar o único cartão micro SD que então tinha à mão.

Na verdade, nem todos os cartões SD nasceram iguais! Muitas vezes podemos interrogar-nos porque custam uns bastante mais que outros? Na verdade, um dos factores que distingue vários tipos de cartões SD é a sua velocidade de escrita e de leitura. Há várias boas referências na Internet, sendo que destaco particularmente esta página.

Acabei por substituir o cartão micro SD por outro, com características diferentes. E realmente a mudança foi brutal! Olhando para os dois abaixo, podem parecer iguais, mas há um dourado, que por acaso (?) é o que se porta melhor:

O dourado é o melhor!

O dourado é o melhor, e não é por ter 16GB!

Para averiguar as diferenças entre os dois, resolvi fazer alguns testes. Utilizei o comando hdparm (é preciso instalá-lo, pois não vem por defeito com o OSMC), bem como o dd. Ambos são comandos problemáticos, especialmente o dd, pelo que tenham sempre a certeza do que estão a fazer!

No cartão micro SD inicial, o hdparm deu valores de leitura com cache, ligeiramente superiores a 430 MB/segundo. A ler directamente do cartão, a velocidade ficou próxima dos 18 MB/segundo. O comando dd permite-nos averiguar a velocidade de escrita, e essa foi ainda inferior, entre os 8 e 9 MB/segundo. A velocidade de leitura com o dd foi ainda superior ao do hdparm:

osmc@osmc:~$ uname -a
Linux osmc 4.3.0-10-osmc #1 SMP PREEMPT Sun Nov 29 14:06:50 UTC 2015 armv7l GNU/Linux
osmc@osmc:~$ sudo hdparm -tT /dev/mmcblk0p2
/dev/mmcblk0p2:
Timing cached reads: 878 MB in 2.00 seconds = 438.80 MB/sec
Timing buffered disk reads: 54 MB in 3.06 seconds = 17.64 MB/sec
osmc@osmc:~$ sudo hdparm -tT /dev/mmcblk0p2
/dev/mmcblk0p2:
Timing cached reads: 864 MB in 2.00 seconds = 431.84 MB/sec
Timing buffered disk reads: 56 MB in 3.11 seconds = 18.01 MB/sec
osmc@osmc:~$ dd if=/dev/zero of=test bs=1048576 count=200
200+0 records in
200+0 records out
209715200 bytes (210 MB) copied, 23.2975 s, 9.0 MB/s
osmc@osmc:~$ dd if=test of=/dev/null bs=1048576
200+0 records in
200+0 records out
209715200 bytes (210 MB) copied, 0.437839 s, 479 MB/s
osmc@osmc:~$ rm test
osmc@osmc:~$ dd if=/dev/zero of=test bs=1048576 count=200
200+0 records in
200+0 records out
209715200 bytes (210 MB) copied, 26.4668 s, 7.9 MB/s
osmc@osmc:~$ dd if=test of=/dev/null bs=1048576
200+0 records in
200+0 records out
209715200 bytes (210 MB) copied, 0.420012 s, 499 MB/s

No segundo cartão micro SD, o hdparm deu valores de leitura com cache de cerca de 380 MB/segundo. A ler directamente do cartão, a velocidade ficou ligeiramente acima dos 18 MB/segundo. Com o comando dd, a velocidade de escrita ficou entre os 45 e 50 MB/segundo, com a velocidade de leitura do dd a ser também superior à do hdparm:

osmc@osmc:~$ uname -a
Linux osmc 4.3.0-10-osmc #1 SMP PREEMPT Sun Nov 29 14:06:50 UTC 2015 armv7l GNU/Linux
osmc@osmc:~$ sudo hdparm -tT /dev/mmcblk0p2
/dev/mmcblk0p2:
Timing cached reads: 762 MB in 2.00 seconds = 380.58 MB/sec
Timing buffered disk reads: 56 MB in 3.02 seconds = 18.54 MB/sec
osmc@osmc:~$ sudo hdparm -tT /dev/mmcblk0p2
/dev/mmcblk0p2:
Timing cached reads: 756 MB in 2.00 seconds = 377.79 MB/sec
Timing buffered disk reads: 56 MB in 3.01 seconds = 18.57 MB/sec
osmc@osmc:~$ dd if=/dev/zero of=test bs=1048576 count=200
200+0 records in
200+0 records out
209715200 bytes (210 MB) copied, 4.57351 s, 45.9 MB/s
osmc@osmc:~$ dd if=test of=/dev/null bs=1048576
200+0 records in
200+0 records out
209715200 bytes (210 MB) copied, 0.476132 s, 440 MB/s
osmc@osmc:~$ rm test
osmc@osmc:~$ dd if=/dev/zero of=test bs=1048576 count=200
200+0 records in
200+0 records out
209715200 bytes (210 MB) copied, 4.04712 s, 51.8 MB/s
osmc@osmc:~$ dd if=test of=/dev/null bs=1048576
200+0 records in
200+0 records out
209715200 bytes (210 MB) copied, 0.489697 s, 428 MB/s

Resumindo, a velocidade de escrita do segundo cartão micro SD parece ser a determinante na perceção de desempenho do OSMC. É aqui que entra a classe dos cartões, e se repararam o segundo cartão é da classe 10, enquanto o primeiro é de classe 4. As classes dos cartões estão relacionados com a sua capacidade de escrita, essencial na fotografia/vídeo. Notem até que a velocidade de leitura do primeiro é melhor!

Para que o OSMC tenha este comportamento, é em princípio porque está a escrever muita informação no cartão micro SD. Presumo que quando está a fazer streaming, que esteja a guardar informação temporariamente no cartão micro SD. Ainda assim, é uma dúvida que vou tentar esclarecer posteriormente…

Raspberry Pi model B versus Raspberry Pi model B versão 2

Se fizeram scroll até ao final dos posts sobre as medições com o NBench do Raspberry Pi model B (RPi B) e do Raspberry Pi model B versão 2 (RPi 2) já sabem o que aqui vou resumir. O RPi 2 é realmente mais rápido, o que podem observar pelo vídeo acima.

O vídeo acima mostra primeiro o RPi B a mudar entre opções no ecrã inicial até chegar à previsão meteorológica e depois a mesma operação no RPi 2. O que é visível é o tempo de resposta entre ambos os equipamentos. O primeiro apresenta inclusivamente paragens para iniciar a apresentação da previsão meteorológica.

O RPi 2 é muito mais rápido que o seu antecessor RPi B. Os resultados dos testes abaixo exprimem essa diferença. O RPi B só tem um core. Um core é um componente de computação que, quando existam mais de um, permite processar instruções em simultâneo.

Sistema testado Número de Testes paralelos Resultado global
RPi B 1 76.0
RPi 2 1 173.7
RPi 2 4 402.5

 

Nbench e o Raspberry Pi Model B versão 2

Raspberry Pi Model B 2 - Raspberrypi.org

Raspberry Pi Model B 2 – Raspberrypi.org

Voltámos a utilizar o BYTE UNIX benchmark suite ou NBench, mas desta vez para medir o desempenho do Raspberry Pi Model B versão 2 (RPi 2). Como tinhamos dito aqui quando medimos o desempenho do RPi B, o Nbench foi criado por volta de 1990 para a revista Byte com o objetivo de medir o desempenho e tem a vantagem de já ter sido usado com tantos sistemas que podemos depois relacionar o seu desempenho com máquinas do passado.

Desta vez, em lugar de um core temos quatro, por isso é feito um conjunto de testes a um core e depois com o processamento paralelo em quatro cores. Por isso, desta vez há dois conjuntos de testes. Agora vamos publicar os resultados.

BYTE UNIX Benchmarks (Version 5.1.3)

System: osmc: GNU/Linux
OS: GNU/Linux — 4.3.0-10-osmc — #1 SMP PREEMPT Sun Nov 29 14:06:50 UTC 2015
Machine: armv7l (unknown)
Language: en_US.utf8 (charmap=”ANSI_X3.4-1968″, collate=”ANSI_X3.4-1968″)
CPU 0/1/2/3: ARMv7 Processor rev 5 (v7l) (0.0 bogomips)

21:32:01 up 3:05, 1 user, load average: 0.24, 0.14, 0.27; runlevel 5

Benchmark Run: Sun Jan 03 2016 21:32:01 – 22:00:05
4 CPUs in system; running 1 parallel copy of tests

Tipo de teste Resultado Unidade Duração testes
Dhrystone 2 using register variables 2894521.7 lps 10.0 s 7
Double-Precision Whetstone 418.1 MWIPS 9.9 s 7
Execl Throughput 449.9 lps 29.9 s 2
File Copy 1024 bufsize 2000 maxblocks 73731.0 KBps 30.0 s 2
File Copy 256 bufsize 500 maxblocks 22420.5 KBps 30.0 s 2
File Copy 4096 bufsize 8000 maxblocks 179668.3 KBps 30.0 s 2
Pipe Throughput 214199.6 lps 10.0 s 7
Pipe-based Context Switching 28599.2 lps 10.0 s 7
Process Creation 1109.0 lps 30.0 s 2
Shell Scripts (1 concurrent) 1188.4 lpm 60.1 s 2
Shell Scripts (8 concurrent) 316.1 lpm 60.2 s 2
System Call Overhead 459926.0 lps 10.0 s 7

Resultados indexados

System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 2894521.7 248.0
Double-Precision Whetstone 55.0 418.1 76.0
Execl Throughput 43.0 449.9 104.6
File Copy 1024 bufsize 2000 maxblocks 3960.0 73731.0 186.2
File Copy 256 bufsize 500 maxblocks 1655.0 22420.5 135.5
File Copy 4096 bufsize 8000 maxblocks 5800.0 179668.3 309.8
Pipe Throughput 12440.0 214199.6 172.2
Pipe-based Context Switching 4000.0 28599.2 71.5
Process Creation 126.0 1109.0 88.0
Shell Scripts (1 concurrent) 42.4 1188.4 280.3
Shell Scripts (8 concurrent) 6.0 316.1 526.8
System Call Overhead 15000.0 459926.0 306.6

System Benchmarks Index Score 173.7

Benchmark Run: Sun Jan 03 2016 22:00:05 – 22:28:25
4 CPUs in system; running 4 parallel copies of tests

Tipo de teste Resultado Unidade Duração testes
Dhrystone 2 using register variables 11358891.2 lps 10.0 s 7
Double-Precision Whetstone 1670.9 MWIPS 10.0 s 7
Execl Throughput 1227.4 lps 29.9 s 2
File Copy 1024 bufsize 2000 maxblocks 100259.5 KBps 30.0 s 2
File Copy 256 bufsize 500 maxblocks 29721.5 KBps 30.0 s 2
File Copy 4096 bufsize 8000 maxblocks 244756.5 KBps 30.0 s 2
Pipe Throughput 831054.0 lps 10.0 s 7
Pipe-based Context Switching 111659.6 lps 10.0 s 7
Process Creation 1952.2 lps 30.0 s 2
Shell Scripts (1 concurrent) 2467.6 lpm 60.1 s 2
Shell Scripts (8 concurrent) 344.4 lpm 60.4 s 2
System Call Overhead 1734253.4 lps 10.0 s 7

Resultados indexados para processamento paralelo com 4 core

System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 11358891.2 973.3
Double-Precision Whetstone 55.0 1670.9 303.8
Execl Throughput 43.0 1227.4 285.4
File Copy 1024 bufsize 2000 maxblocks 3960.0 100259.5 253.2
File Copy 256 bufsize 500 maxblocks 1655.0 29721.5 179.6
File Copy 4096 bufsize 8000 maxblocks 5800.0 244756.5 422.0
Pipe Throughput 12440.0 831054.0 668.0
Pipe-based Context Switching 4000.0 111659.6 279.1
Process Creation 126.0 1952.2 154.9
Shell Scripts (1 concurrent) 42.4 2467.6 582.0
Shell Scripts (8 concurrent) 6.0 344.4 574.0
System Call Overhead 15000.0 1734253.4 1156.2

System Benchmarks Index Score 402.5