1kHz timer behavior on Cyclone V
janetsc at fb.com
Wed Dec 7 21:38:03 UTC 2016
Hi - thanks for the responses!
It is a very simple application that is only processing a 1 kHz timer for the purposes of this test. There is no other CPU load on the system. The only thing I do right now when the timer fires is calculate the time difference since the last timer fired. Once a second, I output the average, min and max for that second.
I do have a delay it the main task, since it is just sitting there idle. Would that account for such an increase in the time between the timer firing?
I will try the POSIX API next.
From: Joel Sherrill <joel at rtems.org>
Sent: Wednesday, December 7, 2016 1:15:23 PM
To: Janet Schneider
Cc: users at rtems.org
Subject: Re: 1kHz timer behavior on Cyclone V
On Wed, Dec 7, 2016 at 11:44 AM, Janet Schneider <janetsc at fb.com<mailto:janetsc at fb.com>> wrote:
I am running a 1kHz timer test on the Altera Cyclone V dev board. I am trying to measure the average time period between the timer firing, and any variance on that latency.
I'm seeing an average of 1003 microseconds between the timer firing. About once a second, I see the maximum time between the timer firing go up to 2500-3000 microseconds.
There are two sets of timers. One is per clock tick and one is per second.
My guesses are:
Do you have a sleep/delay statement in your thread?
There may be some work updating the time that occurs once per second. The implementation of this area has changed so I don't remember offhand if this is still the case.
I'm using rtems_clock_get_uptime_nanoseconds() to measure the time that the timer fires. I have CONFIGURE_MICROSECONDS_PER_TICK set to 500.
What happens when the HW interrupt timer fires?
Has anyone else seen this (or something similar)? Any ideas what might be happening here?
users mailing list
users at rtems.org<mailto:users at rtems.org>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users