| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. |
| |
Estando muito longe de ser um especialista em sistemas operativos, sempre me espantou por que razão é que esta área do real-time não estava mais desenvolvida. Parece-me que facilitava imenso a obtenção de garantias de funcionamento "determinístico" das aplicações quando confrontadas com muita carga.
Eu sei que há alguns sistemas operativos real-time que são habitualmente usados "embeded" para fins muito específicos, mas nunca vi isso usado por exemplo em sistemas bancários. Já em telecomunicações o caso deve ser um pouco diferente.
Alguém com mais experiência que se pronuncie.
|
| |
| |
| | A unica vez que ouvi falar do uso do Linux em sistemas real-time foi.. na Nasa, na sonda que tinha sido enviada para Marte. Fora isso, só mesmo no boot dos pc's da faculdade, onde uma das sub-opções "Linux" é uma versão RT do redhat.
---------------------
The worst moment for the atheist is when he is really thankful and has nobody to thank. Dante Rossetti |
| |
| | | Um sistema operativo real-time têm como objectivo garantir que as coisas acontecem em momentos precisos(microsegundos ou menos) para interagir com sistemas fisicos.
Os sistemas operativos interactivos (isto é, os normais) sacrificam isso para um compromisso entre o máximo de trabalho por unidade de tempo e alguma interactividade com o utilizador.
No outro extremo, estão os sistemas batch que tentam apenas garantir o máximo de trabalho por unidade de tempo.
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| |
| |
"Um sistema operativo real-time têm como objectivo garantir que as coisas acontecem em momentos precisos(microsegundos ou menos) para interagir com sistemas fisicos."
Não é necessariamente da ordem dos micro-segundos, a definição é mais lata. A ideia é que há garantias temporais, independentemente da grandeza.
Por outro lado, também não é obrigatoriamente para os fins que referiste, pode ser qualquer coisa. O que se passa é que habitualmente os S.O.s tempo-real são utilizados para isso.
|
| |
| | Os SO realtime são usados sobretudo em aplicações de Controlo Industrial I.E. Centrais Térmoeléctricas, Nucleares ou então em Pequena escala "embedded" em controladores de Válvulas, Motores, Relays, Elevadores, Comboios, ou a Sonda Marciana...
Isto acontece porque grande parte da teoria do controlo de processos se baseia em controlo deterministico tempo real.
A consagração do Linux como um Sistema Realtime permite-lhe ser considerado como uma alternativa viável para projectos de controlo.
Talvez sirva também de "boost" para o Real Time Java...
|
| |
| | Em termos de telecomunicações é bastante usado o VxWorks da WindRiver, que na minha opinião é a referência como embeded real-time OS, sendo usado em empresas como a NASA ou mais recentemente na Formula 1 para telemetria (tendo aplicações de relevo na robótica,etc...)
|
| |
| | Em termos de telecomunicações é bastante usado o VxWorks da WindRiver, que na minha opinião é a referência como embeded real-time OS, sendo usado em empresas como a NASA ou mais recentemente na Formula 1 para telemetria (tendo aplicações de relevo na robótica,etc...)
vxworks e' a ref no mercado, alem da nasa trabalham tb com a esa, mas acho que o topico refere-se a linuxes como rtos :)
mas nem a proposito falar da windriver, neste dia triste que vai ficar na curta historia da informatica. Parece que agora e' de vez o adeus ao bsdi/bsdos, e' pena.
This letter is your official notification that we are initiating the retirement phase for all of our BSD/OS-based products, including BSD/OS ISE. The difficult economic situation of the past few years, as well as other market factors, have forced us to re-evaluate our products and realign our product offerings to meet the long term needs of our customers.
This was a very difficult decision, one which we did not make lightly.
Make World; Not War; |
| |
| | Um pouco off topic mas falando em NASA, vejam esta noticia já bem antiga. Ao que parece conversões entre metros e polegadas ainda confundem o pessoal.
|
| |
| | Desculpem a ignorância... mas kual o objectivo, ou as vantagens do Linux Real-Time?! Lembra-me de aki à tempos ler qq koisa sobre isso, mas n faço ideia... para q serve? onde se aplica? Brigado.
Ya_Ba - I can take you where living can't... |
| |
| |
| | | Vantagens: 1-Flexibilidade 2-Podes ver o código. 3-Interoperabilidade 4-Licenciamento Objectivo: Ummm, isto também é vantagem mas teres uma plataforma comum e acrescentares valor com diferenciação é atractivo para os fabricantes.
"No comments"
|
| |
| |
Julgo que a pergunta teria mais a ver com o facto de ser "tempo-real" do que com o facto de ser Linux.
No tempo-real há a garantia de que algumas tarefas são executadas de certeza num determinado tempo máximo e/ou que de certo em certo tempo é possível garantir que uma determinada rotina é executada.
|
| |
| | Aquisicao de dados e todo o tipo de analise que requer sincronizacao temporal precisa.
## I live the way I type; fast, with a lot of mistakes. |
| |
|
| |
Pelos vários comentários que apareceram depois do meu anterior, julgo que não terei sublinhado devidamente o ponto que queria focar.
A minha dúvida/estranheza é por que é que não se usa mais o tempo-real nas aplicações "normais", e não apenas naquelas onde tradicionalmente esta característica é aproveitada.
O tempo-real (pelo menos aparentemente para mim...) permitiria obter mais facilmente garantias de qualidade na execução de deterninadas tarefas e certezas quanto à capacidade do sistema responder em carga elevada.
As situações típicas de crash por pico de solicitações (especialmente no caso de interacção com bases de dados pesadas) poderiam provavelmente ser melhor tratadas com ferramentas que possuissem características de tempo-real. Assim era possível saber à partida exactamente a carga que o sistema suportava e o instante exacto em que era necessário recusar novos pedidos.
Ainda nesta onda, sempre achei estranho que haja tantos servidores que antes de aceitarem um pedido qq não vejam se a carga é suficientemente baixa para que ele possa efectivamente ser tratado. Isto pode evidentemente ser resolvido também sem o tempo-real, neste caso será só má programação. Mas, mais uma vez, se o próprio S.O. estivesse já especialmente preparado para ajudar...
|
| |
| |
| | | Hmm.. os sistemas real-time baseiam-se em prioridades. Garantir que a tarefa A é executada no momento t1, interrompendo tarefas com menos prioridade para que isso aconteça. Mas não é capaz de garantir que a tarefa é executada num certo limite de tempo. Os sistemas real-time não inventam performance a partir do ar..
Na verdade, perdem: os sistemas não real-time tomam a liberdade de fazer as coisas nos momentos que acham mais opurtunos e não nos momentos especificados pela aplicação, aumentado assim a performance global, quando vista ao longo de uma janela de tempo relativamente longa.
Não estou a ver como aplicar real-time a algo como uma base de dados ou um webserver. Se eles têm más politicas e aceitam mais pedidos do que os que conseguem servir, é má concepção.
Mas não estou a ver a vantagem de garantir que X acontece no momento Y. Isto não faz com que uma query demore menos tempo a ser processada..
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| |
| |
"Mas não é capaz de garantir que a tarefa é executada num certo limite de tempo. Os sistemas real-time não inventam performance a partir do ar.."
(...)
"Isto não faz com que uma query demore menos tempo a ser processada.."
Quanto ao tempo, o que eu quero dizer é que se pode saber à partida se o s.o. vai ou não conseguir realizar a tarefa qualquer que seja a altura em que ela é solicitada. Evidentemente que não consegue realizar _qualquer_ tarefa... :-)
Quanto ao exemplo das BDs, o objectivo não seria aumentar a performance no sentido de maximizar o número de queries atendidas, mas sim aumentar a qualidade do desempenho pelo facto de se conseguir à partida saber ao certo quantas queries se aguentavam num pico de solicitações, por exemplo, prevendo assim melhor as medidas a tomar em caso de ultrapassagem desse limite.
É nesse sentido que eu falo em "determinismo". Trata-se de um sistema em que o seu estado está mais sob controlo, é mais independente da carga a que está sujeito do que os s.o. "normais".
|
| |
| | Não estou mesmo a ver como aplicar um sistema real-time a isso..
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| |
| | Eu tb não, normalmente a Qualidade de Serviço nas Aplicações consegue-se afinando pools, de Threads ou outros recursos como ligações a BD.
O real-time poderia eventualmente ser utilizado para termos Schedulers fiáveis e com garantia de execução, tipo fazer um query exactamente de hora a hora ou chamar uma transacção todos os 15 seg, mas para que é que isto serve?
|
| |
| |
O mesmo raciocínio que se faz nos sistemas de controlo com RTOS, em que é fundamental ter acções/reacções do OS em timings certos para garantir o correcto funcionamento do sistema controlado, poderia ser aplicado a qq outro sistema cliente-servidor em que se queira assegurar um throughput máximo "determinístico".
Seria apenas aplicar os mesmos métodos pelas mesmas razões.
|
| |
| | Encontrei um excelente comentário sobre esta temática aqui...
|
| |
