Hi , I'm the nasty person that pointed out that the rt-preempt patches DOES provide and strive to provide deterministic HARD realtime for the linux kernel. Hard realtime is as you pointed out bounded by being deterministic, so all talk about microseconds and relative latencies are not really relevant per your own definition. On a good system worst case latencies of around 10-20 usec is on par with RTAI or RT-Linux, they have lower averages, but more jitter so about the same worst cases, and since worst case is what limits the system they are somewhat comparable, hardware makes a bigger difference. Now if were talking hardware, no regular PC with virtual memory, superscalar execution and multitasking will ever provide much less than some usec's ... due to hardware latencies. You said that preempt-rt doesn't provide hard realtime and never will, to and I pointed out in an email that that was your opinion and that I considered that FUD, and sent a link to the osadl.org site wich have a test rack to track worst case latencies on systems run under long time and high load, if that is not deterministic I don't know what is, as far as discussing a common PC. I also pointed out that is was quite rude to make such a statement on the linux-rt list, since most people here are working on getting rt-preempt as good as possible with the goal of exactly hard realtime. So difference of opinion is totally acceptable, but stating that opinions are the truth is something else, now statements like lala-land is just degoratory and are clearly meant to be insulting. I do consider you misinformed and wrong in opinion based on your statement that the definition of hard realtime is if it has a deterministic worst case behaviour or not, but I do hope that I haven't been rude. / regards, Lars Segerlund. 2012/4/24 Mark Hounschell <markh@xxxxxxxxxx>: > On 04/24/2012 12:26 PM, Sven-Thorsten Dietrich wrote: >>> >>> >>> Your in lala land. The Linux kernel, even with the RT patch has so much >>> "per CPU" crap in it, there is no way to prevent it from steeling usecs from >>> your application. The per CPU timer interrupt alone takes a few usecs away >>> from your application every HZ. A hard RT env is one in which you can >>> always, every time, do a predefined work in the same amount of time. Fast or >>> slow isn't the key. It's determinism. The timer interrupt alone prevents >>> that. And it's not the only thing. I've got 8 cpus on my machine but the >>> kernel has to have a piece of every one of them. Until there is isolation >>> from the kernel, there cannot be "Hard RT". This is fact. >>> >> >> >> Mark, >> >> there is a big difference between real-time processing and bare-metal >> processing. >> >> In bare metal, we do care about individual cycles, but not all real-time >> is bare-metal. >> >> Determinism , or "RT requirements" is defined by the application. >> >> Many applications, with critical functionality, that we an define as hard >> real-time, >> can exist fine using the Linux kernel as infrastructure and meet deadlines >> in a time-critical manner. >> >> The OS meets deterministic hard-real-time requirements, if the application >> is not late to execute. >> >> Generally, hard real-time is defined as the value of the computation being >> at most 0 when executed late. >> >> Soft real time implies a diminished value. >> >> Bare metal today, since you bring up counting cycles, is a bit hard to >> reach with all the caching layers, pipelining, memory and bus architecture >> and so on, all aimed at throughput. >> >> You will be hard pressed to find predictable behavior in anything but the >> simplest loops, bare-bones CPUs, and even then, pressure to differentiate in >> the market ends up with odd designs making CPUs do funky things. >> >> Please do refrain from making such broad and sweeping statements, such as >> calling people in lala land (I have been there and its quite nice btw). >> > > Yea, I've been there too. But go back to the OP. I then was simply informing > him of what Hard RT (you may call it bare-bones if you like) was and still > is in my opinion. I was then accused of spreading FUD by someone named Lars. > The response you quoted above was my response to being accused of spreading > FUD when I gave my opinion of what Hard-RT and the RT patch set is. > > I've been in the Hard and Soft RT business since the 70s and understand what > it is, why it is, how programmers in the past have done things considered > wrong now, simply because they could then, and that there really isn't any > hardware designed for it these days. But even if there was, what you quoted > above would still be true. > > I will have to admit though that processing speed has certainly helped in > recent years. We are able to replace _some_ of these old "designed for HRT" > machines with modern boxes simply because they are so fast. Maybe when they > are fast enough to handle timer interrupts in less than a usec or so, I'll > be able to replace more of them. > > But, as my original response to the original OP was, the RT kernel patch is > NOT making the kernel capable of HARD RT but certainly gives good Soft RT > results. If ya lower the bar, you'll never get to the top of the pole. > > Regards > > Mark > -- > To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
