On 24/05/2010, at 8:47 AM, Glen Turner wrote: > On Mon, 2010-05-24 at 09:02 +1000, Peter Chubb wrote: > >> Actually it doesn't give the whole answer. > > Wow, thanks heaps Peter. Thank you all. Particularly Peter.
That is truly an amazing depth of information to digest. > > tenzero: so there are 1000 (CONFIG_HZ) samples per second. For each > sample your program is one of: not scheduled, running in user, running > in system, or has yielded the processor due to a blocking event such as > I/O or an explicit sleep(). > > It is possible that all processes yield and you get scheduled twice in > one sample -- I'd note that, and then ignore the possibility. Run an > infinite loop in another process if it worries you. That bastard will > never yield, and so your process will never be scheduled twice in a > tick. If you have multiple CPUs, bind one infinite loop to each CPU. In > reality, unless your results are odd, this is a lot of work to exclude > an unlikely case. > > With luck, your program is such that you can use strace to count the > blocking events on a single run of your program. Then pretend that the > scheduler tick misses every one of these. So if you program has 10 > blocking events and runs for 1.00 second then there result has a bound > of [1.00, 1.01]. Including the reporting error from the API [0.99, > 1.02]. > > You will save yourself a world of statistics if your "better" program's > range falls completely under the "worse" program's range. In this case it is. The hardware device dramatically outperforms the software and the error in the hardware device is half a clock cycle or 20ns while the error in the software is in the ms scale. Mostly for completeness, I simply wanted to discuss the error in the software measurement. > > In your Appendix you acknowledge Peter's contribution with a footnote > (eg, "Thanks to Dr Peter Chubb of UNSW for explaining the sampling > nature of the Linux task accounting"). In general, you don't cite these > sort of e-mail discussions since they are "all care and no > responsibility" discussions rather than a considered opinion ready for > peer review. Of course, where the posting becomes a part of the record > (such Linus's announcement of Linux) then you reference. > > You will see from this discussion the common research hassle that > determining the error of an experiment is usually more work than > determining the result. Indeed, that's exactly how I'm finding this. > > Best of luck with your studies, > Glen Thanks. All things going to plan, I should graduate in about a month. This is for my final year project in Electronic Engineering. Again, thanks for everyones help. Cheers. D. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
