Re: VCPUOP_set_periodic_timer

[Keir Fraser <keir.xen@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 4014 bytes --]

If you have dedicated a core to the vcpu, so you can discount scheduling
crosstalk, you shouldn¹t miss deadlines by more than a microsecond or two.
Just enough time to wake up the CPU, handle the timer interrupt, and wake up
the vcpu through the scheduler. There are infrequent operations that can
take out all CPUs for a period: taking a CPU offline for example. You could
avoid doing such things in your setup perhaps. :) Ultimately you will need
to measure and confirm deadline-to-notification latency distribution if it
is critical to you.

 -- Keir

On 15/11/2013 11:45, "Simon Martin" <smartin@milliways.cl> wrote:

> Thanks Keir,
>  
> That sounds quite reasonable. What granularity can I achieve with this? Any
> idea on the jitter?
>  
> Regards.
>  
>  
> ------ Original Message ------
> From: "Keir Fraser" <keir.xen@gmail.com>
> To: "Simon Martin" <smartin@milliways.cl>; "Andrew Cooper"
> <andrew.cooper3@citrix.com>
> Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
> Sent: 15/11/2013 08:36:45
> Subject: Re: [Xen-devel] VCPUOP_set_periodic_timer
>  
>> The periodic_timer is really a coarse-grained timer for driving a legacy
>> ticker. It is considered low accuracy and low priority ­ for example, it is
>> stopped entirely while a vcpu is descheduled!
>> 
>> You should use VCPUOP_set_singleshot_timer, and call it again at the end of
>> your timer handler to get the desired periodic behaviour. If you have
>> multiple timers in your OS you would manage them in your OS and pick the
>> nearest deadline to program down to Xen.
>> 
>>  -- Keir
>> 
>> On 15/11/2013 11:24, "Simon Martin" <smartin@milliways.cl> wrote:
>> 
>>> Hi Andrew,
>>>  
>>> The operating system I am trying to port to Xen is an industrial servo
>>> controller. We are currently running at 125 microsecond servo update rate on
>>> our bespoke hardware (at the moment MIPS64 and ARM) (hence the 125
>>> microsecond ideal interrupt period). We will be driving EtherCAT servo
>>> drives that need to be updated at 500 microseconds (hence at least 500
>>> microsecond interrupt period). If we can achieve this on a single core ARM11
>>> clocked at 532 MHz, it must be achievable on PC hardware. As I said before
>>> the idea is to dedicate a CPU core to this with all other functions running
>>> on the other cores.
>>>  
>>> Luckily we can accept a reasonable amount of jitter on the EtherCAT network
>>> as we can hand over clock synchronisation to a slave. This gives us a little
>>> leeway.
>>>  
>>> Regards.
>>>  
>>>  
>>> ------ Original Message ------
>>> From: "Andrew Cooper" <andrew.cooper3@citrix.com>
>>> To: "Simon Martin" <smartin@milliways.cl>; "xen-devel@lists.xen.org"
>>> <xen-devel@lists.xen.org>
>>> Sent: 14/11/2013 18:39:21
>>> Subject: Re: [Xen-devel] VCPUOP_set_periodic_timer
>>>  
>>>> On 14/11/2013 21:18, Simon Martin wrote:
>>>>> Hi all,
>>>>>  
>>>>> I need a periodic timer running at ideally at 125 microseconds and at
>>>>> least 500 microseconds. I've just found the VCPUOP_set_periodic_timer,
>>>>> however there is a comment saying "periods less than one millisecond may
>>>>> not be supported".
>>>>>  
>>>>> I will be running on an x64 machine. Is this supported? If not, is there
>>>>> any alternate means of generating a fast interrupt?
>>>>>  
>>>>> Regards.
>>>> 
>>>> What is the usecase here?  125us is very short indeed.  Xen certainly cant
>>>> guarantee anything more accurate than 50us.  Unless the affected vcpu is
>>>> running uncontested on the hardware, there is very little chance that the
>>>> vcpu will indeed be woken up again in 125us.
>>>> 
>>>> It sounds as if you are looking for some pseudo realtime system, at which
>>>> point you might want to consider a different scheduler.
>>>> 
>>>> ~Andrew
>>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/xen-devel
> 


[-- Attachment #1.2: Type: text/html, Size: 6020 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel