Xen project Mailing List

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@xxxxxxxxxxxx> 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@xxxxxxxxxx>
To: "Simon Martin" <smartin@xxxxxxxxxxxx>; "xen-devel@xxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxx>
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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel