The new RT kernel is out, there is a test graph under load which should
answer a lot of questions on latency.
https://www.osadl.org/Single-View.111+M5acfc476362.0.html
I have a question on what to do with the Preempt-RT patches for EMC , where
do they go ?
2.4 , 2.5
They are really no
On Wed, Jul 20, 2011 at 10:02:05AM +0200, Lars Segerlund wrote:
> I have a question on what to do with the Preempt-RT patches for EMC ,
> where do they go ?
>
> 2.4 , 2.5
>
> Anyhow, can we agree if they go in a separate branch , and to which
> version ? so that we can get them included.
You
On Wed, Jul 20, 2011 at 2:02 AM, Lars Segerlund wrote:
>
> The new RT kernel is out, there is a test graph under load which should
> answer a lot of questions on latency.
>
> https://www.osadl.org/Single-View.111+M5acfc476362.0.html
>
Great! sounds good. However, what about these two machines?
On 20 July 2011 13:04, Jonathan George wrote:
> Only one of the four machines being tested with the new kernel has "good"
> performance compared to rtapi?
RTAI has problems on some hardware too, though. Those plots seem to
show 20 "bad" samples in 100,000
Even the bad examples are perfectly fi
Hi,
Still good enough for open loop systems . RT-Preempt is a work in
progress, and this is rc0 , hopefully it will improve but it is unlekely
that it will 'beat' rtapi ... or similar.
Still good enough for a lot of stuff, and good enough for me at the moment.
On a note, the other machines
Lars Segerlund wrote:
>
> The new RT kernel is out, there is a test graph under load which
> should answer a lot of questions on latency.
>
> https://www.osadl.org/Single-View.111+M5acfc476362.0.html
>
Yes, but that looks like an insanely high-end 8-CPU machine, I wonder
what the results would
just look at the others
eg
from
https://www.osadl.org/Linux-kernels-under-test-by-kernel.qa-farm-kernels-bykernel.0.html
left link shows the makeup of the machine
https://www.osadl.org/Profile-of-system-in-rack-3-slot-2.qa-profile-r3s2.0.html
Dave Caroline
On Wed, Jul 20, 2011 at 4:56 PM, Jon El
Out of curiosity I tried to find results for D510 and D525 boards -
they both are mentioned in the list of tested systems.
This is D510:
https://www.osadl.org/Latency-plot-of-system-in-rack-1-slot.qa-latencyplot-r1s4.0.html?latencies=&showno=&slider=228
This is D525:
https://www.osadl.org/Latency
Well, the 510 doesn't look too bad. more like 12 us. by the time you get
to 20 us the curve is in the 1% range. The 525 doesn't look nearly as
good with a spread of values pretty much equal out into the 20-30 us
area.
Of course maybe I've forgotten how to read semi-log graphs. ;-)
IIRC I've been r
Viesturs Lācis wrote:
> Out of curiosity I tried to find results for D510 and D525 boards -
> they both are mentioned in the list of tested systems.
>
> This is D510:
> https://www.osadl.org/Latency-plot-of-system-in-rack-1-slot.qa-latencyplot-r1s4.0.html?latencies=&showno=&slider=228
>
> This is D
On 7/20/2011 9:41 PM, Jon Elson wrote:
> Yes, I think the extra "CPUs" are
> from hyperthreading, and disabling
> it should help.
>
Rtapi on the D510 with hyperthreading enabled is pretty bad also... Why
would they leave hyperthreading enabled on a Linux system?
I thought hyperthreading was
I believe there is some information about the test load at the bottom of
this page.
https://www.osadl.org/?id=864
/ regards, Lars Segerlund
2011/7/20 Jon Elson
> Lars Segerlund wrote:
> >
> > The new RT kernel is out, there is a test graph under load which
> > should answer a lot of questio
Hi,
First of, the number of 'cores is what /proc/ reports ... ( I think it's
straight from there )...
And secondly, since preemtp-rt have as it's goal to go in mainline it runs
fine on multicore machines, in fact under load preempt-rt 'REALLY' comes
into it's own ..
Now, if you look at the ve
Note the Machines are running different kernels !
/ regarsd, Lars Segerlund.
2011/7/21 dave
> Well, the 510 doesn't look too bad. more like 12 us. by the time you get
> to 20 us the curve is in the 1% range. The 525 doesn't look nearly as
> good with a spread of values pretty much equal out i
Hi,
Hyperthreading is actually really good, if you are running threaded
interrupts, which linux 3.0 does, and that constitues one of the 'core'
technologies in preempt-rt
:-D , Lars Segerlund.
2011/7/21 Dave
> On 7/20/2011 9:41 PM, Jon Elson wrote:
> > Yes, I think the extra "CPUs" are
On Wed, 20 Jul 2011, Jon Elson wrote:
Date: Wed, 20 Jul 2011 20:41:44 -0500
From: Jon Elson
Reply-To: EMC developers
To: EMC developers
Subject: Re: [Emc-developers] Preempt-RT ... where to put the patches ?
Viesturs L??cis wrote:
Out of curiosity I tried to find results for D510 and D525
patches ?
On Wed, 20 Jul 2011, Jon Elson wrote:
> Date: Wed, 20 Jul 2011 20:41:44 -0500
> From: Jon Elson
> Reply-To: EMC developers
> To: EMC developers
> Subject: Re: [Emc-developers] Preempt-RT ... where to put the patches ?
>
> Viesturs Lcis wrote:
> Out of c
On Thu, 21 Jul 2011, Steve Stallings wrote:
> Date: Thu, 21 Jul 2011 10:46:13 -0500
> From: Steve Stallings
> Reply-To: EMC developers
> To: 'EMC developers'
> Subject: Re: [Emc-developers] Preempt-RT ... where to put the patches ?
>
> Peter,
>
> Good p
On 7/21/2011 11:53 AM, Peter C. Wallace wrote:
> On Thu, 21 Jul 2011, Steve Stallings wrote:
>
>
>> Date: Thu, 21 Jul 2011 10:46:13 -0500
>> From: Steve Stallings
>> Reply-To: EMC developers
>> To: 'EMC developers'
>> Subject: Re: [Emc-de
Peter C. Wallace wrote:
>
> Well 100 uSec of jitter should be perfectly acceptable _if_ the PID
> (or hardware stepgen) corrections were based on actual time instead of
> thread
> invocation time, heck even 500 uSec jitter might be OK.
Hmm, I don't know. Without velocity estimation, I'm not sure
Steve Stallings wrote:
> Peter,
>
> Good point about interrupt jitter mattering less if
> the actual sample time does not jitter. Unfortunately
> the current RTAI setup requires that the interrupt
> comes from the host interrupt timers. If we could
> get to a system model where the hardware could
>
Dave wrote:
> So basically you could factor out the jitter entirely?
>
> That sounds like a really good idea! :-)
>
Well, you can't, really. You can only reduce the likelihood of the
jitter affecting the calculations.
The problem is that a thread can be interrupted at any point, without
any
On Thu, 21 Jul 2011, Jon Elson wrote:
> Date: Thu, 21 Jul 2011 12:01:29 -0500
> From: Jon Elson
> Reply-To: EMC developers
> To: EMC developers
> Subject: Re: [Emc-developers] Preempt-RT ... where to put the patches ?
>
> Dave wrote:
>> So basically you could fac
500
>> From: Jon Elson
>> Reply-To: EMC developers
>> To: EMC developers
>> Subject: Re: [Emc-developers] Preempt-RT ... where to put the patches ?
>>
>> Dave wrote:
>>> So basically you could factor out the jitter entirely?
>>>
>>>
On 21 July 2011 18:30, Brian wrote:
> It seems the servo thread would be the highest priority code
If there is a base thread, then that has higher priority. You don't
want to interrupt the step pulses to calculate the next position.
--
atp
"Torque wrenches are for the obedience of fools and the
On Thu, 21 Jul 2011, Brian wrote:
> Date: Thu, 21 Jul 2011 13:30:00 -0400
> From: Brian
> Reply-To: EMC developers
> To: EMC developers
> Subject: Re: [Emc-developers] Preempt-RT ... where to put the patches ?
>
> It seems the servo thread would be the highest prio
eve Stallings (unrepentant top poster)
>
> -Original Message-
> From: Peter C. Wallace [mailto:p...@mesanet.com]
> Sent: Thursday, July 21, 2011 9:34 AM
> To: EMC developers
> Subject: Re: [Emc-developers] Preempt-RT ... where to put the patches ?
>
> On Wed, 20 Ju
Actually it's the patches from : http://www.bitmuster.org/projects/emc.html
I spoke with Michael Abel, and the patches I had and the one he had
done were from the same origin, ( check his page above ).
The patches are not intrusive, and unless you build with RT-Preempt
support they don't affect
On Wed, Jul 27, 2011 at 10:35:52AM +0200, Lars Segerlund wrote:
> Actually it's the patches from : http://www.bitmuster.org/projects/emc.html
>
> I spoke with Michael Abel, and the patches I had and the one he had
> done were from the same origin, ( check his page above ).
You've used his patches
Hi again,
Se below I'll try to answer to the best of my ability.
2011/7/27 Pavel Shramov :
> On Wed, Jul 27, 2011 at 10:35:52AM +0200, Lars Segerlund wrote:
>> Actually it's the patches from : http://www.bitmuster.org/projects/emc.html
>>
>> I spoke with Michael Abel, and the patches I had and
Hello Pavel, Lars and all the others,
I'm happy to see that there is some interest on porting to rt-preempt...
at least it's worth for discussions :)
On 07/27/2011 11:24 AM, Lars Segerlund wrote:
Hi again,
Se below I'll try to answer to the best of my ability.
2011/7/27 Pavel Shramov:
O
Lars,
I'd suggest cloning emc2's current master on say github, branch and apply from
there, so at least you're working within the emc history trail and there no
sudden history-free 'out-of-nowhere' patches
when the dust settles, and the it could be made a feature branch on
git.linuxcnc.org
wh
Hello Folks,
Finally, the RT-Preempt adoptions of EMC are online at gitorious:
They are available via this link:
git://gitorious.org/emc-rt-preempt/emc-rt-preempt.git
I hope that everything is OK there, since I'm still relatively new to git.
The branch for the adoptions is called "2.4.4-rt-sh
Hi everybody,
Now that Michael have put up a git repository, how do we go about
getting stuff pulled ?
A ( for me ) logical way to do this would be to pull the rt-api
parts, and after that the parts touching the makefiles .
What is needed to get going ?
/ regards, Lars Segerlund.
2011/
34 matches
Mail list logo
