Date: Mon, 18 Jun 2007 04:34:36 -0600 From: Chad Perrin <perrin@apotheon.com> To: questions@freebsd.org Subject: Re: FreeBSD and Robotics Message-ID: <20070618103436.GC37851@demeter.hydra> In-Reply-To: <04E232FDCD9FBE43857F7066CAD3C0F137B3FD@svmailmel.bytecraft.internal> References: <04E232FDCD9FBE43857F7066CAD3C0F137B3FD@svmailmel.bytecraft.internal>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 18, 2007 at 01:32:21PM +1000, Murray Taylor wrote: > I can only think of one other point for this... > Interrupt latency. Depending on what you are attempting to do, > the variable nature of interrupt responses could be an issue. > I.e. if the system becomes io bound during a data capture cycle, > and something occurs that requires a response within a very narrow > window, it is possible to miss the window due to other interrupt > processes running. > > For this reason, robotics systems often run on highly optimised > single process systems where there is a 'guaranteed' poll cycle > and / or a very minimal defined interrupt system with minimal > overheads. I suspect that increasing concurrency capability in the near future will change that a fair bit. It'll probably start with highly concurrent embedded and realtime OS development (he said, wildly guessing) and seep out into other areas of computing from there. -- CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ] awj @reddit: "The terms never and always are never always true."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070618103436.GC37851>