Issue with gettimeofday() in RTEMS 4.10;

Gedare Bloom gedare at gwmail.gwu.edu
Fri Jan 28 16:49:50 UTC 2011


Try to reduce the test case to a simple RTEMS application that
produces the invalid behavior (and indicates the problem) and open a
PR on the bugzilla with the test case.  If you can test other
BSPs/CPUs (e.g. qemu, sis-gdb) that would be helpful.

-Gedare

On Fri, Jan 28, 2011 at 9:42 AM, João Rasta <freakforever at gmail.com> wrote:
> The issue seems similar yes, but i'm in doubt about if the leon can use
> multiple ISRs per clock tick. How can i confirm if this is a bug?
>
>
> Best,
> JM
>
>
>
> On Fri, Jan 28, 2011 at 2:33 PM, Gedare Bloom <gedare at gwmail.gwu.edu> wrote:
>>
>> I wonder if this is this related to PR 1495?:
>> https://www.rtems.org/bugzilla/show_bug.cgi?id=1495
>>
>> The symptom is similar, but I don't think the LEON3 has the same
>> structure of clock driver.
>>
>> -Gedare
>>
>> On Fri, Jan 28, 2011 at 9:11 AM, João Rasta <freakforever at gmail.com>
>> wrote:
>> > Hi,
>> >
>> > I'm using gettimeofday() to profile a function. For this i do:
>> >
>> >         struct timeval tim;
>> >         // *Get actual clock
>> >         gettimeofday(&tim, NULL);
>> >         double t1=tim.tv_sec+(tim.tv_usec/1000000.0);
>> >
>> >
>> >         // *GNC Calculations starting point
>> >         Execute_gnc();
>> >         // *Calculations termination point
>> >
>> >
>> >         // *Calculate elapsed time with GNC calculations.
>> >         gettimeofday(&tim, NULL);
>> >         double t2=tim.tv_sec+(tim.tv_usec/1000000.0);
>> >
>> >         procDelay = (t2 - t1 + 0.0275);
>> >         if (t1 > t2)
>> >             printf(" WARNING %f > %f\n",t1,t2);
>> >         else
>> >             printf("%f\n",procDelay);
>> >
>> > But sometimes t1 is larger than t2, which should not be possible since
>> > t2 is
>> > allways measured after t1. For instance, the above code produces the
>> > following when this issue happens:
>> >
>> > WARNING 567996584.559981 > 567996584.550001
>> >
>> > The above code runs in loop and this happens roughly once in an hour
>> > (just
>> > an estimate). Is there any known overflow issue with the usec counter
>> > that i
>> > should be aware? RTEMS is running with a LEON-3.
>> >
>> >
>> > Best,
>> > JM
>> >
>> > _______________________________________________
>> > rtems-users mailing list
>> > rtems-users at rtems.org
>> > http://www.rtems.org/mailman/listinfo/rtems-users
>> >
>> >
>
>




More information about the users mailing list