Timer resolution et al

[Joel Sherrill]

Brian is correct.  a 10 microsecond clock tick is going to end up with you
spending nearly all the CPU time serving tick interrupts.  Having a 2nd 
source
for benchmark purposes is the ideal solution.

The current pc386 timer is setup to use the TSC register for p5 and above.
On 486 and below it uses the same timer hardware as the clock tick driver.
If you can change it so on 486 and below it uses different hardware, it is
a welcome patch.

--joel

Stevens Brian wrote:

>Let me start by saying that I am not an expert on RTEMS and have stated to
>use it recently having looked at it 1st about 5 years ago.
>
>The potential accuracy of the timer chip (8254)that runs at 8MHz, so should
>be able to support micro second accuracy.
>
>However, if you change the micro seconds per tick, the interrupt handler
>will be active more often and use more resources. Also you may need to
>change the ticks per timeslice to make sure that your timeslice stays the
>same, if you do not the system may spend too much of its time doing contexts
>switches.
>
>For my use I would prefer that the timers are separate. 
>
>I hope that this helps and if any one else has more information then they
>will offer it up.
>
>
>
>-----Original Message-----
>From: sashti srinivasan [mailto:svasn_rtems at yahoo.com]
>Sent: 10 March 2004 05:34
>To: Stevens Brian; 'rtems-users at rtems.com'
>Subject: Re: Timer resolution et al
>
>
>Hi,
>
>    Thanks for one important information, that rtc
>chip interrupts the processor ~122 microseconds.  I am
>able to get 10 microsecond accuracy without going to
>hardware.  Please correct me if I am wrong.  I
>configured the CONFIGURE_MICROSECONDS_PER_TICK to 10
>microseconds and hoping that it is giving with 10
>microseconds accuracy on pc386.  Am I wrong?  Please
>tell me.
>
>     I am also working on PC386 BSP.  One thing coming
>to my mind, we have a bios whose services can be made
>effective use of.  Is there any service in bios that
>gives 1 microsecond accuracy?
>
>      Various timing tests that are distributed with
>rtems did not run on PC386.  Mr.Joel also wanted to
>know whether anyone got them working on PC386.  Have
>you got them working?  I am not sure, but I think the
>problem is only with timer
>driver(c/src/lib/libbsp/i386/pc836/timer/timer.c). 
>The timing tests make use of timer functions
>Timer_initialize() and Read_timer().  Probably these
>functions cause the problem.
>
>      Hardware:  Probably the best place to know about
>hardware is rtems source code.  In the above mentioned
>file, the function rtdsc() is probably giving time
>from hardware.  It is a short function counting to
>less than 5 lines.  I could not understand the most
>important line in this.  That is:
>    asm volatile(".byte 0x0F, 0x31" : "=A" (result));
>  I referred to the gnu documentation for gcc.  Only
>things I found out was, "=" specifies result is a
>output,"A" specifies some attributes of result.  But
>as per the documentation, the string preceding :
>should contain a instruction mnemonic.  I do not
>understand the presence of assembler directive .byte
>as the part of the string.  Sorry for troubling the
>members of the list with doubt unrelated to rtems. 
>Thanks if anyone can explain this to me.
>
>With Regards
>Srinivasan
>--- Stevens Brian <BPSTEVENS at qinetiq.com> wrote:
>  
>
>>I have been following the thread on timer resolution
>>etc as I have a need
>>for the following:
>>
>>	A timer with an accuracy of sub milliseconds
>>	A timer that is not dependant on the underlying
>>clock tick.
>>
>>I am working with the pc386 port and have formulated
>>some ideas:
>>	Use one of the other counters on the timer chip.
>>		This seems a straight forward way to do the job
>>without
>>altering the existing code, and since most timer
>>chips have more than 1
>>counter it could probably be extended to other
>>ports. However, it seems that
>>the other timer outputs are not normally conected to
>>the interrupt
>>controller. 
>>
>>	Use the real time clock
>>		In the PC the real time clock chip can provide a
>>periodic
>>interrupt with a resolution of ~122 micro seconds
>>and this line is connected
>>to the interrupt controller.
>>
>>I would prefer to go with the 1st method as I think
>>that this would have
>>more generall application. If any one can help me
>>with the hardware parts
>>then I am willing to have a go at the code for the
>>pc386. (this is a home
>>job not a work job so it may take some time)
>>
>>Thank You
>>
>>Brian Stevens
>>
>>QinetiQ
>>Cody Technology Park,
>>Ively Road,
>>Farnborough,
>>Hampshire
>>GU14 0LX . 
>>UK
>>
>>Telephone (01252) 393959
>>Fax          (01252) 395120
>>    
>>