Duvida sobre o linux

[msamsoniuk]

neste caso nao vejo diferenca do linux para um rtos, pq as mensagens IPC do linux parecem sincronizar threads tal qual ocorre em outros rtos, como o chorus por exemplo... a ultima vez que eu usei mensagens IPC no linux, a performance estava na casa de 10 mil mensagens/segundo sem usar extensoes realtime no kernel... e como cada mensagem grande tinha uns 4KB de tamanho, o volume de trafego estava na ordem de 40MB/s, bem razoavel para um P166

de qq forma, a performance envolvendo a paralela vai ser sempre menor, por que a intel o considera um dispositivo "legado"... uma alternativa a paralela seria a interface ATA, que nao deixa de ser uma paralela modernizada com largura de 16 bits e capaz de operar com DMA até 133MB/s.

[polesapart]

neste caso nao vejo diferenca do linux para um rtos, pq as mensagens IPC do linux parecem sincronizar threads tal qual ocorre em outros rtos, como o chorus por exemplo... a ultima vez que eu usei mensagens IPC no linux, a performance estava na casa de 10 mil mensagens/segundo sem usar extensoes realtime no kernel... e como cada mensagem grande tinha uns 4KB de tamanho, o volume de trafego estava na ordem de 40MB/s, bem razoavel para um P166

A minha colocação com relação ao rtos era justamente em termos de regularidade dos eventos, não de performance bruta. Neste último quesito até o windows 9x consegue alguma pontuação

[msamsoniuk]

opa! o resultado com o rtos vai ser exatamente o mesmo do linux! observe bem as grandezas envolvidas, pq um rtos vai melhor que o linux ateh certo volume, dai para frente ele capota tambem!

o cliente manda mensagem interprocesso, o server recebe e manda para a paralela... essencialmente, o sistema vai alternar entre estas duas threads, indiferente de ser um linux ou rtos, entao vc vai ver na paralela um fluxo nao continuo de dados... nao tem jeito! a paralela trabalha na casa de 1MB/s, nao tem como vc agendar um timer de 1MHz para escalonar processos de forma sincronizada... a partir de certo valor, a unica saida sao loops de delay, mas uma hora as threads escalonam e o fluxo de dados para, mesmo no rtos!

pelo que sei, a unica forma de obter um fluxo continuo de dados sem buracos seria usar DMA, independente de ser rtos ou linux... ou entao usar msdos, q nao tem escalonamento de processos.

neste caso nao vejo diferenca do linux para um rtos, pq as mensagens IPC do linux parecem sincronizar threads tal qual ocorre em outros rtos, como o chorus por exemplo... a ultima vez que eu usei mensagens IPC no linux, a performance estava na casa de 10 mil mensagens/segundo sem usar extensoes realtime no kernel... e como cada mensagem grande tinha uns 4KB de tamanho, o volume de trafego estava na ordem de 40MB/s, bem razoavel para um P166

A minha colocação com relação ao rtos era justamente em termos de regularidade dos eventos, não de performance bruta. Neste último quesito até o windows 9x consegue alguma pontuação

[polesapart]

Acho que estamos saindo (só um pouco?) do foco. O que o cara queria era ler dados da paralela com certa regularidade. Supondo que não tenha um jeito de fazer o modo ECP da maldita comandar DMA para leitura (que eu lembre é só pra envio), o negócio é fazer polling. Teria que fazer isto na thread (ou no que for) que tenha acesso direto a paralela. Daí se você vai enviar isto pra outra thread ou processo com menor prioridade, é irrelevante. O problema é garantir que a thread, ou processo, seja em espaço de usuário ou de kernel, alcance esta certa regularidade.

Este tipo de mecanismo é facilmente implementado (ainda que dentro de certos limites) num rtos, pois a construção dele é baseada na idéia de que eventos de certa prioridade serão sempre atendidos em detrimento aos demais, com um certo limite mínimo de jitter e um certo limite máximo de latência, que são fatores conhecidos ou pelo menos mensuráveis. (Claro que em alguns programas que rodam sobre um rtos um mané põe um disable interrupt no ponto errado e a coisa não funciona como deveria).

No linux standard dá pra fazer isto? Claro, se as grandezas aceitávelis (incluindo os gaps na leitura ) estiverem na ordem das dezenas de ms, não vejo por que não. Mas não parece ser o caso

[msamsoniuk]

com uma cadencia decente? ****nenhum**** rtos vai permitir. note a quadrupla enfase... ****nenhum****! nao tem como escalonar isso na cadencia que se espera da paralela... justamente pq qq OS preemptivo vai contra isso! portanto o negocio seria investir em DMA! mas como soh tem 1 request, teria q escolher uma direcao (somente leitura ou somente escrita)

[xultz]

OK, vamos reprojetar o PC então

[polesapart]

com uma cadencia decente? ****nenhum**** rtos vai permitir. note a quadrupla enfase... ****nenhum****! nao tem como escalonar isso na cadencia que se espera da paralela... justamente pq qq OS preemptivo vai contra isso! portanto o negocio seria investir em DMA! mas como soh tem 1 request, teria q escolher uma direcao (somente leitura ou somente escrita)

Pode ser que no caso prático um hardware modesto não tenha meios de atender isto usando o melhor dos modelos.

Mas você está mal informado quando afirma que qualquer os preemptivo vai contra isto. Existe mais de um modelo de preempção além daquele que você conhece. Num O/S convencional, quando existem tarefas de prioridades idênticas, você só consegue garantir um timeslice entre elas, usando um mecanismo de comutação por timer. Note que a meu ver isto já resolve o problema, supondo que o hardware esteja adequado e que o sistema não seja um kernel pesado com tarefas pesadas.

Mas vamos alêm... existem modelos em que cada tarefa existente possui uma prioridade única. Assim quando uma tarefa de ordem superior precisa rodar, a tarefa de prioridade inferior é empilhada e a tarefa superior roda em modelo RTC (run to completion), ou seja, executa o que tem que fazer e finaliza. A tarefa inferior então continua. Este modelo de preempção é adotado ao menos pela quantum platform, e funciona muito bem.

Acho que você tem dificuldades em comparar o modelo rtos a um modelo "os". O rtos não garante que você vai ser capaz de extrair todo o "suco" do hardware, apenas que vai conseguir fazê-lo dentro de parâmetros deterministicos, que podem ser longe do ideal e podem ser insuficientes pra atender certas condições, mas dentro destas condições, qual o problema que você enxerga? Alguns sistemas chamados de rtos não são tão realtime assim. Porém comparar este modelo a um modelo de O/S sem garantias de tempo e onde existe um kernel trabalhando com tarefas complexas que são executadas com grande variabilidade de tempo é como comparar alhos com bugalhos.

Recomendo que você releia o que o cara pediu no inicio da thread e pense se é algo assim tão absurdo O que ele quer é ler a paralela a cada 20ms, ele não quer ligar uma OC-92 através de um transceptor na paralela e fazer um mirror do slackware

[msamsoniuk]

OK, vamos reprojetar o PC então

pois eh, a intel esta tentando a anos e nao consegue... e estas limitacoes idiotas explicam pq as vezes um PIC funciona melhor que um PC de mesa!

[msamsoniuk]

com uma cadencia decente? ****nenhum**** rtos vai permitir. note a quadrupla enfase... ****nenhum****! nao tem como escalonar isso na cadencia que se espera da paralela... justamente pq qq OS preemptivo vai contra isso! portanto o negocio seria investir em DMA! mas como soh tem 1 request, teria q escolher uma direcao (somente leitura ou somente escrita)

Pode ser que no caso prático um hardware modesto não tenha meios de atender isto usando o melhor dos modelos.

Mas você está mal informado quando afirma que qualquer os preemptivo vai contra isto. Existe mais de um modelo de preempção além daquele que você conhece. Num O/S convencional, quando existem tarefas de prioridades idênticas, você só consegue garantir um timeslice entre elas, usando um mecanismo de comutação por timer. Note que a meu ver isto já resolve o problema, supondo que o hardware esteja adequado e que o sistema não seja um kernel pesado com tarefas pesadas.

nao fique bravinho alex, mas quem anda mal informado eh vc! hahaha =)

para simular um IO sincrono, sem jitter ou slip na sinalizacao, vc teria que ter um sistema de escalonamento de processos *totalmente* deterministico... o simples fato de ter prioridades, outras interrupcoes ou qq especie de multiplexacao de recursos ou utilizacao sob demanda destruiria o determinismo do sistema e faria a sinalizacao sofrer com jitter ou slip.

a efetividade dessa solucao tambem nao vai muito longe, por uma serie de motivos. primeiro que a troca de contexto consome um certo tempo, entao o timer que vc vai utilizar nao vai servir para sinalizacoes que requerem bases de tempo agressivas. segundo que as tasks devem ser sincronas, portanto elas tem que desempenhar suas atividades inteiramente dentro daquele time-slice, sob pena de ocorrer jitter ou slip... mas como eh um recurso compartilhado, se nao de tempo alguem tem que sair perdendo. terceiro que as tasks rodam sucessivamente, entao vc nao consegue simultaneidade na ativacao de diferentes sinalizacoes... e por aih vai.

ao contrario do que vc falou, isso eh possivel em hardware modesto, justamente pq as necessidades de uso simultaneo de recursos sao menores e controlados. em sistemas maiores vc tem tanta falta de determinismo no sistema que fica impossivel simular IO sincrono por software. a vantagem de ter um hardware maior, por outro lado, eh que vc pode fazer o IO sincrono por hardware, utilizando DMA, por exemplo.

Mas vamos alêm... existem modelos em que cada tarefa existente possui uma prioridade única. Assim quando uma tarefa de ordem superior precisa rodar, a tarefa de prioridade inferior é empilhada e a tarefa superior roda em modelo RTC (run to completion), ou seja, executa o que tem que fazer e finaliza. A tarefa inferior então continua. Este modelo de preempção é adotado ao menos pela quantum platform, e funciona muito bem.

pois eh, eu trabalho com um rtos similar a esta que vc descreveu e isso nao resolve problema algum em termos de simular IO sincrono. a unica sinalizacao isenta de jitter e slip seria a sinalizacao controlada pelo processo de maior prioridade, ficando o resto zuado. se vc tem varias sinalizacoes importantes e independentes, vc teria que na pratica ter um processador por sinalizacao.

soh para mostrar como a vida eh dificil, o simples processamento de sinalizacao CAS a cadencia de 125us eh algo que consome 50% dos recursos de um microcontrolador de velocidade bem consideravel.

Acho que você tem dificuldades em comparar o modelo rtos a um modelo "os". O rtos não garante que você vai ser capaz de extrair todo o "suco" do hardware, apenas que vai conseguir fazê-lo dentro de parâmetros deterministicos, que podem ser longe do ideal e podem ser insuficientes pra atender certas condições, mas dentro destas condições, qual o problema que você enxerga? Alguns sistemas chamados de rtos não são tão realtime assim. Porém comparar este modelo a um modelo de O/S sem garantias de tempo e onde existe um kernel trabalhando com tarefas complexas que são executadas com grande variabilidade de tempo é como comparar alhos com bugalhos.

depende... na pratica os conceitos sao intercambiaveis pq resolvem o mesmo problema de formas diferentes!

a maioria dos rtos que eu conheco sao dimensionados para trabalhar dentro de janelas de no maximo 125us sem slip e requerem ainda hardware extra para eliminar jitter em IO sincrono, na forma de FIFOs. por outro lado, conheco muitas solucoes equivalentes implementadas em sistemas operacionais convencionais cuja base de tempo eh apenas 10ms, mas rodam em cima de hardware melhor e conseguem atender os mesmos requisitos de slip e jitter dos sistemas que rodam rtos.

