Re: [LAD] cpu spikes

On Mon, 25 Jan 2016, Jörn Nettingsmeier wrote:

> sorry to hijack this thread, but: when enquiring about latency tuning, one
> frequently encounters hints like "disable cron", "disable indexing services",
> "disable this, disable that".
>
> however, none of those alleged culprits run with real-time privileges or
> access driver or kernel code which does. so how can they be a problem (and
> disabling them part of the solution)? i'm asking because i've got my own
> anecdotal evidence that it *does* make a difference...

Yes, the big thing is that I see xruns just before something pops up
saying "hey theres an upgrade available". Now as I have said, cron runs
super "nice" and so anything that cron runs should be really low priority
too. But time constraints are not just CPU access and time. I would think
that the network driver even using the bus for a full 1500 bytes should
not be a problem, but where does that data go? What priority is a disk
access... and once it starts how big a chunk of data gets written and is
it atomic? It does not seem to be memory related as I use half my memory
it seems even running a lot of stuff at the same time. My swap after weeks
of running is still 0%. (swappiness 10)

> i understand how device drivers can be nasty (graphics cards locking up the
> pci bus, wifi chips hogging the kernel for milliseconds at a time or

Actually I think with wifi chips it is the bus that gets hogged.

> worse...) but it seems that a) either kernel preemption and real-time
> scheduling is terribly buggy or hand-wavey, or b) we're feeding each other
> snake-oil in recommending to disable userspace things that is running without
> rt privs.

As you yourself can attest, it does make a difference. I would suggest
that there are some kernel drivers that are optimized for throughput over
latency that have not yet been accounted for. Or some other things that
are in their own way time constrained. Network traffic comes to mind.
Network traffic comes when it comes and can only be buffered in hardware
so long before packets get lost. However, as I said, even full packets are
relatively small. What is the biggest data chunk that gets written to
disk? Has anyone gone through kernel drivers looking for atomic parts that
could be shortened? Is there a setting for maximum data size of a disk
write/read? It appears there are ways to throttle disk access speed on a
per-proccess basis.

Another one that is puzzling is CPU speed changes (AKA OnDemand). These
happen very fast and should not cause trouble, but they do. It seems to
me, just by watching a cpu speed monitor, that xruns happen at the point
the cpu speed goes down only. Perhaps there is some timing loop somewhere
that gets expanded that should not. I would think any timing should be
done by timers that are not cpu speed dependant.

Honestly, these are just thoughts off the top of my head. I don't know the
kernel code well enough to say (Means I have not looked at it). I just
know that by turning certain things off, I can get lower latency without
xruns over a 24hour period. (even just sitting idle streaming zeros)

--
Len Ovens
www.ovenwerks.net

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Mon Jan 25 20:15:01 2016