Blog‎ > ‎

RaspPhotoPipe

++ = RaspPhotoPipe

Há uns anos atrás montei um Photoduíno que pouco uso lhe dei, principalmente porque dentro de casa não tenho muitas possibilidades de tirar fotografias de estúdio, mas quando se anda na rua, por vezes dá jeito ver as fotos com algo melhor que o LCD que a máquina traz. Neste Natal, o pai natal arranjou-me um tablet, mas como não dá para ligar diretamente o tablet à máquina fotográfica (quanto quanto sei), decidi juntar um Raspberry Pi pelo meio para dar mais uns poderes à máquina fotográfica.

Por isso decidi iniciar um novo projeto, e depois de alguma procura, encontrei alguém com as mesmas ideias do que eu, mas não diz muito pelo que passou. Eu como sou fã da filosofia do open source, irei partilhar os passos do meu projeto. De eletrónica não percebo nada, mas gostava de aprender alguma coisa, por isso, vou começar a montar coisas fáceis até ao ponto de integrar alguns sensores ao Raspberry Pi, tal como fiz com o Photoduino.

Então seguem os objetivos do meu projeto:
1. Arranjar um Raspberry Pi;
2. Interligar o Raspberry Pi com a máquina fotográficas e (re)tirar fotos via gphoto;
3. Juntar o tablet, primeiro fazer os dois comunicar, de preferência não estando dependente de um AP;
4. Arranjar forma de ver no tablet uma foto acabada de tirar com a máquina;
5. Expandir o espaço de armazenamento...

Até agora tudo (espero) fácil.... é só juntar software e cabos, depois começa a parte de envolve alguma eletrónica:
6. Juntar baterias para poder sair de casa;
7. Juntar tudo de forma a ficar transportável.
8. Começar a adicionar sensores... depois logo penso quais :)

Para além de ir indo colocando todos os passos da minha aventura, também vou adicionar a informação de quanto vou gastar no projeto.

Canon Framboesa






Expansão Armazenamento - parte IV

posted 4 Aug 2013, 08:40 by Flip Pipe

Para o RaspPhotoPipe ser útil, pelo menos deveria ser possível copiar um imagem em raw abaixo de 1 segundo. Com os meus último resultado, conseguia copiar em ficheiro raw (cerca de 20Mb na minha máquina) em cerca de 2 segundos. Não é muito mau, mas deveria ser melhor. Por isso fui à procura de formas de melhorar o raspberry pi.


Algo que aprendi com isto, é que, nem sempre o maior é o melhor, isto porque sendo um equipamento com poucos recursos, é fácil de os esgotar.


Primeiro, vou tentar obter o melhor dos discos USB, com o mínimo de recursos.


De acordo com esta pergunta é possível configurar um parâmetro no kernel que se pode obter mais do USB. Este parâmetro é o max_sectors, que limita o número de bytes pedidos em cada comando.

USB

Na minha configuração, o parametro max_sectors será de 192, porque mesmo pedindo mais informação, não obtenho maior débito.


O próximo passo é melhorar como o kernel lida com as chamadas de I/O.

O kernel do Linux, implementa 4 diferentes algoritmos para lidar com os dados de um disponsitivo, e este são conhecidos como schedulers. Podem encontrar no StackOverFlow uma pequena explicação.


No Raspbian, só existem 3 no kernel: noop, deadline e cfq.

Scheduler

Não se deixem enganar pelo gráfico, porque se eu não tivesse alterado a escala, quase não se notava a diferença entre eles, por isso, não penso que alterar o scheduler irá fazer diferença no fim.


Próximo passo, como melhorar o RAID? Vou começar pelos elementos principais. Um desses elementos é a quantidade de dados que é escrita de uma única vez para o disco (chunk size) e outra é a quantidade de memória usada como cache (strip_cache_size).

Depois de correr o script os melhores valores que obtenho são:

Chunk size de 32 bytes e a stripe cache size para 4096 bytes. A chunk size de 8bytes poderia ter melhoria na escrita, mas tornaria a velocidade de leitura muito pior.


Write



Para terminar, ver qual o melhor sistema de ficheiros.



Até agora, todos os testes foram fazendo um DD de /dev/zero para o disco. Mas com este teste, tenho dois problemas: Primeiro não imita a forma como vão ser copiados os dados e por outro lado é muito consumir de recursos do raspberry pi. Se estiver ocupado a gerar zeros para escrever no disco, não pode ao mesmo tempo estar a fazer o processamento necessário para escrever os dados no RAID.