eh facil achar exemplos que ninguem discute: o controlador de video e ethernet em um PC sempre utiliza DMA e sempre possui hardware dedicado... mas muita gente gera video e ethernet por software em microcontroladores pequenos... se o PC tem um clock tao alto, pq nao fazer por software ? pq eh um desperdicio e nao eh eficiente.

Recomendo que você releia o que o cara pediu no inicio da thread e pense se é algo assim tão absurdo O que ele quer é ler a paralela a cada 20ms, ele não quer ligar uma OC-92 através de um transceptor na paralela e fazer um mirror do slackware

hahaha olha a *idade* chegando ae alex!

ele escreveu 20 microsegundos (50KHz) e nao 20 milisegundos (50Hz). na pratica, se ele ativar um strobe para a leitura, o que ele vai medir na saida eh um burst de 1000 pulsos por 20ms e 20ms parado. solucao para isso existe com interrupcao ou DMA, mas uma solucao alternativa mais simples seria manter a leitura por software e bufferizar a entrada com uma memoria FIFO, de modo que a entrada fica cadenciada a 50KHz sem jitter ou slip e o outro lado simplesmente le a FIFO o mais rapido possivel, em qq cadencia. eh muito mais simples!

bom, nao vou mais discutir isso com vc... a menos que vc pare de ser ranzina e pague uma pizza para mim e para o xultz!

[polesapart]

... cortei...
ao contrario do que vc falou, isso eh possivel em hardware modesto, justamente pq as necessidades de uso simultaneo de recursos sao menores e controlados. em sistemas maiores vc tem tanta falta de determinismo no sistema que fica impossivel simular IO sincrono por software. a vantagem de ter um hardware maior, por outro lado, eh que vc pode fazer o IO sincrono por hardware, utilizando DMA, por exemplo.

Ok, me dou por vencido, pelo menos olhando por este lado. O pior é que eu realmente fiquei esclerosado e comparei as alternativas para um alvo de 20 mili, não 20 micro. 20 mili me parece plenamente alcancavel mesmo numa cpu com 4mb de cache fazendo flush direto. Mas a tendência só não é piorar este quadro nos grandes computadores pq estão tendo mais cores e barramentos multi-via, pelo menos estão tentando ir por este caminho, pq logo logo vc teria um pc com 16 cores e um barramento de ram gigante e teria dificuldades pra sincronizar o vídeo com o áudio de um simples dvd

pois eh, eu trabalho com um rtos similar a esta que vc descreveu e isso nao resolve problema algum em termos de simular IO sincrono. a unica sinalizacao isenta de jitter e slip seria a sinalizacao controlada pelo processo de maior prioridade, ficando o resto zuado. se vc tem varias sinalizacoes importantes e independentes, vc teria que na pratica ter um processador por sinalizacao.

Acredito que dependeria do quanto seria aceito de jitter e de quanto defasado fossem os pontos de sincronismo dos circuitos envolvidos. Mas como quanto mais rápido um barramento mais "delicado" fica, realmente o limite é frágil. Só não diga que no caso em que você só tem um conjunto síncrono isto é ****impossível**** cheio de asteriscos, que aí eu te esfolo e não te pago pizza. ehehehe.

]

depende... na pratica os conceitos sao intercambiaveis pq resolvem o mesmo problema de formas diferentes!

a maioria dos rtos que eu conheco sao dimensionados para trabalhar dentro de janelas de no maximo 125us sem slip e requerem ainda hardware extra para eliminar jitter em IO sincrono, na forma de FIFOs. por outro lado, conheco muitas solucoes equivalentes implementadas em sistemas operacionais convencionais cuja base de tempo eh apenas 10ms, mas rodam em cima de hardware melhor e conseguem atender os mesmos requisitos de slip e jitter dos sistemas que rodam rtos.

