Honored ContributorHello i have a device driver that comunicates with an onchip mem. I need to see how much time it takes to read and write from the onchip mem.
I've put several printk's with timestamp to debug how much time it takes but is it the right way to do it? I got a 10ms result, it could be more/less than that? Thanks
Honored ContributorThis is probably not very accurate, as the timestamps depend on the system timer which has a low resolution (could even be 10ms). Besides if you call printk() inside the critical part of your code it will slow it down considerably.
If you need something more accurate, have a look at the performance counter (chapter 34 of this guide (http://www.altera.com/literature/ug/ug_embedded_ip.pdf)). application note 391 (http://www.altera.com/literature/an/an391.pdf) can also be an interesting read for you.Honored ContributorAnother way to time is to make a peripheral you can write to that sets a pin you can probe with an oscilloscope.
Honored ContributorI made a timestamp hardware that starts when the Linux writes 1 to it and i get the value when i write 2.
The value between a read/write acessing a mutex is 2ms. Is that high?Honored Contributorhow much memory are you accessing between those two calls? Are you doing anything else?
Honored ContributorI am doing those calls on userspace (calling a device driver of course)
Therefore i supose there is a lot of scheduler trouble in the userspace and stuff like that.. I did the test 1000 times, my best result was 300uS, my worst was 218ms and the average was 30mSHonored ContributorYes with such a disparity it is difficult to make any conclusions... Could you do the timing in the driver itself? By directly accessing a timestamp component using IORD/IOWR macros?
Honored ContributorOn userspace you will see 1000 mSec or more sometimes, as the user program can be delayed very long by the Kernel preempting it at any point.
-MichaelHonored ContributorI've changed the way i done. Without printk's etc my acess time is 8uS