Por isso alterei a maneira de fazer os testes. Por isso a minha metodologia passou a ser copiar ficheiro a ficheiro da memória do raspberry pi para o disco em RAID. E também deixei de fazer testes com o stripe cache abaixo de 1024 bytes.

Uma grande alteração nos valores, correto? Pois, mas estes dados são de alguma forma enganadores, porque a origem dos dados é memória, e o destino, devido à cache do RAID também é memória. Deste gráfico a única coisa que concluo é que o XFS será a minha primeira escolha como sistema de ficheiros, porque está a ser o mais consistente nos testes, mesmo tendo um pior desempenho que o BTRFS-


Já agora, lembra-se de eu no último post, ter colocado a hipótese de compilar os módulos estaticamente no kernel para isto ser mais rápido... bom aqui têm a vossa resposta... não existem alterações significativas, por isso, não vale a pena perder tempo a recompilar o kernel só por causa disto.


A minha última tentativa de fazer testes semelhantes ao cenário final, é copiar os ficheiro do cartão de memória para o RAID. Não existem diferenças entre os sistemas de ficheiros.

Depois de tantas horas de testes para chegar a uma conclusão: Provavelmente o estrangulamento será no USB e não no desempenho do RAID.



Espanção Armazenamento - Parte III

posted 4 Apr 2013, 14:50 by Flip Pipe

Na minha última mensagem, disse que iria trabalhar com 3 Pens USB em RAID 5. Deveria dar qualquer coisa como 30MB/s de velocidade de escrita.

Entretanto, as componentes para o Raspberry Pi chegaram, por isso pude começar a fazer testes com ele mesmo.

Desilusão... o meu primeiro testes com as 3 Pens em RAID 5 só rondou os 5MB/s... onde estão os 30MB/s dos testes anteriores???

Ah... Esqueci-me de afinar as configurações... vamos lá aumentar o valor do stripe_cache para os 8M e voltar a fazer os testes...

Mais sorte... nenhuma... a velocidade de escrita desceu para menos de 3MB/s.

A verdade é que vou necessitar de fazer mais um monte de testes de novo para ver quais são os valores ótimos para o stipe_cache e tudo o mais que conseguir encontrar para afinar as configurar as configurações... pelo menos quero obter 20MB/s.

Procurando um pouco no Google, encontrei que o valor do tamanho dos blocos (chunk size) de quando o RAID é criado também influência o desempenho global.

Então, lá fiz mais testes, variando o tamanho dos blocos do RAID e o tamanho da memória, e aqui estão os resultados:



Como podem ver, afinar as configurações do RAID é bastante importante nas velocidades de escrita... como podem ver, com o mesmo cenário de testes, podemos ir de ~3MB/s até 12MB/s, 4X mais.

Em relação às leituras, bom, o stripe_cache não afeta o desempenho, só o tamanho dos blocos, então segue o gráfico só o débito alterando esse valor:




Como posso melhorar o desempenho da escrita... adicionando mais discos? O hub que usei até agora, não tinha alimentação externa e quando liguei o 4º disco deixou de funcionar. Então tive de comprar um hub com alimentação externa... e encontrei um com 7 portas :)

Hub novo... será que vai influenciar os resultados?




Não, não faz diferença... adicionando um 4º disco aumenta o desempenho... será que consigo os 20MB/s?

Pois... já sabem... mais um monte de testes com a mesma filosofia utilizada anteriormente.

 

Ainda não foi desta que obtive os 20MB/s.. Talvez com o hub com alimentação externa e com as 6 Pens que tenho em mão, talvez consegui-se obter os 20MB/s, mas quando de o tiver de alimentar a pilhas, mais um ampere faz diferença. Por isso no futuro poderei fazer esses testes para ver como funciona com as 6 Pens, mas para este projeto só vou usar 4.

Todos estes testes foram feitos sem ter qualquer sistema de ficheiros no RAID, por fim, o meu último teste foi ver quanto afetava o desempenho a existência do sistema de ficheiros... aqui estão os resultados:




Mais degradação... menos 4MB/s... isto não são boas noticias... vou ter de melhor mais isto. O software do RAID não está estático no kernel, mas sim via módulos... e muitos. Irei tentar melhorar isso compilando diretamente o RAID no kernel.

