Am 12.08.2013 um 17:48 schrieb John Kasunich <jmkasun...@fastmail.fm>: > > > I wonder how all these new RTOSes and new platforms measure > the passage of real time?
there is no need to wonder, it's all in the open, APIs used and all, and the timing API's are unchanged over at least 10 months: http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=shortlog;h=refs/heads/unified-build-candidate-1 > Back in the simple days, the RTAPI > "get real time" call used the RDTSC instruction to read the time > stamp counter, which was a 64 bit counter, -... > > I'm not sure how well the RTAPI get-real-time call has kept up > with all this complexity. Pretty good as far as the BB platform goes, there is a 200Mhz counter which gives actual results better than the sorta-kinda timings of RDTSC subject to CPU version, powersave trends of the year and phase of the moon. That is the basis for for the API which is being used in the xenomai code: http://www.xenomai.org/documentation/xenomai-2.5/html/api/group__native__timer.html#ga589af3dafaeaa5dcbf2ef7b6dde6af8 If that isnt enough, the PRU also can be coerced into behaving as a highspeed sampling stage, beating halscope by a at least one, if not two orders of magnitude, and no sampling jitter beyond memory latency. I havent researched the RPI, and I dont care, but there is a similar timer register (I think 250Mhz, not sure). For rt-preempt, it's this: http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=src/rtapi/rt-preempt.c;h=364c38277db92fd3d2f3563f7ce54d14c3848b1a;hb=8700564705732f8da0f0a1f821bf40e39cf384b8 , the rest depending on the kernel support for hires timers. IOW: the tools are in place, and they are better than ever before. But it does require looking at, and using what is there. And: those tools have not even been applied yet. > > If the clock is being stopped, the realtime code could stop for a > long time, and when it wakes up it would have no idea that any > time had actually passed. That is an inherent risk of using an > internal measure of time to evaluate "real-time" performance. > > I'm not sure I have anything constructive to offer, but I have to > say this trend is very disturbing. What we have is an observation. This does not match the definition of 'trend' in my statistics course. - Michael > > -- > John Kasunich > jmkasun...@fastmail.fm > > ------------------------------------------------------------------------------ > Get 100% visibility into Java/.NET code with AppDynamics Lite! > It's a free troubleshooting tool designed for production. > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
