All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@domain.hid>
To: ckreider <ckreider@domain.hid>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] inscrutable pipes
Date: Sun, 17 Sep 2006 14:05:26 +0200	[thread overview]
Message-ID: <450D3A06.3070902@domain.hid> (raw)
In-Reply-To: <DE56BFC0-D567-44CE-99A1-869B458AE896@domain.hid>

[-- Attachment #1: Type: text/plain, Size: 2803 bytes --]

ckreider wrote:
> I think I will expand on this because Xenomai coders are on this list.
> 
> We have two product lines that have been made for several years with
> custom hardware and proprietary RTOS.  We decided to migrate these to
> COTS hardware and Linux.  Conventional wisdom, right?  The other line
> migrated first.  There was pain, but not unbearable.  We used RTLinux
> because we needed something that could sample the A/D card at
> predictable intervals and it was what was available at the time.  I
> recently embarked on the conversion of my line and ran into a big
> problem.  My A/D card controls the timing, so I shouldn't need and
> RTOS.  I have a serial stream of 20 byte packets at 60 hz, but Linux
> should handle that, right?  Well, if I had Mot serial chips that did
> hardware handshake, it would be OK, but COTS hardware has 16550s which
> require and interrupt to drop the handshake line(s).  If Linux it too
> busy to service an interrupt for a full receive fifo, how is it going to
> handle the handshake?  It can't.  So I was dropping bytes every so
> often.  Linux didn't have to mask the interrupt for long, just a fifo
> full at 38400. So it wsa RTOS time.  I picked Xenomai this time
> primarily because of the patent issues, but it has a serial driver
> also.  I am not sorry. Yeah, there was some pain with the pipes, but it
> is working slick now.  The serial task is only using 0.1% of a
> relatively slow CPU.  I like the status in/proc. 

Though real numbers will likely not be several orders of magnitude
larger, be careful with that stats: they do not (yet) account for the
IRQ handler load correctly. In fact, some heavy part of the serial job
(reading bytes out of the 16550) runs in IRQ context, and that is
accounted to the task which was preempted - often ROOT, i.e. Linux.

I'm thinking about a more satisfying solution for quite a while, and I
think I found one now. Just needs a bit more refinement and testing, but
the first number are already telling ("latency -p100" on an unloaded
Pentium-M 1.3 GHz):

CPU  PID    MSW        CSW        PF    STAT       %CPU  NAME
  0  0      0          749680     0     01400080   98.0  ROOT
  0  7987   22         46         0     00c00082    0.0  display-7986
  0  7988   0          224356     0     00c00084    1.4  sampling-7986
  0  0      0          26143452   0     00000000    0.6  [IRQ216][timer]

> I like the level of
> support here.  Most of all, I like the quality of Xenomai.  Fantastic
> job all who are involved in Xenomai, and a heartfelt thanks.

In the name of all: We thank you for all the compliments! Though we
certainly don't have the impression users are unhappy with what they
find in Xenomai, hearing it explicitly is always nice.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

      reply	other threads:[~2006-09-17 12:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-14 16:06 [Xenomai-help] inscrutable pipes ckreider
2006-09-14 16:17 ` Gilles Chanteperdrix
     [not found]   ` <1BECC866-4567-477D-9A18-144496828EB7@domain.hid>
2006-09-14 21:22     ` Gilles Chanteperdrix
2006-09-23 17:59       ` Gilles Chanteperdrix
2006-09-14 16:17 ` Philippe Gerum
     [not found]   ` <38A01364-EC56-46D9-9768-A14979EA98E5@domain.hid>
     [not found]     ` <1158326750.5072.2.camel@domain.hid>
2006-09-16 11:32       ` ckreider
2006-09-17 12:05         ` Jan Kiszka [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=450D3A06.3070902@domain.hid \
    --to=jan.kiszka@domain.hid \
    --cc=ckreider@domain.hid \
    --cc=xenomai@xenomai.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 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.