Am 14.12.2012 um 11:51 schrieb EBo: > This might be a very good discussion to have directly with the > rt/preempt kernel folks. This is just the kind of thing that is > motivating them to reqoek numerous low level services.
I do not think this will be helpful at this point - this is a problem with the HAL/RTAPI thread specification, or rather the lack thereof being precise in an aspect which might or might not matter, but likely does at the very least the code comment about rate monotonic scheduling and what the implementation actually does dont agree AFAICT to make the point clear, I turn the table on the argument: I maintain the behaviour observed below with absolutely appalling scheduling behaviour of Vbox is in alignment with HAL/RTAPI threads expected behaviour as far as currently specified. The task now is to firm up the spec such that the previous sentence can be falsified. - Michael > > EBo - > > On Dec 14 2012 2:42 AM, Michael Haberler wrote: >> Hi Jeff, >> >> I'm continuing from our chat yesterday here because it might be of >> wider interest: >> >> http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2012-12-13.html#22:57:03 >> >> to recap: >> >> - current 'sim' uses Gnu Pth threads >> - the rt-preempt merge candiate code uses Pthreads >> - to reduce code duplication, we folded rt-preempt code into the old >> 'sim' code and dropped Pth >> - runtests is fine on real machines, including threads.0 >> - runtests of threads.0 fails on a Virtualbox machine, which has >> exceptionally bad scheduling behaviour due to the hunderlying >> hypervisor scheme and second OS 'underneath'. >> >> Looking at the threads.0 test, it seems to imply there is a relative >> ordering of task execution, namely: >> - two threads, a fast one, and a slow one with 10 times the period of >> the fast one >> - the assumption seems to be the fast one executes 10 times before >> the slow one, resulting in a certain output pattern in the 'result' >> file, namely '1...10','1..10' which says the fast thread ran 10 >> times, >> then the slow one got scheduled. >> >> The only plausible explanation we arrived at so far seems the >> semantics of the threading libraries: >> - Gnu pth uses N:1 threading >> >> (http://en.wikipedia.org/wiki/Thread_%28computing%29#N:1_.28User-level_threading.29) >> - Pthreads uses M:N threading >> >> If that is the case, then threads.0 really verifies the >> implementation of Gnu Pthreads, but not some expected behaviour of >> HAL >> threads. At least I couldnt find a spec or comment which says 'even >> in >> sim mode, relative scheduling counts must remain fixed', which seems >> to happen by accident with Pth but not with pthreads in my Vbox >> setup. >> >> The reason why this test succeeds in usermode RT schemes, and on real >> machines seems to be that scheduling in these cases is precise enough >> to fit within the expected behavior time windows, whereas pthreads >> scheduling on Vbox is so massively off the scale that it violates the >> expected behavior. >> >> -- >> >> The question now is what to do with the result. >> >> First, does it indicate a fatal error situation? I dont think so, >> because in 'sim' mode all bets are off wrt relative scheduling >> anyway. >> >> Second, what does that test actually say? >> >> if all it does is to say 'well Gnu Pth just behaves _so_' then I'm >> unsure what we are testing against here. Of course intuitively one >> would _assume_ a thread 10x as fast gets to run 10x as often, but >> that >> it is not how it is implemented. If we were to ascertain a fixed >> relative scheduling rate, then the HAL/RTAPI threading code must >> assure that, for instance by explicitly scheduling a slow thread >> after >> N invocations of the fast thread where N is the period ratio. >> However, >> AFAICT that is not the case, and I am not at all sure this is >> actually >> the case with RT scheduling by the OS - just because it's precise >> enough on average that doesnt mean the behaviour isnt actually >> stochastic. >> >> I guess the proper answer to all this is to firm up the HAL/RTAPI >> threading specification by explicitly stating what relative periods >> of >> HAL threads mean for expected invocation counts. I can only infer >> this >> from the code, but I would think the answer is: >> >> If several threads are used, the relative timing suggests, *but does >> not ascertain* a certain ratio of thread invocations. >> >> If we can agree on that, that means threads.0 realistically is not >> acceptance test - but we can make it a standalone measurement for >> relative scheduling count probabilities, or drop it altogether. >> >> - Michael >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial >> Remotely access PCs and mobile devices and provide instant support >> Improve your efficiency, and focus on delivering more value-add >> services >> Discover what IT Professionals Know. Rescue delivers >> http://p.sf.net/sfu/logmein_12329d2d >> _______________________________________________ >> Emc-developers mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/emc-developers > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
