Timing precision of grttimeofday and xtime

Source: Internet
Author: User

 

========================================================== ====
Author: yuanlulu

Http://blog.csdn.net/yuanlulu

No copyright, but please keep this statement for reprinting
========================================================== ====

The customer reported that the time US obtained by gettimeofday is always zero.
You can modify the test code as follows:
./Lpc3250test 1 0 50000
Divsor is 1 sec is 0 USEC is 50000 ***
Current Time: sec = 1289836976 USEC = 390000 ***
Current Time: sec = 1289836976 USEC = 390000 ***
Current Time: sec = 1289836976 USEC = 390000 ***
Current Time: sec = 1289836976 USEC = 450000 CNT = 1 ***
Current Time: sec = 1289836976 USEC = 450000 CNT = 1 ***
Current Time: sec = 1289836976 USEC = 500000 CNT = 2 ***
Current Time: sec = 1289836976 USEC = 500000 CNT = 2 ***
Current Time: sec = 1289836976 USEC = 550000 CNT = 3 ***
Current Time: sec = 1289836976 USEC = 550000 CNT = 3 ***
Current Time: sec = 1289836976 USEC = 600000 CNT = 4 ***
Current Time: sec = 1289836976 USEC = 600000 CNT = 4 ***
Current Time: sec = 1289836976 USEC = 650000 CNT = 5 ***
Current Time: sec = 1289836976 USEC = 650000 CNT = 5 ***
Current Time: sec = 1289836976 USEC = 700000 CNT = 6 ***
Current Time: sec = 1289836976 USEC = 700000 CNT = 6 ***
Current Time: sec = 1289836976 USEC = 750000 CNT = 7 ***
Current Time: sec = 1289836976 USEC = 750000 CNT = 7 ***
Current Time: sec = 1289836976 USEC = 800000 CNT = 8 ***
Current Time: sec = 1289836976 USEC = 800000 CNT = 8 ***
Current Time: sec = 1289836976 USEC = 850000 CNT = 9 ***
We can find that the last four digits of us in gettimeofday are zero and can only be accurate to 10 ms.
Call relationship: gettimeofday-> sys_gettimeofday-> do_gettimeofday.
Do_gettimeofday code in the kernel code's kernel/time/timekeeping. c
The function is defined in row 114. do_gettimeofday calls getnstimeofday in the same file.
Void getnstimeofday (struct timespec * TS)
{
Unsigned long seq;
S64 nsecs;

Do {
SEQ = read_seqbegin (& xtime_lock );

* Ts = xtime;
Nsecs = _ get_nsec_offset ();

} While (read_seqretry (& xtime_lock, SEQ ));

Timespec_add_ns (TS, nsecs );
}
It can be seen that getnstimeofday uses xtime directly.
How accurate is the problem to convert to xtime.
Print the xtime read by current_kernel_time (void) in the driver module as follows:
Isoinit, SEC: 1289833417, NS: 950000000
Isoinit, SEC: 1289833417, NS: 950000000
Isoinit, SEC: 1289833417, NS: 960000000
Isoinit, SEC: 1289833417, NS: 960000000
Isoinit, SEC: 1289833417, NS: 960000000
Isoinit, SEC: 1289833417, NS: 970000000
Isoinit, SEC: 1289833417, NS: 970000000

Isoinit, SEC: 1289833425, NS: 780000000
Isoinit, SEC: 1289833425, NS: 780000000
Isoinit, SEC: 1289833425, NS: 790000000
Isoinit, SEC: 1289833425, NS: 790000000
Isoinit, SEC: 1289833425, NS: 790000000
Isoinit, SEC: 1289833425, NS: 800000000
Isoinit, SEC: 1289833425, NS: 800000000
The results of Multiple tests are all zero in the last seven digits. Therefore, the xtime precision cannot exceed 10 ms.
Now we can see that the precision of gettimeofday and xtime is the same as 10 ms. The accuracy is the same as that of the system clock (HZ = 100 ).
Xtime is a global variable.
The xtime update function in kernel/time/timekeeping. C is update_wall_time (void)
/**
* Update_wall_time-uses the current clocksource to increment the wall time
*
* Called from the timer interrupt, must hold a write on xtime_lock.
*/
Void update_wall_time (void)
{
...........
/* Store full nanoseconds into xtime */
Xtime. TV _nsec = (s64) clock-> xtime_nsec> clock-> shift;
Clock-> xtime_nsec-= (s64) xtime. TV _nsec <clock-> shift;
...........
}
Because this function is called by the system at a scheduled time, the accuracy of xtime is the same as that of the system clock.

 

Conclusion: The accuracy of getrimeofday and xtime is related to the system cycle. My system Hz = 100, so it can only be accurate to 10 ms. (Kernel 2.6.27.8)

