On Fri, May 27, 2016 at 10:27 AM, Todd Rme wrote:

On Thu, May 26, 2016 at 6:02 PM, Jason Newton wrote:

...

As a former heavy user of real time preempt patch and RTAI, I found for many tasks I no longer needed it in the last few years. I'd recommend putting in some fine grained auditing for time of computations/io stages and measure the timing/jitter/stats as time series to analyze system behavior. You might find it works perfectly fine for you with the desktop kernel. Basically the timing jitter we're talking here, assuming you've set your schedulers, split things up appropriately, and tuned the slow/problematic spots, down to a millisecond or under. I've had IO jitter, through use of tmpfs or carefully written IO to XFS be very low jitter as well - but this is a larger discussion (which the RT patch wont solve) if you have large datarates (several hundred MiB/s).

Millisecond timing jitter is a problem for what we are doing.

Well my point is that YMMV and it very much depends on what you are doing, but you can get submillisecond jitter - I was trying to be conservative in what you might see but I don't think I ever found a clear lower limit, I'd guess in the 10s of microseconds. It will depend on the hardware you have too, and then you need to swallow the fact that you're not on a hard real-time OS still, so going submillisecond is risky buisiness and you should at least consider Xenomai for those cases. I guess I can only say measure to make sure you need such a patch... and really you should measure even when you use the patch, too.

...

I honestly don't think it's worth the effort to maintain it in a repo with all the other kernels since the versions it works with are out of sync with their stable release.

RTAI is out-of-sync with stable releases, but RT-Preempt is kept in sync. For example the 4.6 patch set was released before the 4.6 kernel was released.

My point was on the RT-Prempt patch and it didn't always follow so dutifully, nor is it required to. I haven't kept up it so I don't know in the last few years how deterministic they are anymore with releases, but I recall them missing kernel releases in the past and then there was the stable series patches and sort of next gen patches. That's alot of extra complexity to track and deal with for a handful of users who have within their capability to simply compile the kernels themselves. Further, these users usually stick with the kernel they get working for a fairly long time.

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org