Dion, As a soon-to-graduate EE you might consider using a tool such as oscilloscope or frequency counter to help more objectively measure timing. A simple thing to do would be to have your code section run in a repeating loop. At the end of the loop toggle a physical output - say the DTR line on a serial port, or even the Num Lock LED on you keyboard. Connection up your 'scope or meter to that physical interface and measure the frequency. I'm pretty sure these modern time-domain measuring devices are going to have some nice crystal-locked output that should have better than 0.1% or better resolution. Just compare that to your output from time() and see how you go.
Regards, Martin [email protected] On Mon, May 24, 2010 at 1:45 PM, Dion Curchin <[email protected]> wrote: > > 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 > -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
