kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
From: greg@kroah.com (Greg KH)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Driver with hard RT requiremnets
Date: Mon, 5 Dec 2016 15:54:56 +0100	[thread overview]
Message-ID: <20161205145456.GA31919@kroah.com> (raw)
In-Reply-To: <CAJ2oMhKQr=gnwPhbDJ6xJBtErjqk=_YsFdESJ+0znmp=WzNcDA@mail.gmail.com>

On Mon, Dec 05, 2016 at 04:49:28PM +0200, Ran Shalit wrote:
> 
> 
> On Mon, Dec 5, 2016 at 4:35 PM, Greg KH <greg@kroah.com> wrote:
> 
>     On Mon, Dec 05, 2016 at 04:24:05PM +0200, Ran Shalit wrote:
>     > Hello,
>     >
>     > We need to support serial driver with real time requirements (towards
>     specific
>     > device with RT demands):
>     > Every 5.3msec receive 100 bytes and 1.3msec afterwards send 100 bytes.
>     >
>     > 1. Does kernel support real-time of such hard requirements ?
> 
>     It depends on the hardware you are using, does your hardware provide
>     enough processing power and lack of harware interruptions (i.e. SMI) to
>     allow this to work properly?
>    
>     > 2. Is it matter if we do the exact bytes send/receive from kernel or
>     userspace,
>     > i.e. is kernel more real-time than userspace ?
> 
>     It depends on your userspace code, people write real-time Java code in
>     userspace just fine.
>    
>     > 3. Is mainline kernel unable to support such requirements and we better
>     use RT
>     > patch such as xemonai ?
> 
>     Why not try it out yourself and see?? You have the code and the hardware
>     to test, you don't need us to tell you if this works or not :)
> 
> 
> Hi,
> 
> I mean that the requirements doesn't allow missing of these time intervals for
> send/receive.
> Say If I'll test and it shall work OK, does it mean that in a more loaded usage
> (more threads in a future application), it shall still function correctly with
> the same kernel (from mainline) ?

Again, it all depends on your hardware.

But if you want to make sure your deadlines are met, use the -rt
patchset and do a lot of testing to ensure things work properly.  Don't
just trust some random person on a random mailing list to tell you if it
works or not :)

> I also wanted to ask if it is doing real-time in kernel is better than doing it
> in userspace ?

Again, it all depends on what you are wanting to do, and your hardware.
Battleships are doing real-time work, in Java, on Linux, just fine.
Does that mean that any Linux machine can do that same workload with the
same deadlines?  Of course not, you have to consider the whole system
(hardware and software) to be able to determine any of this.

> Since we have some doubts if kernel can support such hard requirements, I
> raised this question. I know that Xenomai was created to make kernel hard
> real-time.?

I have no idea what xenomai is, again, please look into the -rt
patchset, and your hardware platform requirements.

good luck!

greg k-h

      reply	other threads:[~2016-12-05 14:54 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-05 14:24 Driver with hard RT requiremnets Ran Shalit
2016-12-05 14:35 ` Greg KH
2016-12-05 14:49   ` Ran Shalit
2016-12-05 14:54     ` Greg KH [this message]

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=20161205145456.GA31919@kroah.com \
    --to=greg@kroah.com \
    --cc=kernelnewbies@lists.kernelnewbies.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).