Por enquanto, não vão tentar melhor isto... agora já tenho tudo o que necessita para fazer a primeira fase do projeto. Já tenho o gphoto a comandar a máquina fotográfica. o WebCamCon já está a funcionar, tenho um dongle usb wireless a fazer de AP e já me consigo ligar com o meu tablet. E tenho (um não bom) armazenamento... Está na altura de juntar tudo.

(nota: vejam na versão em inglês os ficheiros e comentários que lá coloquei)

Expansão de armazenamento - Parte II

posted 23 Mar 2013, 15:03 by Flip Pipe

Como escrevi em fevereiro, um dos objetivos é ter mais capacidade de armazenamento que só o Compact Flash da camera. Depois de algumas semanas de experiências, finalmente, consegui decidir uma coisa no RaspPhotoPipe.

  • Três USB 3.0 Flash Drive em RAID 5.

Esta decisão foi tomada depois de cerca de seis semanas de investigações para chegar a esta conclusão.

Que tipo de pen drive USB para usar

Minha primeira decisão e, provavelmente, a mais óbvia foi usar pen drives USB 2.0, e há dois tipos de presente: UDP e do COB (Chip on Board).



Uma descrição sobre as diferenças podem ser encontradas aqui (em inglês), mas não diz sobre o tempo de vida e débitos. Pedi ajuda em StackExchange (em inglês) mas até agora não tive sorte nenhuma.

Até aqui, a comparação só eu tenho é de duas pen usb. Usando o Utilitário de Disco do Ubuntu eu tenho alguns resultados:

 COB UDP
 
 


Com estes resultados e porque são mais pequenas, vou-me focar nas pen USB UDP.

Onde Comprar

A minha primeira ideia foi comprar diretamente da China e da fabrica por mais barato e para comprá-lo sem qualquer invólucro.

Encontrei um site de venda empresa para empresa: http://www.alibaba.com/

Contactei com cerca de 6 empresas, todas elas responderam às minhas perguntas, mas no final, o MOQ ("mininum order quantity" - quantidade mínima) era de 50 unidades, e na melhor das hipóteses vou usar 6 em numa configuração em RAID mais elaborado.

Um dos fabricantes, apontar-me a versão de atacado de Alibaba:

http://www.aliexpress.com

Mas, sem invólucro não encontrei nenhum produto. Para ser barato, a quantidade minima era de 10 unidades.

Então, virei-me para as lojas mais convencionais.

Depois de algumas horas a procurar PENs no site MyMemory, eu escolhi a Kingston DataTraveler USB 3, 32 GB.

"O preço é idêntico ao USB 2, mesmo sendo um péssimo USB 3, deve ter pelo menos o mesmo desempenho de USB 2." Este foi o meu pensamento para comprá-las ... e comprei 6.

Por curiosidade, MyMemory enviou-me cada um delas num pacote diferente. Não muito bom para o ambiente.

Quando elas chegaram, eu fiz alguns testes com o Utilitário de Disco, e para mim foi um pouco dececionante.



Como podem ver, a leitura tem um desempenho bom, mas é tão bom quanto o minha PEN USB 2.0 UDP .

Agora, com seis PENs, eu não vou comprar outras. Mas há um pico de esperança ... como o primeiro pico na escrita. Provavelmente, esse pico pode ser o suficiente para no RAID em geral ganhar melhor desempenho.

Que nível de RAID escolher

Não vou explicar as diferenças entre os níveis de RAID, porque eles estão bem documentadas na internet.

RAID 0 - Têm o melhor desempenho na escrita e melhor preço por GB, mas não é utilizável porque se uma PEN falhar, todo o RAID irá falhar, mas vou testá-lo para comparação.

RAID 5 - Bom preço por GB, mas falta-lhe o desempenho na escrita, mas de quanto?

RAID 50 e 05 - a um custo pouco maior de preço, mas juntando a distribuição com espelhamento, provavelmente vai ter melhor desempenho que só RAID 5.

RAID 10 e 01 - o mais caro, mas ele deverá um bom desempenho... bem vamos testá-lo.

Para fazer o teste, para fazer os testes liguei as 6 PEN no computador e dividi cada uma em 6 partições



