On Sun, Jul 18, 2010 at 12:25 AM, Caspar Zhang <[email protected]> wrote:
>
> ----- "Caspar Zhang" <[email protected]> wrote:
>
>> Hi all,
>>
>> In my recent tests, not all desired time is equal to exact
>> execution time,
>> sometimes it is +/-1s, and in a few times it becomes +/-2s. In most
>> cases,
>> +/-2s is still a valid value between exact execute time and desired
>> time.
>>
>> Signed-off-by: Caspar Zhang <[email protected]>
>>
>> --- a/testcases/kernel/syscalls/pselect/pselect01.c 2010-04-01
>> 14:23:10.000000000 +0800
>> +++ b/testcases/kernel/syscalls/pselect/pselect01.c 2010-07-15
>> 16:03:40.969426078 +0800
>> @@ -109,7 +109,8 @@
>> NULL);
>> end = time(&t);
>>
>> - if (((end - start) == total_sec) || ((end - start) ==
>> total_sec + 1))
>> + /* Is it still valid in range -2~2s? */
>> + if ((end - start - total_sec <= 2) && (end - start -
>> total_sec >= -2))
>
> Sorry for mistake, since end, start are unsigned int, use
> end-start-total_sec >= -2 will cause error, add (int)before
> (end-start) instead. New patch attached.
The fact that the test is using time(3) to calculate the elapsed
period instead of clock_gettime is dubious at best, because the
precision of time is in seconds. Maybe it should be converted to
clock_gettime calls for improved precision?
Thanks,
-Garrett
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list
