1 |
Karl Hiramoto wrote: |
2 |
> wireless wrote: |
3 |
>> Hello, |
4 |
>> |
5 |
>> |
6 |
>> I'd be curious to see any discussions/links others |
7 |
>> have related to the various options for low-latency |
8 |
>> (kernels &) techniques, either legacy or current, |
9 |
>> that are available/recommended for embedded |
10 |
>> gentoo. Any other embedded linux distros |
11 |
>> discussions/links related to low latency |
12 |
>> are of interest too. |
13 |
>> |
14 |
>> |
15 |
>> Any discussion of experiences |
16 |
>> with your low-latency efforts are also of |
17 |
>> interest to me, specific the the kernel or |
18 |
>> otherwise. |
19 |
>> |
20 |
>> |
21 |
>> A treatise or technical doc (discussion) |
22 |
>> would be keen. My googling has produced many |
23 |
>> "low quality" urls.... out of the morass of |
24 |
>> links.... (so I'm missing something on my |
25 |
>> searches) |
26 |
>> Some man pages to set the scheduler: |
27 |
>> |
28 |
> You might want to explain what you are doing, or what you are trying to achive. |
29 |
|
30 |
Researching how close an embedded (linux) system, on a given processor |
31 |
can get to a state machine or a commercial Rtos. |
32 |
|
33 |
What mechanisms are theoretically possible. Mechanisms that work |
34 |
and actually exist. |
35 |
|
36 |
Published latency result (verifiable or not) base on a variety of |
37 |
kernel gymnastics. |
38 |
|
39 |
> |
40 |
> 1ms-5ms latency in a user space process should be very easy to achieve |
41 |
> >on a fast machine. If you want 10s of micro-second latency your |
42 |
going |
43 |
>to have tough time. |
44 |
|
45 |
Ok, what is practical for which technique? Guesstimates or published |
46 |
data if ok. |
47 |
|
48 |
> |
49 |
> It all depends on what your trying to do as to what the best strategy may be. |
50 |
|
51 |
Agreed. That why I ask for a discussion on what anyone has done, not |
52 |
trying to pry too deeply where folks are uncomfortable. So a |
53 |
theoretical or practical example is fine. |
54 |
|
55 |
For (mythical) example has anyone used a (hardware) interrupt in a |
56 |
very fast method where it is not available to the linux kernel but, an |
57 |
assembler routine could access it directly? Possible? been tried? Any |
58 |
other wild ideas? |
59 |
|
60 |
Or for another (mythical) example: |
61 |
We used 2 processors, one running a state machine for directly reading |
62 |
an array of 20 bit D/A in sub microsecond fashion, and then passed the |
63 |
data (like this) to another processor running RT_linux (windRiver or |
64 |
embedded-gentoo)..... |
65 |
|
66 |
|
67 |
|
68 |
> If your writing C code see: |
69 |
|
70 |
Eventually C or target assembler (This research before processor |
71 |
selection). It's not a question of how fast (low latency) or |
72 |
such, but a research effort into here's how fast one can service an |
73 |
A/D ( merely for example) with this amount of bandwidth (data per |
74 |
second) under embedded (low latency linux). A discussion of trade-offs |
75 |
preferable real examples but theoretical is OK too. Whats the |
76 |
best that is published and believable? What tricks have any |
77 |
gentoo folks used? |
78 |
|
79 |
(another mythical example) |
80 |
Maybe somebody use an OMAP chip and use the D/A under the DSP |
81 |
to pass low latency data to the embedded linux running on |
82 |
the Arm core of the OMAP SOC? |
83 |
|
84 |
It's research into what is possible, claimed or otherwise |
85 |
but most importantly what anyone in embedded gentoo is |
86 |
willing to share, what they did. Just a 10,000 foot view, |
87 |
not any sort of sensitive code, only what anyone is |
88 |
willing to share. |
89 |
|
90 |
|
91 |
> man sched_setscheduler |
92 |
> man setpriority(int |
93 |
> |
94 |
> check out sched.h |
95 |
> |
96 |
> remember real_time != fast |
97 |
|
98 |
|
99 |
Not to argue, but, I'm one that does not believe in the whole |
100 |
RealTime semantic. There is only functions of Latency and functions |
101 |
of Determinism. So such euphemisms such as "soft" and "hard" |
102 |
RT are really nebulous constructs for me. But that does |
103 |
not stop me from reading what others have published |
104 |
or discussed, in terms of RT or under other related monikers. |
105 |
|
106 |
IMHO: |
107 |
"RT" is for academics and MBAs. RT means faster than human |
108 |
perception, traditionally, which is sporadic and varied, at best. Hard |
109 |
vs soft is also a poorly conceived concept used to attempt to extend |
110 |
"RT" terminology; breaks down upon inspection of specific minutia. |
111 |
|
112 |
|
113 |
But again, it's not about what I know, or believe, it's about what is |
114 |
claimed and what is documented related to embedded linux, in its |
115 |
many colors (i.e. kernel and other places), particular embedded |
116 |
gentoo. |
117 |
|
118 |
|
119 |
I'm not looking to solve any specific problem (yet) just wanting to |
120 |
see what is published and what folks can verify or some practical |
121 |
examples of what somebody does to achieve their balance |
122 |
of low-latency with whatever measure of determinism that |
123 |
they chose. However my experience is without some measure |
124 |
of determinism, low-latency is pointless. ymmv, and I'd like |
125 |
to here why is was not a priority in your low-latency, gentoo, |
126 |
example. |
127 |
|
128 |
I hope this *research* and discussion is specific and related to |
129 |
embedded gentoo, but, certainly other embedded linux materials are of |
130 |
interest to me too. Suggestions of other lists is cool too. |
131 |
Google and not been fruitful for me on this, so if you find |
132 |
great gentoo examples, please include what (keywords) you |
133 |
used to find material. |
134 |
|
135 |
|
136 |
Maybe, it as simple as, "with embedded linux (even gentoo) |
137 |
nothing below 100 ms is practical, and here is why.... |
138 |
|
139 |
|
140 |
James |