RES: RES: Different tick interval with the same application between RTEMS 4.10.0 and 4.10.2?

Mon May 21 19:36:21 UTC 2012

On 05/21/2012 01:33 PM, Fabrício de Novaes Kucinskis wrote:
>
> Yes Joel, GDB changed to 7.2. The extension of SIS internal cycle 
> counter was the main reason for our upgrade.
>
> The RTC counter is programmed with the same value for both BSP’s. I’m 
> starting to think that this is related to the GDB update.
>
> I’m just curious about why would you expect that the change of the 
> counter’s length would make SIS faster…?
>
Random hunches.

+ The native GCC used to compile the binary was newer and it
got better at the inner loop between the two points.

+ The change to the 64-bit cycle counter also simplified the
inner loop of the simulator in some way that either by itself
made it faster, or let the same gcc do a better job.

The gdb version is independent of the RTEMS version. You
can always compare the execution times of the same binaries
on them.

--joel

> *De:*Joel Sherrill [mailto:joel.sherrill at oarcorp.com]
> *Enviada em:* segunda-feira, 21 de maio de 2012 15:14
> *Para:* Fabrício de Novaes Kucinskis
> *Cc:* 'RTEMS Users'
> *Assunto:* Re: RES: Different tick interval with the same application 
> between RTEMS 4.10.0 and 4.10.2?
>
> On 05/21/2012 12:55 PM, Fabrício de Novaes Kucinskis wrote:
>
> Hi Joel, and thanks for your answer,
>
> The “one second” reference I used is real time (ERC32 BSP). When 
> simulating (SIS BSP), things run a little faster. But not as fast as 
> what we are seeing now.
>
> We checked (both a dump of the .exe and with a breakpoint at 
> Clock_isr), and the fast idle mode is not #included in the application 
> compiled for SIS.
>
> Could this be a side-effect of the nanoseconds change? I don’t think 
> so, as we’re not enabling the extension. But don’t know where else to 
> look for.
>
> I don't think so either. The timer should be programmed with the same 
> value
> on both sis and real hardware.
>
> That's the only thing to check.
>
> By any chance did the version of gdb change? Or did the binary change?
> I am thinking that an sis with 64-bit internal cycle counter might be 
> faster
> than the version with 32-bit internal cycle counter.
>
> We also compiled the same application with both versions of RTEMS and 
> run in an ERC32 board. Both run at the same 1-second interval. As this 
> is our main target, the issue with the simulator shouldn’t bother us 
> too much. But I think it’s always important to report to the list when 
> something doesn’t work as expected – maybe the observed behavior point 
> to something to be improved or fixed.
>
> Thanks again,
>
> Fabrício.
>
> *De:*Joel Sherrill [mailto:joel.sherrill at oarcorp.com]
> *Enviada em:* segunda-feira, 21 de maio de 2012 11:26
> *Para:* Fabrício de Novaes Kucinskis
> *Cc:* 'RTEMS Users'
> *Assunto:* Re: Different tick interval with the same application 
> between RTEMS 4.10.0 and 4.10.2?
>
> On 05/21/2012 08:49 AM, Fabrício de Novaes Kucinskis wrote:
>
> Hi all,
>
> We've just upgraded our development environment from RTEMS 4.10.0 to 
> RTEMS 4.10.2. As always, an interesting issue has raised! ;-)
>
> We use the ERC32 and SIS BSPs. After the upgrade, a simple test 
> application that prints a clock once per second started to print the 
> clock values almost two times faster on SIS. The application gets the 
> number of ticks per second and uses it in the rtems_task_wake_after 
> directive.
>
> When on any simulator, there is always the possibility that somehow 
> the fast idle mode
> in the clock driver got turned on.
>
>
> To determine if the issue was on SIS or RTEMS, we run in the 4.10.2 
> environment the previous version of the test, compiled with RTEMS 
> 4.10.0, and the task runs once per second. Also, the number of ticks 
> per second reported in both versions is the same.
>
>
> Is this once per second in simulated or real time?
>
> Set a break point at Clock_isr and see if it is doing the fast idle mode.
>
>
>
>
> Looking at the release notes, we've found a number of changes/fixes 
> related with ticks and time since 4.10.0. But it seems that none of 
> them is related to what I report here.
>
> I looked at the diff files and the only changes are fixing bugs
> related to nanoseconds since last tick when you ask on the
> edge of a tick interrupt occurring.
>
>
> Is this something to be expected when upgrading? Am I missing some 
> change in the configuration?
>
> Thanks in advance and best regards,
>
> Fabrício de Novaes Kucinskis.
>
>
>
>
>
> -- 
> Joel Sherrill, Ph.D.             Director of Research&   Development
> joel.sherrill at OARcorp.com  <mailto:joel.sherrill at OARcorp.com>         On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>      Support Available             (256) 722-9985
>   
>
>
>
>
> -- 
> Joel Sherrill, Ph.D.             Director of Research&   Development
> joel.sherrill at OARcorp.com  <mailto:joel.sherrill at OARcorp.com>         On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>      Support Available             (256) 722-9985
>   

-- 
Joel Sherrill, Ph.D.             Director of Research&   Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
     Support Available             (256) 722-9985

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20120521/5291b89f/attachment-0001.html>