On Tue, 24 Mar 2009, Giacomo A. Catenazzi wrote:
> Do you really need real time kernel?
> Debian is a technical driven project, but reading the previous two quotes,
> "real time" is used as marketing thing.

It's good to question the use of any feature, but a real-time kernel is
certainly very useful in many industrial applications and Debian is
popular in that field. (Don't put a marketing label on anything where
you are not yourself sure of your expertise.)

I do use a real-time kernel on a Debian based system for one of my
customers (but I have to recompile the kernel anyway because I do other
customizations) and I have good reasons to do so because I can't suffer
serial overrun and I must ensure that the serial interrupt handler
is run in the required time and that no other (kernel) task has higher
priority.

Cheers,
--
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Raphael Hertzog wrote:

On Tue, 24 Mar 2009, Giacomo A. Catenazzi wrote:

Do you really need real time kernel?
Debian is a technical driven project, but reading the previous two quotes,
"real time" is used as marketing thing.


It's good to question the use of any feature, but a real-time kernel is
certainly very useful in many industrial applications and Debian is
popular in that field. (Don't put a marketing label on anything where
you are not yourself sure of your expertise.)


Yes, I didn't write very well my sentence: the previous quotes was more
about "there exist rt kernels", "ubuntu has a rt kernel", but not solid
requirements. I had to write some "seems", and I'm sorry for the two
quoted people if it seems an attack.
Anyway, later in the mail, I asked for precise needs, so we could see
better what we should improve.

IMHO most users want a low latency kernel, but not a slower kernel, so
a CONFIG_HZ_1000 would be nice. But the original post was about
multimedia production (and not reproduction), so the needs are probably
other.

My point was more:
- Debian has not rt kernel. Why? Non DD interested or/and low demand?
This is an important point. We must not produce a rt-kernel if
we cannot provide testers and developers (in unstable).
- kernel management is a weak point in distribution: no good method
for kernel dependencies, using full capabilities, ...

so IMHO we should try harder with the normal kernel, so that we
can use the same infrastructure and testers. If we fail and we
are able to support rt kernels, IMO it is good to provide it in Debian.

The original mail was about "multimedia production" and few year ago kernel
developers had a lot of interaction with music industries.
I'm not an expert in the field, but how far are we in their need with
standard kernels?)



I do use a real-time kernel on a Debian based system for one of my
customers (but I have to recompile the kernel anyway because I do other
customizations) and I have good reasons to do so because I can't suffer
serial overrun and I must ensure that the serial interrupt handler
is run in the required time and that no other (kernel) task has higher
priority.


These *other customizations* are important to rt-kernel. So we need
a person (or more) that know the needs and could support us.
"realtime" alone is only a label ;-)

ciao
cate


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Tue, 24 Mar 2009, Giacomo A. Catenazzi wrote:
>> I do use a real-time kernel on a Debian based system for one of my
>> customers (but I have to recompile the kernel anyway because I do other
>> customizations) and I have good reasons to do so because I can't suffer
>> serial overrun and I must ensure that the serial interrupt handler
>> is run in the required time and that no other (kernel) task has higher
>> priority.
>
> These *other customizations* are important to rt-kernel.

No they are not. It's a supplementary driver only.

By -rt kernel, I refer to the patch set maintained by Thomas Gleixner and
Ingo Molnar:
http://rt.wiki.kernel.org
http://www.kernel.org/pub/linux/kernel/projects/rt/

The patch set is progressively integrated in Linus's tree but there's
still some work left and it will likely continue to exist for a long time.
FWIW LWN has articles about its (progressive) integration.

Of course, if we add a -rt flavor, we should have someone willing to
maintain it within the kernel team.

Cheers,
--
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Giacomo A. Catenazzi wrote:

Raphael Hertzog wrote:

On Tue, 24 Mar 2009, Giacomo A. Catenazzi wrote:

Do you really need real time kernel?
Debian is a technical driven project, but reading the previous two
quotes,

"real time" is used as marketing thing.


It's good to question the use of any feature, but a real-time kernel is
certainly very useful in many industrial applications and Debian is
popular in that field. (Don't put a marketing label on anything where
you are not yourself sure of your expertise.)


Yes, I didn't write very well my sentence: the previous quotes was more
about "there exist rt kernels", "ubuntu has a rt kernel", but not solid
requirements. I had to write some "seems", and I'm sorry for the two
quoted people if it seems an attack.
Anyway, later in the mail, I asked for precise needs, so we could see
better what we should improve.

IMHO most users want a low latency kernel, but not a slower kernel, so
a CONFIG_HZ_1000 would be nice. But the original post was about
multimedia production (and not reproduction), so the needs are probably
other.

My point was more:
- Debian has not rt kernel. Why? Non DD interested or/and low demand?
This is an important point. We must not produce a rt-kernel if
we cannot provide testers and developers (in unstable).
- kernel management is a weak point in distribution: no good method
for kernel dependencies, using full capabilities, ...

so IMHO we should try harder with the normal kernel, so that we
can use the same infrastructure and testers. If we fail and we
are able to support rt kernels, IMO it is good to provide it in Debian.

The original mail was about "multimedia production" and few year ago
kernel

developers had a lot of interaction with music industries.
I'm not an expert in the field, but how far are we in their need with
standard kernels?)



I do use a real-time kernel on a Debian based system for one of my
customers (but I have to recompile the kernel anyway because I do other
customizations) and I have good reasons to do so because I can't suffer
serial overrun and I must ensure that the serial interrupt handler
is run in the required time and that no other (kernel) task has higher
priority.


These *other customizations* are important to rt-kernel. So we need
a person (or more) that know the needs and could support us.
"realtime" alone is only a label ;-)


Thanks for the reactions so far! I think the newer kernels are improved
for realtime (for audio usage, real low latency etc.). And there was
some discussion about better realtime support in default kernels:


http://linuxmusicians.com/viewtopic.php?f=24&t=490

I think 95% of the users of the linuxaudio.org community (LAU
mailinglist) uses a realtime kernel (CONFIG_HZ_1000 + Mingo patch
(!?)). Discussion if it is still needed bumps up there once in a while,
for example:


http://linuxaudio.org/mailarchive/lau/2009/3/10/153190

But till now people reports better results (mostly in terms of latency
and xruns for jackd) with a patched kernel.


I know two people has started working again on rt patches for the newer
kernel:


http://lwn.net/Articles/319544/
quote:
The realtime preemption project is a longstanding effort to provide
deterministic response times in a general-purpose kernel. Much code
resulting from this work has been merged into the mainline kernel over
the last few years, and a number of vendors are shipping commercial
products based upon it. But, for the last year or so, progress toward
getting the rest of the realtime work into the mainline has slowed.
On February 11, realtime developers Thomas Gleixner and Ingo Molnar
resurfaced with the announcement of a new realtime preemption tree and
a newly reinvigorated development effort.


Merging into the mainline kernel would be the best imho. So people who
want to record stuff, realtime with fx, can use the default kernel. It
would make a lot of people pretty happy.


Kind regards,




--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

> I think 95% of the users of the linuxaudio.org community (LAU mailinglist)
> uses a realtime kernel (CONFIG_HZ_1000 + Mingo patch (!?)). Discussion if
> it is still needed bumps up there once in a while, for example:
>
> http://linuxaudio.org/mailarchive/lau/2009/3/10/153190
>
>
> But till now people reports better results (mostly in terms of latency and
> xruns for jackd) with a patched kernel.

I for one would be very interested in an uptodate realtime kernel in Debian.
And I'm definately not alone in that wish.

Given that there are several audio oriented distributions based on Debian
(e.g. 64studio and pure:dyne) that would benefit from this, and I am sure
their teams may be interested in helping to support it too.
Also any users who started out with 64studio and want to upgrade to a more
uptodate system, would be interested in a rt-kernel.

>From my personal experience the debian kernel 2.6.24 was a bit better for
audio stuff, but had a problem with the FTDI serial driver, so I had to go up
to the 2.6.26 kernel, which gave me some xruns in jackd unfortunately.

A lot of linux audio users build their own patched kernels, because they can't
get it from the distribution; and not all of them enjoy doing it. (I've kept
postponing it, but if I don't find one in a distro soon, I'll probably have
to... the current Ubuntu rt kernel seems to have some other issues I
believe... at least on 64bit...)

sincerely,
Marije


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Tue, 24 Mar 2009, nescivi wrote:


Given that there are several audio oriented distributions based on Debian
(e.g. 64studio and pure:dyne) that would benefit from this, and I am sure
their teams may be interested in helping to support it too.


IMHO it makes perfectly sense to try to join forces with these Debian
based distributions and try to comaintain a -rt kernel package together
with these guys to ensure a solit maintenance inside Debian.


A lot of linux audio users build their own patched kernels, because they can't
get it from the distribution;


So why don't these people try to go the right way (tm) and work on an
official -rt kernel package?


and not all of them enjoy doing it. (I've kept
postponing it, but if I don't find one in a distro soon, I'll probably have
to... the current Ubuntu rt kernel seems to have some other issues I
believe... at least on 64bit...)


One reason more to finally solve the problem in the source distribution
to make sure that all derivers will profit from it.

Kind regards

Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Andreas Tille wrote:

On Tue, 24 Mar 2009, nescivi wrote:

Given that there are several audio oriented distributions based on
Debian
(e.g. 64studio and pure:dyne) that would benefit from this, and I am
sure

their teams may be interested in helping to support it too.


IMHO it makes perfectly sense to try to join forces with these Debian
based distributions and try to comaintain a -rt kernel package together
with these guys to ensure a solit maintenance inside Debian.

A lot of linux audio users build their own patched kernels, because
they can't

get it from the distribution;


So why don't these people try to go the right way (tm) and work on an
official -rt kernel package?


and not all of them enjoy doing it. (I've kept
postponing it, but if I don't find one in a distro soon, I'll
probably have

to... the current Ubuntu rt kernel seems to have some other issues I
believe... at least on 64bit...)


One reason more to finally solve the problem in the source distribution
to make sure that all derivers will profit from it.


A little sidestep:

Also for a realtime kernel for music production it's important to have
the right drivers in it, to support firewire devices for example. I read
this on the Debian multimedia mailinglist:




We're aiming to have this package in 64 Studio 3.0, we also need to
change our 2.6.29-rc4 kernel to support the old firewire stack though.


>> Why only in 64studio and not in plain Debian?

What's good for Debian is good for us :-) but the Debian project may
not want to tweak the kernel or the FireWire stack just for the
benefit of FFADO users. In the 64 Studio project we have more
flexibility to do things like that.


Some background info here:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/276463
What is true about this? Shouldn't plain Debian also support those Pro
audio Firewire devices, the ones the FFADO team are making drivers for?


Regards,






--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Grammostola Rosea <rosea.grammostola@gmail.com> writes:

> Shouldn't plain Debian also support those Pro audio Firewire devices,
> the ones the FFADO team are making drivers for?

Debian as a whole probably not. However interested contributors are
strongly encouraged to help the debian kernel maintainers to integrate
that patchset to the kernel package.

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Wed, Mar 25, 2009 at 12:37:37PM +0100, Grammostola Rosea wrote:

> > >> Why only in 64studio and not in plain Debian?
> > What's good for Debian is good for us :-) but the Debian project may
> > not want to tweak the kernel or the FireWire stack just for the
> > benefit of FFADO users. In the 64 Studio project we have more
> > flexibility to do things like that.
> > Some background info here:
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/276463
> What is true about this? Shouldn't plain Debian also support those Pro
> audio Firewire devices, the ones the FFADO team are making drivers for?


It's easy:

http://ieee1394.wiki.kernel.org/index.php/Juju_Migration#Module_auto-loading


Compile both modules and blacklist the new Juju modules. That's the
current upstream recommendation.

Even if the default will change around 2.6.30 (or later, I don't know
the exact schedule), the FFADO users could still enable the old ieee1394
modules.

We already have libraw1394-v2 in sid, but as outlined, FFADO currently
only works with the old stack. This might also change in the future,
especially if the Google Summer of Code project succeeds. (in-kernel
alsa driver module for firewire audio)


IOW: ship both stacks, decide for one and blacklist the other. FFADO
users will then select the appropriate one. And of course, I'll continue
looking into the FFADO-on-Juju issue.


HTH

--
mail: adi@thur.de http://adi.thur.de PGP/GPG: key via keyserver


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org