[gentoo-amd64] kernel.org vs. Gentoo-64 bit kernels (xruns)

[gentoo-amd64] kernel.org vs. Gentoo-64 bit kernels (xruns)

[Mark Knecht]

Hi,
   Is there a simple document around that would tell me something
about the differences between the Gentoo 64-bit kernel and the
standard 2.6.13.2 kernel from kernel.org? I'm a audio user, live audio
recording, etc., and use Jack all the time. My new AMD64 machine is
giving me many xrun problems that I have not seen on other Gentoo
machines running Gentoo kernels. However all previous Gentoo machines
were 32-bit and here I'm running the 64-bit kernel.

   I'm considering building a kernel from kernel.org with the realtime
patches applied which will probably fix things according to the
Jack-audio developer folks. Unfortunately the  patch set for 2.6.13
does not apply cleanly against the Gentoo 64-bit kernel source, so I'm
wondering what I'd be missing by using the kernel.org kernel instead.

   I also need to determine if the problems are possibly because of
this new NForce4 chipset but that may take awhile.

   Thanks in advance for any info you might provide.

Cheers,
Mark

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] kernel.org vs. Gentoo-64 bit kernels (xruns)

[P.V.Anthony]

Mark Knecht wrote:
> Hi,
>    Is there a simple document around that would tell me something
> about the differences between the Gentoo 64-bit kernel and the
> standard 2.6.13.2 kernel from kernel.org? I'm a audio user, live audio
> recording, etc., and use Jack all the time. 

I am just happy to see another audio person in this list.

I too do audio recording. Ashamed to say this, but I use Mac and Windows for 
that and not Gentoo. Sorry.

P.V.Anthony
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] kernel.org vs. Gentoo-64 bit kernels (xruns)

[Mark Knecht]

On 9/19/05, P.V.Anthony <pvantony@singnet.com.sg> wrote:
> Mark Knecht wrote:
> > Hi,
> >    Is there a simple document around that would tell me something
> > about the differences between the Gentoo 64-bit kernel and the
> > standard 2.6.13.2 kernel from kernel.org? I'm a audio user, live audio
> > recording, etc., and use Jack all the time.
> 
> I am just happy to see another audio person in this list.
> 
> I too do audio recording. Ashamed to say this, but I use Mac and Windows for
> that and not Gentoo. Sorry.

Perfectly cool with me. We've all been there. I was a Pro Tools user
for a long time. Sold it and run Ardour now, very successfully up
until this machine/kernel. It's to be expected though. My last laptop
used a new ATI chipset at the time. It took a couple of months before
everything caught up and worked well. Probably the same here. I expect
it will be fine one of these days soon.

I still use Win XP for a few soft synths - NI Guitar Rig, Battery,
Reaktor, GigaStudio (in parallel with LinuxSampler) Acid Pro, etc.
Mainly just stuff for which there is no Linux equivalent app in
existance.

Drop me a note anytime you want to chat about this sort of stuff.

Cheers,
Mark

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] kernel.org vs. Gentoo-64 bit kernels (xruns)

[Billy Holmes]

Mark Knecht wrote:

> everything caught up and worked well. Probably the same here. I expect
> it will be fine one of these days soon.

take a look in the ck (ck-sources) mailing list:

http://bhhdoa.org.au/mailman/listinfo/ck

http://kernel.kolivas.org/

It's moderated by the author. They always have some talk about 
interactivity which leads to audio talk. There are a few audio guys on 
there that should be able to give you some ideas/links. ck tends to 
attract audio and video people, because of it's low latency. From what I 
can gather, audio people feel ck may not be perfect for audio apps, but 
it's a good start.
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] kernel.org vs. Gentoo-64 bit kernels (xruns)

[Mark Knecht]

On 9/19/05, Billy Holmes <billy@gonoph.net> wrote:
> Mark Knecht wrote:
> 
> > everything caught up and worked well. Probably the same here. I expect
> > it will be fine one of these days soon.
> 
> take a look in the ck (ck-sources) mailing list:
> 
> http://bhhdoa.org.au/mailman/listinfo/ck
> 
> http://kernel.kolivas.org/
> 
> It's moderated by the author. They always have some talk about
> interactivity which leads to audio talk. There are a few audio guys on
> there that should be able to give you some ideas/links. ck tends to
> attract audio and video people, because of it's low latency. From what I
> can gather, audio people feel ck may not be perfect for audio apps, but
> it's a good start.

