From: wireless <wireless@tampabay.rr.com>
To: gentoo-embedded@lists.gentoo.org
Subject: Re: [gentoo-embedded] Looking for low-latency docs
Date: Mon, 30 Mar 2009 15:57:35 -0400 [thread overview]
Message-ID: <49D1242F.7090308@tampabay.rr.com> (raw)
In-Reply-To: <49D10A2C.2060509@hiramoto.org>
Karl Hiramoto wrote:
> wireless wrote:
>> Hello,
>>
>>
>> I'd be curious to see any discussions/links others
>> have related to the various options for low-latency
>> (kernels &) techniques, either legacy or current,
>> that are available/recommended for embedded
>> gentoo. Any other embedded linux distros
>> discussions/links related to low latency
>> are of interest too.
>>
>>
>> Any discussion of experiences
>> with your low-latency efforts are also of
>> interest to me, specific the the kernel or
>> otherwise.
>>
>>
>> A treatise or technical doc (discussion)
>> would be keen. My googling has produced many
>> "low quality" urls.... out of the morass of
>> links.... (so I'm missing something on my
>> searches)
>> Some man pages to set the scheduler:
>>
> You might want to explain what you are doing, or what you are trying to achive.
Researching how close an embedded (linux) system, on a given processor
can get to a state machine or a commercial Rtos.
What mechanisms are theoretically possible. Mechanisms that work
and actually exist.
Published latency result (verifiable or not) base on a variety of
kernel gymnastics.
>
> 1ms-5ms latency in a user space process should be very easy to achieve
> >on a fast machine. If you want 10s of micro-second latency your
going
>to have tough time.
Ok, what is practical for which technique? Guesstimates or published
data if ok.
>
> It all depends on what your trying to do as to what the best strategy may be.
Agreed. That why I ask for a discussion on what anyone has done, not
trying to pry too deeply where folks are uncomfortable. So a
theoretical or practical example is fine.
For (mythical) example has anyone used a (hardware) interrupt in a
very fast method where it is not available to the linux kernel but, an
assembler routine could access it directly? Possible? been tried? Any
other wild ideas?
Or for another (mythical) example:
We used 2 processors, one running a state machine for directly reading
an array of 20 bit D/A in sub microsecond fashion, and then passed the
data (like this) to another processor running RT_linux (windRiver or
embedded-gentoo).....
> If your writing C code see:
Eventually C or target assembler (This research before processor
selection). It's not a question of how fast (low latency) or
such, but a research effort into here's how fast one can service an
A/D ( merely for example) with this amount of bandwidth (data per
second) under embedded (low latency linux). A discussion of trade-offs
preferable real examples but theoretical is OK too. Whats the
best that is published and believable? What tricks have any
gentoo folks used?
(another mythical example)
Maybe somebody use an OMAP chip and use the D/A under the DSP
to pass low latency data to the embedded linux running on
the Arm core of the OMAP SOC?
It's research into what is possible, claimed or otherwise
but most importantly what anyone in embedded gentoo is
willing to share, what they did. Just a 10,000 foot view,
not any sort of sensitive code, only what anyone is
willing to share.
> man sched_setscheduler
> man setpriority(int
>
> check out sched.h
>
> remember real_time != fast
Not to argue, but, I'm one that does not believe in the whole
RealTime semantic. There is only functions of Latency and functions
of Determinism. So such euphemisms such as "soft" and "hard"
RT are really nebulous constructs for me. But that does
not stop me from reading what others have published
or discussed, in terms of RT or under other related monikers.
IMHO:
"RT" is for academics and MBAs. RT means faster than human
perception, traditionally, which is sporadic and varied, at best. Hard
vs soft is also a poorly conceived concept used to attempt to extend
"RT" terminology; breaks down upon inspection of specific minutia.
But again, it's not about what I know, or believe, it's about what is
claimed and what is documented related to embedded linux, in its
many colors (i.e. kernel and other places), particular embedded
gentoo.
I'm not looking to solve any specific problem (yet) just wanting to
see what is published and what folks can verify or some practical
examples of what somebody does to achieve their balance
of low-latency with whatever measure of determinism that
they chose. However my experience is without some measure
of determinism, low-latency is pointless. ymmv, and I'd like
to here why is was not a priority in your low-latency, gentoo,
example.
I hope this *research* and discussion is specific and related to
embedded gentoo, but, certainly other embedded linux materials are of
interest to me too. Suggestions of other lists is cool too.
Google and not been fruitful for me on this, so if you find
great gentoo examples, please include what (keywords) you
used to find material.
Maybe, it as simple as, "with embedded linux (even gentoo)
nothing below 100 ms is practical, and here is why....
James
next prev parent reply other threads:[~2009-03-30 19:59 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-30 16:16 [gentoo-embedded] Looking for low-latency docs wireless
2009-03-30 16:25 ` Ahmed Ammar
2009-03-30 18:06 ` Karl Hiramoto
2009-03-30 19:57 ` wireless [this message]
2009-03-30 20:27 ` Arkadi Shishlov
2009-03-30 20:46 ` Wolfgang Denk
2009-03-30 21:37 ` Arkadi Shishlov
2009-03-30 22:32 ` Wolfgang Denk
2009-03-31 7:47 ` Mike Frysinger
2009-03-31 0:31 ` Peter Stuge
2009-03-31 18:31 ` wireless
2009-03-31 18:46 ` Peter Stuge
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=49D1242F.7090308@tampabay.rr.com \
--to=wireless@tampabay.rr.com \
--cc=gentoo-embedded@lists.gentoo.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