Pô, mas aí é alhos e bugalhos de novo. Num mesmo PC xexelento vc vai ter que dizer que é ****impossível**** alcançar 125 µs com um o/s convencional, mas vai ter dificuldade em afirmar isto e colocar tantos asteriscos se imaginar um rtos bem dimensionado rodando no mesmo hardware, mesmo que tenha que desligar o cache l2 de 4mb da tua cpu multicore. Isto aqui assumindo o caso de só ter um dispositivo síncrono.

hahaha olha a *idade* chegando ae alex!

ele escreveu 20 microsegundos (50KHz) e nao 20 milisegundos (50Hz). na pratica, se ele ativar um strobe para a leitura, o que ele vai medir na saida eh um burst de 1000 pulsos por 20ms e 20ms parado. solucao para isso existe com interrupcao ou DMA, mas uma solucao alternativa mais simples seria manter a leitura por software e bufferizar a entrada com uma memoria FIFO, de modo que a entrada fica cadenciada a 50KHz sem jitter ou slip e o outro lado simplesmente le a FIFO o mais rapido possivel, em qq cadencia. eh muito mais simples!

bom, nao vou mais discutir isso com vc... a menos que vc pare de ser ranzina e pague uma pizza para mim e para o xultz!

Ok, vamos parar de ser chatos e off-topic: o cara pode por um PIC na porta paralela e resolver o problema. Se fosse 20ms ele podia usar ioperm e prioridade realtime, mas como é 20µs e eu vou ter que me acostumar com a idéia de um *dinoussauro* dos tempos do IRC me chamar de velho pq eu não sei mais ler direito, eu vou sair de fininho pela esquerda.

Quanto a pizza, eu tenho uma idéia melhor: pague uma pizza pra mim e pro Xultz na semana que vem que a gente chega a um acordo, mas tem que ser bem grande

[]s

Alex

[msamsoniuk]

]

depende... na pratica os conceitos sao intercambiaveis pq resolvem o mesmo problema de formas diferentes!

a maioria dos rtos que eu conheco sao dimensionados para trabalhar dentro de janelas de no maximo 125us sem slip e requerem ainda hardware extra para eliminar jitter em IO sincrono, na forma de FIFOs. por outro lado, conheco muitas solucoes equivalentes implementadas em sistemas operacionais convencionais cuja base de tempo eh apenas 10ms, mas rodam em cima de hardware melhor e conseguem atender os mesmos requisitos de slip e jitter dos sistemas que rodam rtos.

Pô, mas aí é alhos e bugalhos de novo. Num mesmo PC xexelento vc vai ter que dizer que é ****impossível**** alcançar 125 µs com um o/s convencional, mas vai ter dificuldade em afirmar isto e colocar tantos asteriscos se imaginar um rtos bem dimensionado rodando no mesmo hardware, mesmo que tenha que desligar o cache l2 de 4mb da tua cpu multicore. Isto aqui assumindo o caso de só ter um dispositivo síncrono.

acho que tem que pensar em tres parametros de tempo: jitter, slip e delay, para entao verificar como estes parametros variam conforme vc escolhe um rtos ou um os normal, com o respectivo hardware necessario para que facam o mesmo trabalho.

nao sei se eh o melhor exemplo, mas pense no caso de telefonia tdm, onde os DSPs processam todos os filtros em realtime dentro da janela de 125us entre uma amostra e outra: para eliminar o jitter, usamos um hardware dedicado de sincronismo, o que implica em um delay de 125us entre entrada e saida. para evitar slip, os filtros tem que ser deterministicos e rodar dentro dessa janela. portanto nao temos jitter nem slip, ficando com um delay de 125us.