Thanks. Yes, I've run ck-sources a few times in the past but not had
good luck with it. I'm also suspicious that the problem I'm currectly
seeing with the gentoo-sources AMD64 kernel is likely to not be solved
by this. It seems right now that a simple emerge sync is causing xruns
on this system implying to me some underlying problem with either hard
drive activity or networking. since the hard drive is SATA and the
networking option in the kernel marks the NIC driver as 'Reverse
engineered - experimental' I'm not confident of fixing this problem in
the immediate short term anyway.

My thoughts right now:

1) kernel.org + rt patches
2) ck-sources
3) gentoo-sources-amd64 + rt patches not cleanly applied

   I may also investigate a different NIC. I have a email friend that
runs a studio in Sydney. I helped him move from FC2 to Gentoo. We had
xruns using some of the NIC stuff for his motherboard. When we found
that was the problem he never had another problem.

   Thanks for your ideas.

cheers,
Mark

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] kernel.org vs. Gentoo-64 bit kernels (xruns)

[Tres Melton]

On Mon, 2005-09-19 at 11:16 -0700, Mark Knecht wrote:
> Hi,
>    Is there a simple document around that would tell me something
> about the differences between the Gentoo 64-bit kernel and the
> standard 2.6.13.2 kernel from kernel.org? I'm a audio user, live audio
> recording, etc., and use Jack all the time. My new AMD64 machine is
> giving me many xrun problems that I have not seen on other Gentoo
> machines running Gentoo kernels. However all previous Gentoo machines
> were 32-bit and here I'm running the 64-bit kernel.

The homepage for that is:  http://dev.gentoo.org/~dsd/genpatches
The patches are in /usr/portage/sys-kernel/gentoo-sources/files/
And the ebuild is
here /usr/portage/sys-kernel/gentoo-sources/gentoo-sources-2.6.13.ebuild

>    I'm considering building a kernel from kernel.org with the realtime
> patches applied which will probably fix things according to the
> Jack-audio developer folks. Unfortunately the  patch set for 2.6.13
> does not apply cleanly against the Gentoo 64-bit kernel source, so I'm
> wondering what I'd be missing by using the kernel.org kernel instead.
> 
>    I also need to determine if the problems are possibly because of
> this new NForce4 chipset but that may take awhile.
> 
>    Thanks in advance for any info you might provide.
> 
> Cheers,
> Mark
> 
-- 
Tres Melton
IRC & Gentoo: RiverRat

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] kernel.org vs. Gentoo-64 bit kernels (xruns)

[Mark Knecht]

On 9/19/05, Tres Melton <tres@mindspring.com> wrote:

> The homepage for that is:  http://dev.gentoo.org/~dsd/genpatches

Thanks. This is interesting. I See that one patch is for NVidia SATA
DMA whic is important ot me.

> The patches are in /usr/portage/sys-kernel/gentoo-sources/files/

Yes, this I knew.

> And the ebuild is here /usr/portage/sys-kernel/gentoo-sources/gentoo-sources-2.6.13.ebuild

This doesn't help me. I'm not a programmer - I'm a guitar player. I
don't read ebuilds at all. Completely a foreign language to me...

I appreaciate the info a lot. Thanks!

Cheers,
Mark

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] kernel.org vs. Gentoo-64 bit kernels (xruns)

[Mark Knecht]

On 9/19/05, Billy Holmes <billy@gonoph.net> wrote:
> Mark Knecht wrote:
> 
> > everything caught up and worked well. Probably the same here. I expect
> > it will be fine one of these days soon.
> 
> take a look in the ck (ck-sources) mailing list:
> 
> http://bhhdoa.org.au/mailman/listinfo/ck
> 
> http://kernel.kolivas.org/
> 
> It's moderated by the author. They always have some talk about
> interactivity which leads to audio talk. There are a few audio guys on
> there that should be able to give you some ideas/links. ck tends to
> attract audio and video people, because of it's low latency. From what I
> can gather, audio people feel ck may not be perfect for audio apps, but
> it's a good start.

Hi,
   I built ck-sources. Same xrun problem for me as the standard
gentoo-sources kernel.

Thanks,
Mark

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] kernel.org vs. Gentoo-64 bit kernels (xruns)

[Tres Melton]

On Mon, 2005-09-19 at 17:18 -0700, Mark Knecht wrote:

> This doesn't help me. I'm not a programmer - I'm a guitar player. I
> don't read ebuilds at all. Completely a foreign language to me...

Ebuilds are bash shell scripts actually.  There is a certain order that
functions are called and a set of default functions to call.  Any
functions that are in the ebuild are overloaded functions and perform
the same task but slightly differently.  The bash manual page should
help out here as well as the developers handbook here:
http://dev.gentoo.org/~plasmaroo/devmanual/

> I appreaciate the info a lot. Thanks!

No problem.

> Cheers,
> Mark
> 
-- 
Tres Melton
IRC & Gentoo: RiverRat

-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: kernel.org vs. Gentoo-64 bit kernels (xruns)

[Duncan]

Mark Knecht posted <5bdc1c8b05091914554f0c7360@mail.gmail.com>, excerpted
below,  on Mon, 19 Sep 2005 14:55:59 -0700:

> It seems right now that a simple emerge sync is causing xruns on this
> system implying to me some underlying problem with either hard drive
> activity or networking. since the hard drive is SATA and the networking
> option in the kernel marks the NIC driver as 'Reverse engineered -
> experimental' I'm not confident of fixing this problem in the immediate
> short term anyway.
> 
> My thoughts right now:
> 
> 1) kernel.org + rt patches
> 2) ck-sources
> 3) gentoo-sources-amd64 + rt patches not cleanly applied
> 
>    I may also investigate a different NIC. I have a email friend that
> runs a studio in Sydney. I helped him move from FC2 to Gentoo. We had
> xruns using some of the NIC stuff for his motherboard. When we found that
> was the problem he never had another problem.

I'm not familiar with the term "xrun", so this may be entirely off the
wall, but have you confirmed the hard drive is running DMA?  If your
chipset or SATA drivers are wrong, and your hard drive is having to run in
legacy interrupt mode instead of DMA mode, it *WILL* destroy latency and
generally make the system unusable for any sort of real-time work at all,
regardless of the other kernel patches applied.  So... in addition to
checking the network drivers, investigate the hard drive and chipset I/O
drivers as well, and confirm you ARE running DMA mode.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: kernel.org vs. Gentoo-64 bit kernels (xruns)

[Mark Knecht]

On 9/20/05, Duncan <1i5t5.duncan@cox.net> wrote:
> Mark Knecht posted <5bdc1c8b05091914554f0c7360@mail.gmail.com>, excerpted
> below,  on Mon, 19 Sep 2005 14:55:59 -0700:
> 
> > It seems right now that a simple emerge sync is causing xruns on this
> > system implying to me some underlying problem with either hard drive
> > activity or networking. since the hard drive is SATA and the networking
> > option in the kernel marks the NIC driver as 'Reverse engineered -
> > experimental' I'm not confident of fixing this problem in the immediate
> > short term anyway.
> >
> > My thoughts right now:
> >
> > 1) kernel.org + rt patches
> > 2) ck-sources
> > 3) gentoo-sources-amd64 + rt patches not cleanly applied
> >
> >    I may also investigate a different NIC. I have a email friend that
> > runs a studio in Sydney. I helped him move from FC2 to Gentoo. We had
> > xruns using some of the NIC stuff for his motherboard. When we found that
> > was the problem he never had another problem.
> 
> I'm not familiar with the term "xrun", so this may be entirely off the
> wall, but have you confirmed the hard drive is running DMA?  If your
> chipset or SATA drivers are wrong, and your hard drive is having to run in
> legacy interrupt mode instead of DMA mode, it *WILL* destroy latency and
> generally make the system unusable for any sort of real-time work at all,
> regardless of the other kernel patches applied.  So... in addition to
> checking the network drivers, investigate the hard drive and chipset I/O
> drivers as well, and confirm you ARE running DMA mode.
> 
Thanks, yes, DMA is running, as far as I can tell. hdparm -tT returns
numbers that are >50MB/S.

xruns are a term specific to the Jack server
(jack-audio-connection-kit) that tell us whether we've had and overrun
or an underrun. It's would be off topic to go deeply into how Jack
operates when talking to sound cards, but take it to mean something
bad has happened with real-time audio data.

Interestingly Jack runs from memory so hard drive performance should
not cause major problems unless it's not interruptable in a more or
less real-time way. On my Gentoo 32-bit machines (using Via and ATI
chipsets) I've not had to install any real-time patches and can still
run reliable at sub-2mS latencies. On those machines I can do pretty
much anything, browse the web with firefox, do and emerge sync, etc.,
and I get no xruns. On this AMD64/NForce4 machine and emerge sync
causes xruns immediately, indicating the sound card is getting starved
for data.

Anyway, thanks for the comments. DMA seems to be enabled on both the
hard drive and the CDRW and DVDRW drives.

Cheers,
Mark

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: kernel.org vs. Gentoo-64 bit kernels (xruns)

[Marco Matthies]