========================================================== ====
Author: yuanlulu

Http://blog.csdn.net/yuanlulu

No copyright, but please keep this statement for reprinting
========================================================== ====

The customer reported that the time US obtained by gettimeofday is always zero.
You can modify the test code as follows:
./Lpc3250test 1 0 50000
Divsor is 1 sec is 0 USEC is 50000 ***
Current Time: sec = 1289836976 USEC = 390000 ***
Current Time: sec = 1289836976 USEC = 390000 ***
Current Time: sec = 1289836976 USEC = 390000 ***
Current Time: sec = 1289836976 USEC = 450000 CNT = 1 ***
Current Time: sec = 1289836976 USEC = 450000 CNT = 1 ***
Current Time: sec = 1289836976 USEC = 500000 CNT = 2 ***
Current Time: sec = 1289836976 USEC = 500000 CNT = 2 ***
Current Time: sec = 1289836976 USEC = 550000 CNT = 3 ***
Current Time: sec = 1289836976 USEC = 550000 CNT = 3 ***
Current Time: sec = 1289836976 USEC = 600000 CNT = 4 ***
Current Time: sec = 1289836976 USEC = 600000 CNT = 4 ***
Current Time: sec = 1289836976 USEC = 650000 CNT = 5 ***
Current Time: sec = 1289836976 USEC = 650000 CNT = 5 ***
Current Time: sec = 1289836976 USEC = 700000 CNT = 6 ***
Current Time: sec = 1289836976 USEC = 700000 CNT = 6 ***
Current Time: sec = 1289836976 USEC = 750000 CNT = 7 ***
Current Time: sec = 1289836976 USEC = 750000 CNT = 7 ***
Current Time: sec = 1289836976 USEC = 800000 CNT = 8 ***
Current Time: sec = 1289836976 USEC = 800000 CNT = 8 ***
Current Time: sec = 1289836976 USEC = 850000 CNT = 9 ***
We can find that the last four digits of us in gettimeofday are zero and can only be accurate to 10 ms.
Call relationship: gettimeofday-> sys_gettimeofday-> do_gettimeofday.
Do_gettimeofday code in the kernel code's kernel/time/timekeeping. c
The function is defined in row 114. do_gettimeofday calls getnstimeofday in the same file.
Void getnstimeofday (struct timespec * TS)
{
Unsigned long seq;
S64 nsecs;

Do {
SEQ = read_seqbegin (& xtime_lock );

* Ts = xtime;
Nsecs = _ get_nsec_offset ();

} While (read_seqretry (& xtime_lock, SEQ ));

Timespec_add_ns (TS, nsecs );
}
It can be seen that getnstimeofday uses xtime directly.
How accurate is the problem to convert to xtime.
Print the xtime read by current_kernel_time (void) in the driver module as follows:
Isoinit, SEC: 1289833417, NS: 950000000
Isoinit, SEC: 1289833417, NS: 950000000
Isoinit, SEC: 1289833417, NS: 960000000
Isoinit, SEC: 1289833417, NS: 960000000
Isoinit, SEC: 1289833417, NS: 960000000
Isoinit, SEC: 1289833417, NS: 970000000
Isoinit, SEC: 1289833417, NS: 970000000

Isoinit, SEC: 1289833425, NS: 780000000
Isoinit, SEC: 1289833425, NS: 780000000
Isoinit, SEC: 1289833425, NS: 790000000
Isoinit, SEC: 1289833425, NS: 790000000
Isoinit, SEC: 1289833425, NS: 790000000
Isoinit, SEC: 1289833425, NS: 800000000
Isoinit, SEC: 1289833425, NS: 800000000
The results of Multiple tests are all zero in the last seven digits. Therefore, the xtime precision cannot exceed 10 ms.
Now we can see that the precision of gettimeofday and xtime is the same as 10 ms. The accuracy is the same as that of the system clock (HZ = 100 ).
Xtime is a global variable.
The xtime update function in kernel/time/timekeeping. C is update_wall_time (void)
/**
* Update_wall_time-uses the current clocksource to increment the wall time
*
* Called from the timer interrupt, must hold a write on xtime_lock.
*/
Void update_wall_time (void)
{
...........
/* Store full nanoseconds into xtime */
Xtime. TV _nsec = (s64) clock-> xtime_nsec> clock-> shift;
Clock-> xtime_nsec-= (s64) xtime. TV _nsec <clock-> shift;
...........
}
Because this function is called by the system at a scheduled time, the accuracy of xtime is the same as that of the system clock.

 

Conclusion: The accuracy of getrimeofday and xtime is related to the system cycle. My system Hz = 100, so it can only be accurate to 10 ms. (Kernel 2.6.27.8)

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.