no caso de telefonia voip, podemos processar exatamente os mesmos filtros, mas em buffers de um stream rtp, o que eh mais eficiente, na medida que o processamento eh feito em blocos. no caso de rtp, eliminamos o jitter usando um hardware dedicado com uma fifo, o que implica em um delay de 10ms entre entrada e saida (para um buffer tipico de 80 byes). os filtros ficam mais eficientes trabalhando em buffers e vc tem uma janela de 10ms para trabalhar sem slip, perfeitamente acessivel a um OS convencional. portanto, novamente, nao temos jitter ou slip, ficando com um delay de 10ms.

note que a diferenca entao entre o DSP rodando um rtos e o PC rodando um os normal eh simplesmente o delay: 125us contra 10ms. embora pareca que o PC seja pior, o delay de 1/100 nao eh desconfortavel e, por outro lado, a eficiencia rodando filtros em intervalos de 10ms eh muito maior no caso do PC com um os convencional, o que significa mais canais com a mesma densidade de processamento que vc teria usando DSPs com rtos.

por outro lado, se o delay tambem deve ser levado em consideracao, nao temos como fugir do rtos! pq o delay comeca nos 10ms... o resultado final pode ser maior, na medida que se vc tiver menos garantia de determinismo, vc vai trabalhar com buffers maior para eliminar jitter e slip.

no caso da paralela, nao vejo opcao mesmo: tem q ter uma FIFO no meio do caminho e, realmente, poderia ser um mcu. neste caso, a interface entre o mcu e o PC nao precisaria nem ser a paralela, poderia ser uma interface serial, usb ou ethernet, apenas lembrando que esta 'packetizacao' vai inserir delay entre a captura e o real processamento das amostras.

Quanto a pizza, eu tenho uma idéia melhor: pague uma pizza pra mim e pro Xultz na semana que vem que a gente chega a um acordo, mas tem que ser bem grande

eh claro que pago, eh soh dizer o dia, o lugar e a hora... mas venham sozinhos e desarmados!

[polesapart]

eh claro que pago, eh soh dizer o dia, o lugar e a hora... mas venham sozinhos e desarmados!

E qual a graça nisso? Vamos levar o chun e ele vai nos convencer que é possível fazer isto em *java* com load de cpu inferior a 0,5%

Vamos combinar então, talvez fds que vêm, o Xultz tem aula durante a semana (Xultz, já tou dizendo que vc vai, tem problema não né? hehe)...

[]s!

[xultz]

Pow, Alex, como é que você pode me comprometer dessa maneira, principalmente sabendo que eu odeio pizza ou qualquer outro alimento calórico, e que vivo só de alface.
Mas como sei do perigo de você e o Marcelo se encontrarem para discutir sobre SO (principalmente depois que você traiu o movimento e passou a usar Debian, deixando o Marcelo conhecido como "o último usuário de Slack", eu vou lá e garanto a segurança dos dois. Porém, se o Chun for, aí eu tou fora, a menos que seja contratada uma equipe de segurança profissional para dar conta de segurá-lo. Eu lembro bem do último que falou mal de Java na frente dele, pobre coitado...
A minha pode ser de 4 queijos, com bastante orégano e borda recheada de catupiry. Apesar que sou mais o calzone do Baggio lá perto de casa.

[msamsoniuk]

soh combinar a data, hora e lugar! hehehe

Pow, Alex, como é que você pode me comprometer dessa maneira, principalmente sabendo que eu odeio pizza ou qualquer outro alimento calórico, e que vivo só de alface.
Mas como sei do perigo de você e o Marcelo se encontrarem para discutir sobre SO (principalmente depois que você traiu o movimento e passou a usar Debian, deixando o Marcelo conhecido como "o último usuário de Slack", eu vou lá e garanto a segurança dos dois. Porém, se o Chun for, aí eu tou fora, a menos que seja contratada uma equipe de segurança profissional para dar conta de segurá-lo. Eu lembro bem do último que falou mal de Java na frente dele, pobre coitado...
A minha pode ser de 4 queijos, com bastante orégano e borda recheada de catupiry. Apesar que sou mais o calzone do Baggio lá perto de casa.