Mark Knecht wrote:
> xruns are a term specific to the Jack server
> (jack-audio-connection-kit) that tell us whether we've had and overrun
> or an underrun. It's would be off topic to go deeply into how Jack
> operates when talking to sound cards, but take it to mean something
> bad has happened with real-time audio data.

You might want to investigate Ingo Molnar's realtime patches [1] (in 
case you don't already know about them). They are apparently very good 
at keeping worst-case latencies very low. I tried an older version of 
that patchset (just used it for normal desktop stuff) and it seemed to 
work fine. I heard that people use it for audio stuff, but I don't do 
anything much with audio myself.

Marco

[1] http://people.redhat.com/mingo/realtime-preempt/
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: kernel.org vs. Gentoo-64 bit kernels (xruns)

[Marco Matthies]

Marco Matthies wrote:
> You might want to investigate Ingo Molnar's realtime patches [1] (in 
 > [snip]

Hi Mark,

apologies for not reading your other messages where you already said you 
had tried the rt-patches -- knowledge about them probably spread like 
wildfire in the audio community anyway, no need for me to spread old news...

Marco
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] kernel.org vs. Gentoo-64 bit kernels (xruns)

[Billy Holmes]

Mark Knecht wrote:
> Thanks. Yes, I've run ck-sources a few times in the past but not had

when you run with ck-sources, others have found it's best to use 
SCHED_ISO rather than SCHED_NORM (ck was patched with ISO support) - 
which is like real time scheduling for users processes. From what I hear 
it's easier to setup than the rt limits stuff (ie. it's automatic).
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] kernel.org vs. Gentoo-64 bit kernels (xruns)

[Daniel Gryniewicz]

On Tue, 2005-09-20 at 09:58 -0400, Billy Holmes wrote:
> Mark Knecht wrote:
> > Thanks. Yes, I've run ck-sources a few times in the past but not had
> 
> when you run with ck-sources, others have found it's best to use 
> SCHED_ISO rather than SCHED_NORM (ck was patched with ISO support) - 
> which is like real time scheduling for users processes. From what I hear 
> it's easier to setup than the rt limits stuff (ie. it's automatic).

Much more important is to run emerge as SCHED_BATCH.  I do this, and it
keeps emerge for effecting my interactivity (including skips in
audio/video) at all.
-- 
Daniel Gryniewicz
Gentoo AMD64 Team / Gentoo Gnome Herd / AMD64 Operational AT Lead

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] kernel.org vs. Gentoo-64 bit kernels (xruns)

[Mark Knecht]

On 9/20/05, Billy Holmes <billy@gonoph.net> wrote:
> Mark Knecht wrote:
> > Thanks. Yes, I've run ck-sources a few times in the past but not had
> 
> when you run with ck-sources, others have found it's best to use
> SCHED_ISO rather than SCHED_NORM (ck was patched with ISO support) -
> which is like real time scheduling for users processes. From what I hear
> it's easier to setup than the rt limits stuff (ie. it's automatic).
> --
> gentoo-amd64@gentoo.org mailing list
> 
> 
Billy,
   Hey, thanks for the tip. IT would be great to see this run better.

   I'm looking around in the kernel and haven't foudn SCHED_ISO vs.
SCHED_NORM. For the preemption model I chose 'Low Latency Desktop'. In
the .config file I see these entries:

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y

Am I supposed to choose one at the command line when booting? Or can I
change schedulers once the kernel is running, through /proc or
something?

If I cannot google something then I'll sign up for the ck list.

Thanks again to all who have answered. The info is helpful.

Cheers,
Mark

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] kernel.org vs. Gentoo-64 bit kernels (xruns)

[Mark Knecht]

On 9/20/05, Daniel Gryniewicz <dang@gentoo.org> wrote:
> On Tue, 2005-09-20 at 09:58 -0400, Billy Holmes wrote:
> > Mark Knecht wrote:
> > > Thanks. Yes, I've run ck-sources a few times in the past but not had
> >
> > when you run with ck-sources, others have found it's best to use
> > SCHED_ISO rather than SCHED_NORM (ck was patched with ISO support) -
> > which is like real time scheduling for users processes. From what I hear
> > it's easier to setup than the rt limits stuff (ie. it's automatic).
> 
> Much more important is to run emerge as SCHED_BATCH.  I do this, and it
> keeps emerge for effecting my interactivity (including skips in
> audio/video) at all.
> --
> Daniel Gryniewicz

Daniel,
   This makes sense but I've never heard of doing this before. How
