Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

delay_timer by Linux kernel

Status
Not open for further replies.

tapas_mishra

Newbie level 2
Joined
Apr 2, 2010
Messages
2
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
1,295
Hi I am new to this forum ,want to know that how does the processor timer gets recognized by Linux kernel.
There is a variable known as jiffy which stores the number of timer ticks a computer has been run and up since its boot.
Here is a link to the article that I am asking.

http://kerneltrap.org/node/6857

I am trying to generate a delay of the order of 10^-9 although the code exists on what I am asking but want to do it myself.
Here is a link to the code I am referring to if some one wants to see.
**broken link removed**

What I want to know is which register does the kernel reads to get the value of variable jiffy ? Is it random or well defined location?
 

Originally the JIFFY was the time interval between system timer interrupts, however today it's referred to as the software clock and based on the kernel variable HZ. The value of HZ ranges from 1ms to 10ms, depending on the speed of the processor with 4ms being the default. JIFFIES is the running count of each JIFFY.

The kernel offers two delay functions mdelay() and udelay(), delays of 10^-3 and 10^-6 respectfully, far short of your desired nanosecond or 10^-9. Delays of that fine a granularity are not feasible or for that matter possible with any OS even a RTOS running on the processor. You would have to write a routine in assembler counting each and every clock cycle used by your code and then dedicating the entire processor to running only your code. Besides system buses typically run slower than 1GHz so what can you accomplish even if you achieved an accurate 1ns delay? The clock cycle on a 1GHz x86 is 1ns, even delays of single digit microseconds can be a challenge on many linux machines, due to the fact that linux is not a true RTOS.

The Software Clock, HZ, and Jiffies
The accuracy of various system calls that set timeouts, (e.g., select(2), sigtimedwait(2)) and measure CPU time (e.g., getrusage(2)) is limited by the resolution of the software clock, a clock maintained by the kernel which measures time in jiffies. The size of a jiffy is determined by the value of the kernel constant HZ.

The value of HZ varies across kernel versions and hardware platforms. On i386 the situation is as follows: on kernels up to and including 2.4.x, HZ was 100, giving a jiffy value of 0.01 seconds; starting with 2.6.0, HZ was raised to 1000, giving a jiffy of 0.001 seconds. Since kernel 2.6.13, the HZ value is a kernel configuration parameter and can be 100, 250 (the default) or 1000, yielding a jiffies value of, respectively, 0.01, 0.004, or 0.001 seconds. Since kernel 2.6.20, a further frequency is available: 300, a number that divides evenly for the common video frame rates (PAL, 25 HZ; NTSC, 30 HZ).

The times(2) system call is a special case. It reports times with a granularity defined by the kernel constant USER_HZ. Userspace applications can determine the value of this constant using sysconf(_SC_CLK_TCK).

High-Resolution Timers
Before Linux 2.6.21, the accuracy of timer and sleep system calls (see below) was also limited by the size of the jiffy.

Since Linux 2.6.21, Linux supports high-resolution timers (HRTs), optionally configurable via CONFIG_HIGH_RES_TIMERS. On a system that supports HRTs, the accuracy of sleep and timer system calls is no longer constrained by the jiffy, but instead can be as accurate as the hardware allows (microsecond accuracy is typical of modern hardware). You can determine whether high-resolution timers are supported by checking the resolution returned by a call to clock_getres(2) or looking at the "resolution" entries in /proc/timer_list.

HRTs are not supported on all hardware architectures. (Support is provided on x86, arm, and powerpc, among others.)

This is why there is no ndelay() kernel function available. You'll just have to wait for the Intel Optical Processors due out next year. Remember 3x10^8 m/s, it not just a good idea, it's the law.
 
bigdogguru said:
You would have to write a routine in assembler counting each and every clock cycle used by your code and then dedicating the entire processor to running only your code.
Hi thanks for the nice explanation.If you can point me out to the some code as you mentioned above I would like to read or what should I search for.
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top