Com ele, eu criei seis unidades RAID, cada uma com 6 partições, uma de cada PEN e no final fiquei com o seguinte cenário:










Os primeiros 3 são níveis de RAID suportados diretamente pelo mdadm, mas os outros três são combinações de níveis de RAID, porque eles não são diretamente suportados pelo mdadm.

Com esta configuração eu tenho esse tamanho total dos volumes



E a esta altura, o vencedor é o RAID 5, seguido por seus irmãos de 50 e 05.

O ponto seguinte é testar a taxa de transferência de escrita. Para fazer isso, eu criei dois testes ... um com o dd a copiar 4G de /dev/zero, e outro mais realista para a sua utilização, criei sete diretorias com três conjuntos de imagens, um em raw e outro em jpeg. Em seguida, com o rsync, foram copiados da memória e entre cópia de cada diretório esperei 5 segundos. O último teste é o mais próximo que eu me lembre de como simular o uso real. Todos os testes foram feitos três vezes para verificar a consistência.

E os valores iniciais com o dd foram dececionantes.



Todos os RAIDs com nível 5, os resultados foram miseráveis. Durante os testes, eu guardei alguns dados como era a escrita em cada partição com dstat. Os dados e gráficos estão nos arquivos deste post. Esta informação permitiu a criação deste gráfico



Mas como irá comparar com o teste mais semelhante com a realidade.



Quaisquer conclusões com estes testes ... Tendo tomado as notas destes valores, eles são muito semelhantes durante as rondas e os conjuntos. Como podem ver, há muitas células com valores ~107MB/s, ~35 MB/s e ~15MB/s em todos os níveis RAID.



Com estes resultados, o RAID 5 tem mais hipóteses de ser escolhido, mas porque é isso acontece. Provavelmente algum tipo de memória cache no RAID antes de os dados serem enviados para a unidade física.

Eu tentei encontrar a resposta a isto pesquisando um pouco, mas acabei por encontrar encontrar algo mais útil.
Existe um parâmetro em RAID 5, que afeta o desempenho: stripe_cache_size

No StackExchange há uma resposta que explica um pouco.

http://askubuntu.com/questions/19325/improving-mdadm-raid-6-write-speed

Neste blog tem um gráfico de como o valor desse parâmetro afeta o desempenho de escrita

http://peterkieser.com/2009/11/29/raid-mdraid-stripe_cache_size-vs-write-transfer/

O porquê ... Não encontrei ...

O valor de omissão no sistema é de 256, mudei para 8192 e refiz os testes com o RAID 5... vejam as diferenças



E podemos verificar a velocidade de escrita ao longo do tempo



WOW ... grande diferença ... afinando o RAID 5, não há mais perguntas que nível de RAID que vou usar no meu RaspPhotoPipe.

Mas todos estes testes foram feitos no meu computador de secretária, e não no RaspberryPI. Assim, o próximo post sobre armazenamento será de como configurar e afinar o RAID 5 no RaspPhotoPipe.


Portable Power for my RaspPhotoPipe

posted 14 Feb 2013, 11:55 by Flip Pipe   [ updated 14 Feb 2013, 13:19 ]

Hoje encontrei mais uma peça para o meu projeto.... adicionar uma fonte de alimentação para quando sair fora de portas... ou melhor, não é adicionar uma fonte de alimentação mas sim criar um circuito com um regulador de corrente 7-40v DC, que como diz o artigo.... dá muitas possibilidades...

Deixo-vos aqui o link.

Já agora, hoje adicionei uma forma de poderem deixar comentários aqui... graças ao trabalho de Morteza Mirmojarabian... vejam aqui como.

Encontrei dois conversores no DealExtreme, logo vejo por onde vou:

http://dx.com/p/166930 e http://dx.com/p/151211

Expansão de armazenamento

posted 13 Feb 2013, 13:11 by Flip Pipe   [ updated 13 Feb 2013, 13:11 ]

Um dos objetivos do projeto é adicionar espaço de armazenamento extra. Isto porquê? Porque o espaço de armazenamento em Compact Flash (CF) custa 3x mais.

Vamos ver uma comparação:
 
 
 
 Sandisk Cruzer Switch USB 2.0 Flash Drive - Black + Red (32GB)
$23.80
$0.74/GB
 SDHC SD Memory Card - Blue (32GB / Class 10)
$25.30
$0.79/GB
 Transcend 400X 32GB Compact Flash
