All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Simon Martin <smartin@milliways.cl>
Cc: Lars Kurth <lars.kurth@citrix.com>,
	Roland Heusser <heusserr@mail.gvsu.edu>,
	Artem Mygaiev <artem.mygaiev@globallogic.com>,
	Lovene Bhatia <lbhatia@samsung.com>, Sisu Xi <xisisu@gmail.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Joshua Whitehead <whitehej@mail.gvsu.edu>,
	xen-devel <xen-devel@lists.xen.org>,
	Drek Darkover <wackerei@gmail.com>,
	Stefano Panella <stefano.panella@citrix.com>,
	Nate Studer <nate.studer@dornerworks.com>,
	mdavis@planetaryresources.com
Subject: Re: Xen for real-time/embedded/automotive
Date: Thu, 28 Nov 2013 13:03:33 +0100	[thread overview]
Message-ID: <1385640213.20797.116.camel@Abyss> (raw)
In-Reply-To: <em40e5807b-ac20-4c2a-ad66-d1056397e07b@smartin-alien>


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

On gio, 2013-11-28 at 11:39 +0000, Simon Martin wrote:
>  
> > BTW, I do realise only know that I probably never asked that... What
> > is 
> > (if you feel like saying it here) your specific usecase / final goal
> > of 
> > this work? 
> >  
> I am porting an motion control system to Xen. The OS and hardware is
> developed in house. I originally wrote the OS about 20 years ago on a
> TI DSP processor with 32 k words of RAM and it has been evolving since
> then, migrating to different processors (MIPS/ARM) and an ever
> increasing amount of memory (we moved from SRAM to DRAM when we went
> on to the MIPS platform, and the smallest DRAM chips you could get at
> the time were 1 MB).
>
That's very cool! You know, at some point, probably when you/we would
have a bit more of this in place, I'll probably ask if you want to write
a post on our blog (http://blog.xen.org/) about it! :-D
 
> Looking at the Real-Time Xen project, it is built around millisecond
> resolution. That was fine for motion control about 20 years ago, but
> nowadays everyone is working sub-millisecond. 
>
Yeah, well, let's investigate what the limit is and try to push harder
on it then. From my previous experience with real-time on Linux, it's
possiblee to go sub-milliseconds, although not without some tricks.
Personally, I think it's both possible and worthwhile to try to figure
out what are the tricks required for us to get as near as possible to
that!

> Our existing systems can close the control loop every 125 µs doing
> full interpolation on 8 axes with 64 bit resolution on an ARM11
> platform. Worst than that, jitter on the control loop gives you at
> best jerky movement and at worst shuts down the drives so that must be
> controlled.
>  
HeHe... It's about Linux, but I just can't resist:

<<Controlling a laser with Linux is crazy, but everyone in this room is
crazy in his own way. So if you want to use Linux to control an
industrial welding laser, I have no problem with your using
PREEMPT_RT.>> Torvalds, Linus (2007)

Of course, substitute 'Linux' with 'Xen', and PREEMPT_RT with either
RT-Xen, or whatever we could come up with in the long run! :-P :-P

Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

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

  reply	other threads:[~2013-11-28 12:03 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-18 19:14 Xen for real-time/embedded/automotive Dario Faggioli
2013-11-19  1:27 ` Simon Martin
2013-11-20 14:04   ` Lars Kurth
2013-11-20 14:23     ` Simon Martin
2013-11-20 15:14       ` Lars Kurth
2013-11-20 17:36       ` Anil Madhavapeddy
2013-11-20 17:59         ` Simon Martin
2013-11-20 18:05           ` Anil Madhavapeddy
2013-11-20 18:35             ` Simon Martin
2013-11-28  9:53   ` Dario Faggioli
2013-11-28 11:39     ` Simon Martin
2013-11-28 12:03       ` Dario Faggioli [this message]
2013-11-28 12:39         ` Simon Martin
2013-11-30 11:37           ` Dario Faggioli
2013-11-20  4:50 ` Sisu Xi
2013-11-20 15:25   ` Lars Kurth
2013-11-21  7:04     ` Dario Faggioli
2013-11-21  7:52     ` Dario Faggioli
2013-12-12  8:05     ` Jeremiah Foster
2013-12-12  8:12       ` Dario Faggioli
2013-12-12  9:35         ` Lars Kurth
2013-12-12  9:39           ` Jeremiah Foster
2013-12-12  9:46             ` Dario Faggioli
2013-11-22  7:14 ` Dario Faggioli
2013-11-28  9:35 ` Dario Faggioli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1385640213.20797.116.camel@Abyss \
    --to=dario.faggioli@citrix.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=artem.mygaiev@globallogic.com \
    --cc=heusserr@mail.gvsu.edu \
    --cc=lars.kurth@citrix.com \
    --cc=lbhatia@samsung.com \
    --cc=mdavis@planetaryresources.com \
    --cc=nate.studer@dornerworks.com \
    --cc=smartin@milliways.cl \
    --cc=stefano.panella@citrix.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=wackerei@gmail.com \
    --cc=whitehej@mail.gvsu.edu \
    --cc=xen-devel@lists.xen.org \
    --cc=xisisu@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.