does one run emerge as a SCHED_BATCH process?

   None the less, when recording in Ardour I'll be doing a reasonable
amount of disk I/O. Not so much bandwitch - probably never more than
5-10MB/S on large recordings, but still it's a large number of audio
files and therefore more disk seeking, etc., so I'll want the whole
disk subsystem working well.

Thanks,
Mark

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: kernel.org vs. Gentoo-64 bit kernels (xruns)

[Mark Knecht]

On 9/20/05, Marco Matthies <marco-ml@gmx.net> wrote:
> Marco Matthies wrote:
> > You might want to investigate Ingo Molnar's realtime patches [1] (in
>  > [snip]
> 
> Hi Mark,
> 
> apologies for not reading your other messages where you already said you
> had tried the rt-patches -- knowledge about them probably spread like
> wildfire in the audio community anyway, no need for me to spread old news...
> 
> Marco

Not a problem. Others may not know.

Yes, I've been running versions of them since back in the 2.4 days.
Ingo's work has been great, as has Con Kolivas's. What has amazed me,
however, is that since coming to Gentoo  and the Gentoo 2.6 kernels
I've not needed ANY patches to get great performance on my 32-bit
machines. I've been running the straight gentoo-sources at 5mS latency
or lower with no xruns. It's worked really well, at least for my
studio machines. I hope that one of these days soon I can do that with
my AMD64 machine also.

Chhers,
Mark

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] kernel.org vs. Gentoo-64 bit kernels (xruns)

[Billy Holmes]

Mark Knecht wrote:
>    None the less, when recording in Ardour I'll be doing a reasonable
> amount of disk I/O. Not so much bandwitch - probably never more than
> 5-10MB/S on large recordings, but still it's a large number of audio
> files and therefore more disk seeking, etc., so I'll want the whole
> disk subsystem working well.

you can control scheduling with

emerge schedtool

also, CFQ with the read IO patches appeared to have very good results 
and honored nice and scheduling priorities between multiple process reads.
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] kernel.org vs. Gentoo-64 bit kernels (xruns)

[Billy Holmes]

Mark Knecht wrote:
> If I cannot google something then I'll sign up for the ck list.

go ahead and sign up, you'll have about 10 answers and suggestions in 
about 30 minutes - and almost all the answers will be better informed 
than mine :)

I use ck-sources on all my desktop machines, plus a terminal server that 
has 15+ people using it. With mapped water mark, plus the new preswap 
patches, it makes this terminal server do wonders. People don't even 
realize that they are connected to a shared machine.

My usage is vastly different than you yours, but I feel ck has gone 
great strides toward the low latency desktop.
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] kernel.org vs. Gentoo-64 bit kernels (xruns)

[Daniel Gryniewicz]

On Tue, 2005-09-20 at 09:04 -0700, Mark Knecht wrote:
> On 9/20/05, Daniel Gryniewicz <dang@gentoo.org> wrote:
> > On Tue, 2005-09-20 at 09:58 -0400, Billy Holmes wrote:
> > > Mark Knecht wrote:
> > > > Thanks. Yes, I've run ck-sources a few times in the past but not had
> > >
> > > when you run with ck-sources, others have found it's best to use
> > > SCHED_ISO rather than SCHED_NORM (ck was patched with ISO support) -
> > > which is like real time scheduling for users processes. From what I hear
> > > it's easier to setup than the rt limits stuff (ie. it's automatic).
> > 
> > Much more important is to run emerge as SCHED_BATCH.  I do this, and it
> > keeps emerge for effecting my interactivity (including skips in
> > audio/video) at all.
> > --
> > Daniel Gryniewicz
> 
> Daniel,
>    This makes sense but I've never heard of doing this before. How
> does one run emerge as a SCHED_BATCH process?
> 
>    None the less, when recording in Ardour I'll be doing a reasonable
> amount of disk I/O. Not so much bandwitch - probably never more than
> 5-10MB/S on large recordings, but still it's a large number of audio
> files and therefore more disk seeking, etc., so I'll want the whole
> disk subsystem working well.
> 
> Thanks,
> Mark
> 

I do this:
alias emerge='sudo schedtool -B -e /usr/bin/emerge'

Obviously the sudo is unnecessary if you're root.  You can use similar
aliases to run things as SCHED_ISO, which I do for mplayer, for example.

Daniel

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: kernel.org vs. Gentoo-64 bit kernels (xruns)

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 2259 bytes --]

On Tuesday 20 September 2005 14:25, Mark Knecht wrote:
> On 9/20/05, Duncan <1i5t5.duncan@cox.net> wrote:
> > I'm not familiar with the term "xrun", so this may be entirely off the
> > wall, but have you confirmed the hard drive is running DMA?  If your
> > chipset or SATA drivers are wrong, and your hard drive is having to run
> > in legacy interrupt mode instead of DMA mode, it *WILL* destroy latency
> > and generally make the system unusable for any sort of real-time work at
> > all, regardless of the other kernel patches applied.  So... in addition
> > to checking the network drivers, investigate the hard drive and chipset
> > I/O drivers as well, and confirm you ARE running DMA mode.
>
> Thanks, yes, DMA is running, as far as I can tell. hdparm -tT returns
> numbers that are >50MB/S.
>
> xruns are a term specific to the Jack server
> (jack-audio-connection-kit) that tell us whether we've had and overrun
> or an underrun. It's would be off topic to go deeply into how Jack
> operates when talking to sound cards, but take it to mean something
> bad has happened with real-time audio data.

Nah, it's more alsa specific. What soundcard do you use? Some soundcards are 
more crappy than others (especially onboard ones). I guess it should support 
DMA as even the soundblaster pro did so. Soundcards do however provide 
various levels of hardware accelleration.

> Interestingly Jack runs from memory so hard drive performance should
> not cause major problems unless it's not interruptable in a more or
> less real-time way. On my Gentoo 32-bit machines (using Via and ATI
> chipsets) I've not had to install any real-time patches and can still
> run reliable at sub-2mS latencies. On those machines I can do pretty
> much anything, browse the web with firefox, do and emerge sync, etc.,
> and I get no xruns. On this AMD64/NForce4 machine and emerge sync
> causes xruns immediately, indicating the sound card is getting starved
> for data.

Good chance the soundcard buffer is smaller or the driver is crappy. You could 
try to take the soundcard from the old machine and put it in the new one.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-amd64] kernel.org vs. Gentoo-64 bit kernels (xruns)

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 563 bytes --]

On Tuesday 20 September 2005 19:47, Daniel Gryniewicz wrote:
>
> I do this:
> alias emerge='sudo schedtool -B -e /usr/bin/emerge'
>
> Obviously the sudo is unnecessary if you're root.  You can use similar
> aliases to run things as SCHED_ISO, which I do for mplayer, for example.

Or, more easilly, set the nicelevel to -19 (the lowest) which also amounts to 
batch scheduling. Nicelevel -19 is treated as batch by default by the 2.6 
kernel.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-amd64] kernel.org vs. Gentoo-64 bit kernels (xruns)

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1378 bytes --]

On Tuesday 20 September 2005 18:01, Mark Knecht wrote:
> On 9/20/05, Billy Holmes <billy@gonoph.net> wrote:
> > Mark Knecht wrote:
> > > Thanks. Yes, I've run ck-sources a few times in the past but not had
> >
> > when you run with ck-sources, others have found it's best to use
> > SCHED_ISO rather than SCHED_NORM (ck was patched with ISO support) -
> > which is like real time scheduling for users processes. From what I hear
> > it's easier to setup than the rt limits stuff (ie. it's automatic).
> > --
> > gentoo-amd64@gentoo.org mailing list
>
> Billy,
>    Hey, thanks for the tip. IT would be great to see this run better.
>
>    I'm looking around in the kernel and haven't foudn SCHED_ISO vs.
> SCHED_NORM. For the preemption model I chose 'Low Latency Desktop'. In
> the .config file I see these entries:
>
> #
> # IO Schedulers
> #
> CONFIG_IOSCHED_NOOP=y
> CONFIG_IOSCHED_AS=y
> CONFIG_IOSCHED_DEADLINE=y
> CONFIG_IOSCHED_CFQ=y
>
> Am I supposed to choose one at the command line when booting? Or can I
> change schedulers once the kernel is running, through /proc or
> something?

These ones are schedulers for harddisk (and other IO) access. As such they are 
not related to the task scheduling that SCHED_ISO is about.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-amd64] Re: kernel.org vs. Gentoo-64 bit kernels (xruns)

[Mark Knecht]

On 9/20/05, Paul de Vrieze <pauldv@gentoo.org> wrote:
> On Tuesday 20 September 2005 14:25, Mark Knecht wrote:
> > On 9/20/05, Duncan <1i5t5.duncan@cox.net> wrote:
> > > I'm not familiar with the term "xrun", so this may be entirely off the
> > > wall, but have you confirmed the hard drive is running DMA?  If your
> > > chipset or SATA drivers are wrong, and your hard drive is having to run
> > > in legacy interrupt mode instead of DMA mode, it *WILL* destroy latency
> > > and generally make the system unusable for any sort of real-time work at
> > > all, regardless of the other kernel patches applied.  So... in addition
> > > to checking the network drivers, investigate the hard drive and chipset
> > > I/O drivers as well, and confirm you ARE running DMA mode.
> >
> > Thanks, yes, DMA is running, as far as I can tell. hdparm -tT returns
> > numbers that are >50MB/S.
> >
> > xruns are a term specific to the Jack server
> > (jack-audio-connection-kit) that tell us whether we've had and overrun
> > or an underrun. It's would be off topic to go deeply into how Jack
> > operates when talking to sound cards, but take it to mean something
> > bad has happened with real-time audio data.
> 
> Nah, it's more alsa specific. What soundcard do you use? Some soundcards are
> more crappy than others (especially onboard ones). I guess it should support
> DMA as even the soundblaster pro did so. Soundcards do however provide
> various levels of hardware accelleration.

That's not the problem here. The card is an RME HDSP 9652. It ran in
my older Asus/Via/Athlon-XP/Gentoo-32-bit machine just fine. I've
built the new Asus/NForce4/Athlon64/Gentoo-64-bit machine and
transfered the same card of here so I know the card and drivers are
fine, at least in a 32-bit environment.
> 
> > Interestingly Jack runs from memory so hard drive performance should
> > not cause major problems unless it's not interruptable in a more or
> > less real-time way. On my Gentoo 32-bit machines (using Via and ATI
> > chipsets) I've not had to install any real-time patches and can still
> > run reliable at sub-2mS latencies. On those machines I can do pretty
> > much anything, browse the web with firefox, do and emerge sync, etc.,
> > and I get no xruns. On this AMD64/NForce4 machine and emerge sync
> > causes xruns immediately, indicating the sound card is getting starved
> > for data.
> 
> Good chance the soundcard buffer is smaller or the driver is crappy. You could
> try to take the soundcard from the old machine and put it in the new one.

As you can see, that's what I did! :-)

- Mark

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] kernel.org vs. Gentoo-64 bit kernels (xruns)

[Tres Melton]

On Tue, 2005-09-20 at 20:23 +0200, Paul de Vrieze wrote:
> On Tuesday 20 September 2005 19:47, Daniel Gryniewicz wrote:
> >
> > I do this:
> > alias emerge='sudo schedtool -B -e /usr/bin/emerge'
> >
> > Obviously the sudo is unnecessary if you're root.  You can use similar
> > aliases to run things as SCHED_ISO, which I do for mplayer, for example.
> 
> Or, more easilly, set the nicelevel to -19 (the lowest) which also amounts to 
> batch scheduling. Nicelevel -19 is treated as batch by default by the 2.6 
> kernel.

Erm, isn't that backwards?  The lowest priority is 20.  The highest is
-19.  You have to be root for any priority < 0.

> Paul
> 
-- 
Tres Melton
IRC & Gentoo: RiverRat

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] kernel.org vs. Gentoo-64 bit kernels (xruns)

[Matt Randolph]

Tres Melton wrote:

>On Tue, 2005-09-20 at 20:23 +0200, Paul de Vrieze wrote:
>  
>
>>On Tuesday 20 September 2005 19:47, Daniel Gryniewicz wrote:
>>    
>>
>>>I do this:
>>>alias emerge='sudo schedtool -B -e /usr/bin/emerge'
>>>
>>>Obviously the sudo is unnecessary if you're root.  You can use similar
>>>aliases to run things as SCHED_ISO, which I do for mplayer, for example.
>>>      
>>>
>>Or, more easilly, set the nicelevel to -19 (the lowest) which also amounts to 
>>batch scheduling. Nicelevel -19 is treated as batch by default by the 2.6 
>>kernel.
>>    
>>
>
>Erm, isn't that backwards?  The lowest priority is 20.  The highest is
>-19.  You have to be root for any priority < 0.
>
>  
>
>>Paul
>>
>>    
>>

I would guess that Paul used the word "lowest" in a strictly numerical 
sense, rather than priority-wise.  By the way, my nice has a range of 
-20 to 19.

Matt
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] kernel.org vs. Gentoo-64 bit kernels (xruns)

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1130 bytes --]

On Wednesday 21 September 2005 02:15, Matt Randolph wrote:
> Tres Melton wrote:
> >On Tue, 2005-09-20 at 20:23 +0200, Paul de Vrieze wrote:
> >>On Tuesday 20 September 2005 19:47, Daniel Gryniewicz wrote:
> >>>I do this:
> >>>alias emerge='sudo schedtool -B -e /usr/bin/emerge'
> >>>
> >>>Obviously the sudo is unnecessary if you're root.  You can use
> >>> similar aliases to run things as SCHED_ISO, which I do for mplayer,
> >>> for example.
> >>
> >>Or, more easilly, set the nicelevel to -19 (the lowest) which also
> >> amounts to batch scheduling. Nicelevel -19 is treated as batch by
> >> default by the 2.6 kernel.
> >
> >Erm, isn't that backwards?  The lowest priority is 20.  The highest is
> >-19.  You have to be root for any priority < 0.
> >
> >>Paul
>
> I would guess that Paul used the word "lowest" in a strictly numerical
> sense, rather than priority-wise.  By the way, my nice has a range of
> -20 to 19.

Nah, I made a mistake between -19 and 19. Of course it should be 19.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-amd64] kernel.org vs. Gentoo-64 bit kernels (xruns)

[Nicolas Sergent]

Mark Knecht a écrit :
> Hi,
>    Is there a simple document around that would tell me something
> about the differences between the Gentoo 64-bit kernel and the
> standard 2.6.13.2 kernel from kernel.org? I'm a audio user, live audio
> recording, etc., and use Jack all the time. My new AMD64 machine is
> giving me many xrun problems that I have not seen on other Gentoo
> machines running Gentoo kernels. However all previous Gentoo machines
> were 32-bit and here I'm running the 64-bit kernel.
> 
>    I'm considering building a kernel from kernel.org with the realtime
> patches applied which will probably fix things according to the
> Jack-audio developer folks. Unfortunately the  patch set for 2.6.13
> does not apply cleanly against the Gentoo 64-bit kernel source, so I'm
> wondering what I'd be missing by using the kernel.org kernel instead.
> 
>    I also need to determine if the problems are possibly because of
> this new NForce4 chipset but that may take awhile.
> 
>    Thanks in advance for any info you might provide.
> 
> Cheers,
> Mark
> 


Hi,

have you had a look at sys-apps/realtime-lsm ? ( http://www.joq.us )
I don't know if it's as performant as the rt-patches, but you can use 
this module with a gentoo-kernel.

Cheers

Khâpin

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] kernel.org vs. Gentoo-64 bit kernels (xruns)

[Mark Knecht]

On 9/21/05, Nicolas Sergent <khapin@wanadoo.fr> wrote:
>
> Hi,
>
> have you had a look at sys-apps/realtime-lsm ? ( http://www.joq.us )
> I don't know if it's as performant as the rt-patches, but you can use
> this module with a gentoo-kernel.
>
> Cheers
>
> Khâpin

Yes, thanks.I already run realtime-lsm. However that package doesn't
provide any performance improvements to the system. What it does is
allow a user to do things he'd normally need ot be root to do, such as
requestion realtime processing performance within Jack. As root you
can always do this. As a user you never can until

1) realtime-lsm is installed
2) There is a group created that is given lsm rights
3) The user is added to that group.

Eg:

mark@lightning ~ $ cat /etc/modules.autoload.d/kernel-2.6
<SNIP>
fglrx
snd-intel8x0
snd-hdsp
ohci1394
sbp2
realtime gid=600 any=1
mark@lightning ~ $

mark@lightning ~ $ cat /etc/group
<SNIP>
realtime:x:600:mark


Cheers,
Mark

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] kernel.org vs. Gentoo-64 bit kernels (xruns)

[John C. Shimek]

A few questions and comments.
Are you running the most current BOIS on your MB?  Have you checked your 
BOIS setting to see if any of that can help with realtime performance?  
Is all your hardware good? Checked memory, hard drives, motherboard, 
video card, NIC, anything else you might have.

I have no knowledge of realtime or audio things but I have seen several 
posts about bad hardware messing things up in weird unpredicted ways.  
You seem to know about most everything that has been suggested and if 
the software is not fixing, try the hardware.  Though I can't help a lot 
with diagnosing hardware problems, I know several on this list and other 
are great at it.

My 2 cents worth
JCS


Billy Holmes wrote:

> Mark Knecht wrote:
>
>> Thanks. Yes, I've run ck-sources a few times in the past but not had
>
>
> when you run with ck-sources, others have found it's best to use 
> SCHED_ISO rather than SCHED_NORM (ck was patched with ISO support) - 
> which is like real time scheduling for users processes. From what I 
> hear it's easier to setup than the rt limits stuff (ie. it's automatic).

-- 
gentoo-amd64@gentoo.org mailing list