$87.00
$2.71/GB

Os cartões Compact Flash são usados nas DSLR devido à sua capacidade de escrita:  167MB/s, contra 25MB/s dos SHDC (ver na wikipedia)

Segundo o site DealExtreme, a pen USB que mostro só grava a 10MB/s (o normal deste formato miniatura), o SDHC a 14MB/s. Não informam sobre o CF, mas se este cartão fosse 133x, teria um débito de 25MB/s... sendo de 400x, deve dar mais um bocadinho...

Já agora, como nota de rodapé, o interface USB 2.0 é limitado a 60 MB/s.

Mas depois de ter despejado o buffer para o cartão, essa qualidade dos CF já não é mais necessária, por isso, porque não adicionar mais espaço num tipo de armazenamento mais barato.

No Raspberry Pi, existem duas opções... ou um cartão SD grande... ou muitas pen usb ligadas a um hub. Por isso a ideia é arranjar um hub usb compacto e algumas pen usb.

  ou      ou ainda       com mais isto   


Depois de ter isso, é tentar configurar um raid... com discos normais é trivial... agora com pens usb, acho que ser trivial com a ajuda deste site:

Outra coisa é que nível de raid usar, usando como premissas 4 pens usb de 32GB:

Raid 0; 128Gb e ganhos na escrita... mas se uma flash se estraga, deve ir tudo para o lixo.
Raid 5: 96GB e sem ganhos na escrita... mas se perder uma das pens, os dados ainda ficam intactos.
Raid 10: 64GB de armazenamento e duplico a velocidade de escrita e posso perder uma pen.
Raid 1: Este está praticamente excluído... só fico com 32Gb disponíveis e não ganho nada em velocidade.

Mais tarde logo vejo como irei fazer isto....

Wifi e Web Server

posted 12 Feb 2013, 03:06 by Flip Pipe   [ updated 12 Feb 2013, 03:20 ]

Desta vez encontrei um projeto semelhante para o BeagleBoard. Chama-se Photo CamCon. Lá encontrei informação de como colocar o BeagleBoard a fazer de AP e código para um web server de front-end.

E procurando mais um pouco... encontrei informação de como o fazer com o raspberry pi e qual a pen a comprar que já está na lista de compras.

Juntar gphoto2

posted 12 Feb 2013, 02:33 by Flip Pipe   [ updated 12 Feb 2013, 02:33 ]

Mais um link para adicionar aos bookmarks deste projeto... desta vez a integração do gphoto com uma nikon. Uma ideia que fica é adicionar um botão para iniciar os scripts que se tiver no raspberry pi, ou em alternativa, usar o lirc para usar um comando remoto de infravermelhos... fica mais uma ideia para explorar mais tarde.

Shutdown ao Raspberry Pi

posted 11 Feb 2013, 06:39 by Flip Pipe   [ updated 11 Feb 2013, 06:39 ]

Um problema que vou ter mais tarde é desligar de forma harmoniosa o Raspberry Pi, porque retirar só o cabo de energia deve ficar para última opção, por isso, deixo aqui um link para usar o udev para quando se retirar um determinado dispositivo USB ele fazer shutdown.

A ver se mais tarde encontro alguma solução para usar o GPIO.

Primeiras Compras

posted 10 Feb 2013, 11:59 by Flip Pipe   [ updated 22 Feb 2013, 13:27 ]



Antes de começar o projeto é preciso ir às compras.

O Raspberry Pi vêm da InMotion, uma empresa do Porto...


Before starting the project I need to go shopping.

The Raspberry Pi, a company in Oporto(Portugal)...

 

Mas como é preciso mais umas coisas para ligar o Raspberry Pi, fui às compras ao DealExtreme:

1 Cartão de Memória para meter o sistema operativo.


But since it takes a few more things to connect the Raspberry Pi, I went shopping at DealExtreme:

One memory card to the operating system
.

 
Depois um conversor HDMI DVI e um cabo plano hdmi para a instalação do sistema operativo
 
Then a DVI to HDMI converter and a hdmi plan cable to install the operating system
.

   

 E por fim, a energia

 
Finally, the energy
 
 
E agora é esperar duas semanas ou mais para que as coisas cheguem de Hong Kong até cá.


And now is wait two or more weeks for this arrive from Hong Kong.



1-9 of 9

Comments