29 Aug
2014
29 Aug
'14
1:40 a.m.
Hello all.
I hope this isn't too rambling a post to get some replies...
I have seen on this list multiple times lately (possibly by the same person, but never
corrected) a statement similar to thus:
"I chose an i5 over an i7 as the i5 doesn't have Hyperthreading whereas the i7
does."
I always thought I remembered this as wrong, especially as I believed I was running a 2
core i5 in my laptop and it shows up as 4 cores. I have just confirmed this to be the
case. But it is partially correct, so if anybody has been taking this information for
recommendation towards a new CPU purchase this appears to be a clearer picture of the
situation.
"The quick explanation is that all Core i7 CPUs use Hyper-Threading, so a six-core
CPU can handle 12 streams, a four-core can handle eight streams, and a dual-core can
handle four streams. Core i5 uses Hyper-Threading to make a dual-core CPU act like a
four-core one, but if you have a Core i5 processor with four true cores, it won't have
Hyper-Threading. For the time being, Core i5 tops out at handling four streams, using four
real cores or two cores with Hyper-Threading."[1]
As I say, Hyperthreading definitely "works" on my i5 and did with 12.04 as well
as 14.04. Whether it helps or hinders I have no idea! I do know that the current
Hyperthreading technology has nothing, or very little, to do with the Hyperthrading of the
old P4 CPUs and most of the comments I read on it when the processors first came out seem
to assume they were the same beast. I also know on Doze systems having it enabled on an i7
gave massive performance boosts with audio software, whereas on the old P4 performance was
better with HT disabled (at least initially.)
So can anybody point to any conclusive evidence that i-series processors benefit from
having HT disabled on a Linux based DAW? Preferably benchmarks on a system installed with
HT Enabled and Disabled using a recent kernel and system.
There are also other BIOS settings I would like some recommendation on how to set. Also
how much difference does it make it functions are turned on in BIOS and then Disabled
later? I would imaging the other way around would cause more difficulties (as maybe the
relevant parts of the kernel wouldn't be installed?) but have definitely read
recommendations to make sure to set up BIOS first.
The items in question are:
Intel SpeedStep
CPU Management
Intel Hyper-Threading (mentioned above.)
Also: Are there any good resources on setting up an Arch DAW system? I have been reading
as much as possible on the Arch Wiki as I can while we have power and internet here
(really not much just lately! About 2 hours the whole of today!!)
Some offline documentation would be very useful, so I can read when the internet is down!
http://archaudio.org seems to be dead in the water! Was it superseded?
Plus these couple of articles I found but admit yet to read as been concentrating on the
general Wiki.
http://www.linux.com/learn/tutorials/607117-build-a-serious-multimedia-prod…
https://wiki.archlinux.org/index.php/Pro_Audio
Anything else you can point me to I would be very thankful. I believe Arch is the next
step I wan to take. :)
Also starting to feel a little disenfranchised with XFCE. What are you guys running your
Arch DAW with?
Thanks for any pointers. :)
[1] http://www.pcmag.com/article2/0,2817,2404675,00.asp
29 Aug
29 Aug
7:40 a.m.
On Thu, 28 Aug 2014, Kaza Kore wrote:
I have seen on this list multiple times lately
(possibly by the same person, but
never corrected) a statement similar to thus:
"I chose an i5 over an i7 as the i5 doesn't have Hyperthreading whereas the i7
does."
I always thought I remembered this as wrong, especially as I believed I was
running a 2 core i5 in my laptop and it shows up as 4 cores. I have just
That is correct. I had forgotten that there was a model of i5 with two
cores and that one has hyperthreading to make up for it. As I was buying
MB and processor separate, I looked through Intel's spec list to make sure
I got one without hyperthreading. I was hopping not to pay for "Boost
Technology" as well, but the only higher end cpu that can be had without
boost is the xeon (some of them anyway).
"The quick explanation is that all Core i7 CPUs
use Hyper-Threading, so a
six-core CPU can handle 12 streams, a four-core can handle eight streams, and a
dual-core can handle four streams. Core i5 uses Hyper-Threading to make a
dual-core CPU act like a four-core one, but if you have a Core i5 processor with
four true cores, it won't have Hyper-Threading. For the time being, Core i5 tops
out at handling four streams, using four real cores or two cores with
Hyper-Threading."[1]
Yes that is correct. Thank you for pointing that out. As always, this list
is a good start, but one's own research is important too.
As I say, Hyperthreading definitely "works"
on my i5 and did with 12.04 as well
as 14.04. Whether it helps or hinders I have no idea! I do know that the current
Hyperthreading technology has nothing, or very little, to do with the
Hyperthrading of the old P4 CPUs and most of the comments I read on it when the
processors first came out seem to assume they were the same beast. I also know on
Doze systems having it enabled on an i7 gave massive performance boosts with
audio software, whereas on the old P4 performance was better with HT disabled (at
least initially.)
Performance is an interesting word, hyperthreading has always helped
performance, even audio performance if you are talking about CPU
throughput. In jackd terms, even on the single core P4, audio was pretty
solid down to about -p64, then xruns. With hyperthreading off -p16 with no
xruns was possible. However, overall performance was less too.
So can anybody point to any conclusive evidence that
i-series processors benefit
from having HT disabled on a Linux based DAW? Preferably benchmarks on a system
installed with HT Enabled and Disabled using a recent kernel and system.
That does sound interesting. There is a site that tests lowlatency
performance of a number of machines with RT kernels. Here is one for an i3
with hyperthreading:
https://www.osadl.org/Profile-of-system-in-rack-0-slot-0.qa-profile-r0s0.0.…
It looks very good, so your comment about the difference between old
hyperthreading and new may be right. (the highest latency in the plot is
34us with cycle test) How these test relate to real world audio use I
don't know. At the top of the above page there is access to the rest of
the rack slots with different machines that might be there.
There are also other BIOS settings I would like some
recommendation on how to
set. Also how much difference does it make it functions are turned on in BIOS and
then Disabled later? I would imaging the other way around would cause more
difficulties (as maybe the relevant parts of the kernel wouldn't be installed?)
but have definitely read recommendations to make sure to set up BIOS first.
The items in question are:
Intel SpeedStep
Even with the i5, a few months old, setting the CPU to performance over
ondemand seems to make a difference. Ondemand pretty much means 10ms for
no xrun latency. Ondemand changes cpu speed in such a way that the OS is
aware of the cpu speed and can control that speed. Letting the CPU decide
on it's own can't be better. This is why I turn boost technology off. -p16
is about .6ms at 48k sample rate and seems to be very stable. In fact
setting CPU governor to userspace and fixing cpu frequency to 800 MHz
seems to be more stable than with on demand. (tested on both the i5 and an atom
netbook)
CPU Management
Not sure what you mean by that. SMIs? Any time the OS doesn't know what
the CPU is doing, RT latency suffers. Intel agrees turning them off
improves low latency, but they also say that in some cases this voids
warranty...
Intel Hyper-Threading (mentioned above.)
I don't know that the physical technology matters so much as the OS being
hyperthreading aware and treating each pair of cores like one. That is
making sure that core 0 does not do anything that takes too long for core
1 to meet it's dead line. I do not know if new Linux kernels do this,
older ones did not. They logged that the chip had hyperthreading, but
still seemed to treat two threads as two different cores.
Certainly, common wisdom has not kept up with tech changes. I would be
nice to know more.
--
Len Ovens
www.ovenwerks.net
10:33 a.m.
On 29/08/14 15:40, Len Ovens wrote:
I don't know that the physical technology matters so much as the OS being
hyperthreading aware and treating each pair of cores like one. That is making
sure that core 0 does not do anything that takes too long for core 1 to meet
it's dead line. I do not know if new Linux kernels do this, older ones did not.
They logged that the chip had hyperthreading, but still seemed to treat two
threads as two different cores.
Certainly, common wisdom has not kept up with tech changes. I would be nice to
know more.
Not quite on topic, since this isn't to do with Hyper-threading, but certainly
the Linux scheduler has been getting much more sophisticated in dealing with
different kinds of cores ... in ARM it now schedules tasks for chips with some
smaller cores and some faster ones, keeping them busy with suitable sized tasks.
The ARM kernels running the most recent Samsung tablets (with 4 big plus 4
little cores) have this GTS in the 3.14 kernels ... it runs all 8 cores together
assigning tasks appropriate to each, rather than just switching between big or
little of each pair to save power. Selling hardware on that scale certainly
brings a budget, and since the kernel is GPL it can't be kept in-house.
Seems that 3.14 has also added a deadline-based scheduler that is closer to what
audio needs from realtime than the extremely low latency preemption based on
priorities that the two older realtime schedulers offer.
http://www.linuxfoundation.org/news-media/blogs/browse/2014/01/deadline-sch…
Simon
11:47 a.m.
On Fri, Aug 29, 2014 at 06:33:43PM +1000, Simon Wise wrote:
Seems that 3.14 has also added a deadline-based
scheduler that is
closer to what audio needs from realtime than the extremely low
latency preemption based on priorities that the two older realtime
schedulers offer.
http://www.linuxfoundation.org/news-media/blogs/browse/2014/01/deadline-sch…
Not really.
I went to a workshop on this some weeks ago, with presentations
by the author(s) of this deadline scheduler.
I presented a short intro to Jack, what it does and how and why,
with the aim to enable a discussion on if the deadline scheduler
would be a good solution for running a dynamic set of audio apps.
The conclusion was that (apart from some specific uses in e.g.
drivers) it was not designed to solve this type of problem, and
it would quite difficult to use it in such a context.
The new scheduler is designed to run a set of periodic tasks,
with arbitrary periods and having few or no dependencies between
them, at up to 100% CPU usage, while meeting their deadlines.
Rate-proportional scheduling (shorter period -> higher priority)
can only do this up to 69% CPU use, except in some special cases
such as all periods being equal or having simple integer ratios
between them.
The situation with a set of audio apps running under Jack (or
something similar) is very different: the order in which they
have to run depends on their connections.
Another problem with the deadline scheduler as implemented is
that you can not overcommit CPU use. If P_i is the period of
task 'i' and T_i its running time, then Sum_i { T_i / P_i }
must be smaller than the number of CPUs available to the
scheduler. This is enforced by the API, where T_i, P_i and
D_i (the relative deadline) are parameters. If a task ever
tries to take more than its T_i, it will be interrupted and
have to wait until its CPU budget is updated, which will be
after a time P_i.
In fact, having tasks pre-empted like this is a very normal
way to use the scheduler. The idea is that each task should
get a defined share T_i of time in each period P_i, and meet
its deadline which is relative to the instant it becomes
runnable.
If on the other hand a task has to finish a defined amount
of work in each period (e.g process a period of audio because
others depend on the output), then its configured T_i must be
the absolute worst case time it could ever take to do that.
So to make this work with audio processes you need to *know*
their running time, and if these times are variable you must
use the worst case one. Which means that CPU use will be well
below 100%.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
4:28 p.m.
On 29/08/14 19:47, Fons Adriaensen wrote:
On Fri, Aug 29, 2014 at 06:33:43PM +1000, Simon Wise
wrote:
that's interesting, it seemed promising at first ... so this is for being
certain that particular and predictable sized tasks will get scheduled in time
for their own individual deadlines, and I guess finding out immediately that
something can't be guaranteed ... while most audio tasks need to be done as soon
as possible since they are of less predictable duration, are inter-dependant and
all work together towards essentially the same deadline ... so the challenge in
multi core machines with a set of audio tasks taking most of the available
processing is scheduling the tasks with the most depending on them earliest,
hence putting tasks on queues with various priorities makes a lot more sense.
Seems that 3.14 has also added a deadline-based
scheduler that is
closer to what audio needs from realtime than the extremely low
latency preemption based on priorities that the two older realtime
schedulers offer.
http://www.linuxfoundation.org/news-media/blogs/browse/2014/01/deadline-sch…
Not really.
I went to a workshop on this some weeks ago, with presentations
by the author(s) of this deadline scheduler.
I presented a short intro to Jack, what it does and how and why,
with the aim to enable a discussion on if the deadline scheduler
would be a good solution for running a dynamic set of audio apps.
The conclusion was that (apart from some specific uses in e.g.
drivers) it was not designed to solve this type of problem, and
it would quite difficult to use it in such a context.
The new scheduler is designed to run a set of periodic tasks,
with arbitrary periods and having few or no dependencies between
them, at up to 100% CPU usage, while meeting their deadlines.
Rate-proportional scheduling (shorter period -> higher priority)
can only do this up to 69% CPU use, except in some special cases
such as all periods being equal or having simple integer ratios
between them.
The situation with a set of audio apps running under Jack (or
something similar) is very different: the order in which they
have to run depends on their connections.
Another problem with the deadline scheduler as implemented is
that you can not overcommit CPU use. If P_i is the period of
task 'i' and T_i its running time, then Sum_i { T_i / P_i }
must be smaller than the number of CPUs available to the
scheduler. This is enforced by the API, where T_i, P_i and
D_i (the relative deadline) are parameters. If a task ever
tries to take more than its T_i, it will be interrupted and
have to wait until its CPU budget is updated, which will be
after a time P_i.
so it is probably very useful if you need to be certain of tasks completing and
perhaps change strategies early to avoid missing deadlines, but that isn't what
audio needs.
In fact, having tasks pre-empted like this is a very normal
way to use the scheduler. The idea is that each task should
get a defined share T_i of time in each period P_i, and meet
its deadline which is relative to the instant it becomes
runnable.
If on the other hand a task has to finish a defined amount
of work in each period (e.g process a period of audio because
others depend on the output), then its configured T_i must be
the absolute worst case time it could ever take to do that.
So to make this work with audio processes you need to *know*
their running time, and if these times are variable you must
use the worst case one. Which means that CPU use will be well
below 100%.
thanks for that explanation
Simon
6:01 p.m.
On Sat, Aug 30, 2014 at 12:28:24AM +1000, Simon Wise wrote:
that's interesting, it seemed promising at first
... so this is for
being certain that particular and predictable sized tasks will get
scheduled in time for their own individual deadlines, and I guess
finding out immediately that something can't be guaranteed
Yes. On a single CPU machine, if the API accepts your parameters
(the condition involving the P_i and T_i is satisfied), then in
theory things should work up to 100% CPU. In practice a bit less,
due to implementation losses. The strange thing is that the same
algorithm can not provide the same guarantee on multi-CPU systems.
All it can do in that case is provide an upper bound on by how
much deadlines will be missed. There seems to be no solution for
this somewhat counter-intuitive result.
most audio tasks need to be done as soon as possible
since they are
of less predictable duration, are inter-dependant and all work
together towards essentially the same deadline ...
Yes, it's those dependencies and the fact that the whole set of tasks
has a common deadline instead of each an individual one which doesn't
fit into the scheme. It's really meant for e.g. servers which should
use a well defined percentage of the time for each of a number of tasks.
Meeting the deadlines is in fact not the end, but the means by which
this is achieved by the new scheduler.
in multi core machines with a set of audio tasks
taking most of the
available processing is scheduling the tasks with the most depending
on them earliest, hence putting tasks on queues with various
priorities makes a lot more sense.
The most common case in our world is all tasks having the same period.
Then you schedule them on their dependencies, and nothing else. The
exception would be algorithms such as used in zita-convolver in which
part (or even most of) the work is done in larger periods, which are
all an exact multiple (even power of 2) of Jack's one. Rate-monotonic
scheduling (giving the tasks with larger periods lower priority) works
very well in that case, up to full CPU usage, provided all app use the
same mapping from period size to priority.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
7:42 p.m.
On Fri, Aug 29, 2014 at 11:01 AM, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
I recently sat in on Karthik Poduval's thesis defense on the topic of
Jack scheduling with the hierarchical group scheduler (I hope you
don't mind the mention, Karthik). He showed great scheduling
efficiency for a real-time thread and reduced jitter.
Hardware locality and group scheduling looks like a great approach for
real-time audio and video--this approach could handle many of the
issues mentioned in this thread. For example, 1-2 ms is significant
for a real-time audio thread, but 16-17 ms is the important duration
for 60Hz video. One may need low latency, the other may need high
throughput. The solution is: 2 different schedulers in a hierarchy,
each handling different groups of processes. There can be any number
of schedulers in group hierarchical scheduling, so the system
processes could be handled by another (the first/original) scheduler
as well. HWLoc can add to this scheme, ensuring there's no contention
among different RT processes that operate on different time-scales (on
multi-core systems).
Aside from knowing this general scheme and principle, I'm ignorant of
the fine details of kernel schedulers. I may not be able to add much
more to this discussion (but I'll keep reading).
On Sat, Aug 30, 2014 at 12:28:24AM +1000, Simon Wise
wrote:
...
in multi core
machines with a set of audio tasks taking most of the
available processing is scheduling the tasks with the most depending
on them earliest, hence putting tasks on queues with various
priorities makes a lot more sense.
The most common case in our world is all tasks having the same period.
Then you schedule them on their dependencies, and nothing else. The
exception would be algorithms such as used in zita-convolver in which
part (or even most of) the work is done in larger periods, which are
all an exact multiple (even power of 2) of Jack's one. Rate-monotonic
scheduling (giving the tasks with larger periods lower priority) works
very well in that case, up to full CPU usage, provided all app use the
same mapping from period size to priority.
30 Aug
30 Aug
4:39 a.m.
On 30/08/14 02:01, Fons Adriaensen wrote:
On Sat, Aug 30, 2014 at 12:28:24AM +1000, Simon Wise
wrote:
while on a single core machine there isn't a problem with dependencies in DSP
either ... audio is easier ... there is enough time to finish it all, or there
isn't.
that's interesting, it seemed promising at
first ... so this is for
being certain that particular and predictable sized tasks will get
scheduled in time for their own individual deadlines, and I guess
finding out immediately that something can't be guaranteed
Yes. On a single CPU machine, if the API accepts your parameters
(the condition involving the P_i and T_i is satisfied), then in
theory things should work up to 100% CPU. In practice a bit less,
due to implementation losses. The strange thing is that the same
algorithm can not provide the same guarantee on multi-CPU systems.
All it can do in that case is provide an upper bound on by how
much deadlines will be missed. There seems to be no solution for
this somewhat counter-intuitive result.
Yes, it's those dependencies and the fact that the whole set of tasks
has a common deadline instead of each an individual one which doesn't
fit into the scheme. It's really meant for e.g. servers which should
use a well defined percentage of the time for each of a number of tasks.
Meeting the deadlines is in fact not the end, but the means by which
this is achieved by the new scheduler.
so multicore DSP scheduling is something like dependency based boot scheduling
... that has taken a lot of effort.
The most common case in our world is all tasks having the same period.
Then you schedule them on their dependencies, and nothing else. The
exception would be algorithms such as used in zita-convolver in which
part (or even most of) the work is done in larger periods, which are
all an exact multiple (even power of 2) of Jack's one. Rate-monotonic
scheduling (giving the tasks with larger periods lower priority) works
very well in that case, up to full CPU usage, provided all app use the
same mapping from period size to priority.
so a potential use for this scheduler in audio would be if we have a non-DSP
task which does not take a big part of the processing overall but that must keep
up to date, and should not be left to the last moment leaving it all in one
sample period potentially causing a DSP glitch.
Something like dealing with the control inputs or the feedback required to play
an instrument where responsiveness and lack of jitter are really important.
Then while the DSP threads are running with real-time priority we can still
guarantee an allocation of a steady but strictly limited amount of processing
time for the critical parts of perhaps midi or automation which is evenly spread
over the DSP periods. Maybe also making sure some particular aspects of the GUI
are always updated even when most of it slows down if the DSP load gets too high.
Simon
8:08 p.m.
On Friday, August 29, 2014 09:47:25 AM Fons Adriaensen wrote:
On Fri, Aug 29, 2014 at 06:33:43PM +1000, Simon Wise
wrote:
What about pinning a core (or cores) to audio processing? If the system is
truly being stressed to the point that it has become challenging for the
scheduler to keep up, wouldn't pinning make more sense?
-Reuben
Seems that 3.14 has also added a deadline-based
scheduler that is
closer to what audio needs from realtime than the extremely low
latency preemption based on priorities that the two older realtime
schedulers offer.
http://www.linuxfoundation.org/news-media/blogs/browse/2014/01/deadline-sc
heduling-314
Not really.
The new scheduler is designed to run a set of periodic tasks,
with arbitrary periods and having few or no dependencies between
them, at up to 100% CPU usage, while meeting their deadlines.
Rate-proportional scheduling (shorter period -> higher priority)
can only do this up to 69% CPU use, except in some special cases
such as all periods being equal or having simple integer ratios
between them.
29 Aug
29 Aug
2:54 p.m.
On Thu, 2014-08-28 at 22:40 -0700, Len Ovens wrote:
I now think this is CPU Power Management and turns off some levels such
as Sleep or Hibernate but I'm not positive...
Thanks, Dale.
Performance is an interesting word, hyperthreading has
always helped
performance, even audio performance if you are talking about CPU
throughput. In jackd terms, even on the single core P4, audio was pretty
solid down to about -p64, then xruns. With hyperthreading off -p16 with no
xruns was possible. However, overall performance was less too.
Have done some further reading, and although I can't say for definite it
sounds like support for modern hyperthreading mode is quite well
supported in Linux now and for general/desktop use. Seen one report that
it specifically caused problems with (some?) rt-kernels, but not with
generic. No mention of pre-empt. Another reporting that it increases
power but generally at the cost of latency.
I would be interested to know if it would allow you to play something in
your DAW that uses greater CPU power but at the cost of low loads
requiring a higher buffer setting within Jack. It does seem these days
it may be down to the question of whether minimum latency or maximum
available power is of most importance to you. (Although without some
real checks I'm only just postulating. If somebody wants to provide me
with a project file that will play on a default install of KXStudio
installed with it turned on and off.
Although that still begs the question of whether it being turned off in
BIOS/UFEI before or after installation actually makes any difference...
So can anybody point to any conclusive evidence
that i-series processors benefit
from having HT disabled on a Linux based DAW? Preferably benchmarks on a system
installed with HT Enabled and Disabled using a recent kernel and system.
That does sound interesting. There is a site that tests lowlatency
performance of a number of machines with RT kernels. Here is one for an i3
with hyperthreading:
https://www.osadl.org/Profile-of-system-in-rack-0-slot-0.qa-profile-r0s0.0.…
It looks very good, so your comment about the difference between old
hyperthreading and new may be right. (the highest latency in the plot is
34us with cycle test) How these test relate to real world audio use I
don't know. At the top of the above page there is access to the rest of
the rack slots with different machines that might be there. CPU Management
Not sure what you mean by that. SMIs? Any time the OS doesn't know what
the CPU is doing, RT latency suffers. Intel agrees turning them off
improves low latency, but they also say that in some cases this voids
warranty...
3:20 p.m.
New subject: NOW - UEFI
On Fri, 2014-08-29 at 18:39 +0545, dale wrote:
Although that still begs the question of whether it
being turned off in
BIOS/UFEI before or after installation actually makes any difference...
Now this is something that has been harder for me to get my head around
than benefit/disadvantages to HT!
When I got this laptop it had Window7 pre-installed with a bunch of
Lenovo software on it. At the time I know nothing of changes from BIOS
to UEFI! One of the first things I did was install Ubuntu Studio 12.04
on it, using Legacy mode as I wasn't sure if it was UEFI compatible and
my laptop seems to allow both.
This has caused various headaches I have kind learned to live with. Main
one being relating to screen brightness. If I set a low default screen
brightness in Windows then it seems to change the range of brightness
Linux can display. This was even more noticable when running LiveUSB
distros! I actually couldn't get the screen bright enough to see what I
was doing without setting the level within Windows bright again!
Then I read (or skimmed) this yesterday and feel even more confused.
https://wiki.archlinux.org/index.php/UEFI
But I am starting to think I should try enabling it with a Linux
install. Especially as I plan to completely banish Windows from the
computer now... But I thought I would ask what more experienced Linux
users have to say about UEFI mode vs BIOS/Legacy mode.
Again thanks for all the help. Dale.
6:45 p.m.
New subject: NOW - UEFI
On Fri, 29 Aug 2014, dale wrote:
This has caused various headaches I have kind learned
to live with. Main
one being relating to screen brightness. If I set a low default screen
brightness in Windows then it seems to change the range of brightness
Linux can display. This was even more noticable when running LiveUSB
distros! I actually couldn't get the screen bright enough to see what I
was doing without setting the level within Windows bright again!
Is there a setting in regular bios for screen brightness? EFI my leave
some variables around that the OS can continue to manipulat after boot...
wonderful :P
Then I read (or skimmed) this yesterday and feel even
more confused.
https://wiki.archlinux.org/index.php/UEFI
I see what you mean, every time I thought I was getting somewhere, I got
sent to yet another page. The most I got out of it was that EFI is intel's
answer to grub but with more control of the firware settings at the same
time. The old bios included calls to access some of the HW, but no one
used them as they were not muti-task/user friendly. It appears EFI does
the same thing and windows uses it and Linux does not know how to access
at least part of it. (or windows sets up its own calls within it)
But I am starting to think I should try enabling it
with a Linux
install. Especially as I plan to completely banish Windows from the
computer now... But I thought I would ask what more experienced Linux
users have to say about UEFI mode vs BIOS/Legacy mode.
You will get some I don't doubt... it may be hard to tell the truth from
FUD ;) EFI and Linux are still relatively new (3.10ish) and complaints
found in one kernel version may no longer be true.
--
Len Ovens
www.ovenwerks.net
7:24 p.m.
New subject: NOW - UEFI
On Fri, 29 Aug 2014, Len Ovens wrote:
I see what you mean, every time I thought I was
getting somewhere, I got sent
to yet another page. The most I got out of it was that EFI is intel's answer
to grub but with more control of the firware settings at the same time. The
old bios included calls to access some of the HW, but no one used them as
they were not muti-task/user friendly. It appears EFI does the same thing and
windows uses it and Linux does not know how to access at least part of it.
(or windows sets up its own calls within it)
What I forgot to add, is that it is obvious that a larger part of this
code sticks around and is still running after boot. At least with the bios
that didn't seem to be true. Some of this code may be called by SMIs and
of course the OS has less control of what is there. This code is not open
source and aside from security considerations (inteligent ethernet IFs
have that problem) RT performance may suffer.
I would suggest the xeon set of processors and MB may be more controlable
just because the server market demands it be so. Turning SMIs off on these
boards voids the warranty due to heat considerations, but my monitoring of
temperature while in performance mode with all cores at 100% use on my 4
core i5 has shown no problems. The temperature has remained well below the
point speed reduction would be indicated. In fact ondemand can make things
hotter, I found manually running one core at a lower speed actually
increased the temperature. There are a lot of different xeon models and it
is possible to get them with no HT or boost. I was thinking of getting
such a MB, but could find none with PCI slots. I do not know if they would
make better audio boards though. At the other end of the server market is
the atom MB which are good headless audio machines (the graphics part is
not linux friendly) using less power, cooling and being small besides.
Many of these MB have one PCI slot and there are "L" adaptors that allow
the card to use less space so an older (well supported) audio card could
be used.
--
Len Ovens
www.ovenwerks.net
30 Aug
30 Aug
7:24 a.m.
New subject: NOW - UEFI
On Fri, 2014-08-29 at 09:45 -0700, Len Ovens wrote:
I guess it must tie into ACPI somehow. Or would that be a silly
assumption? I believe ACPI controls hardware functions, including screen
brightness and fan controllers, while the system is running. Or am I
confused? I know on the rare occasions I've had a crash there have been
lots of ACPI Unknown (or similar) messages in my log! Did mean to look
into it further at some point...
On Fri, 29 Aug 2014, dale wrote:
No and I've looked again and again thinking it must be settable
elsewhere if it can be set from the Lenovo software/Windows and affect
all booted OSes.
This has caused various headaches I have kind
learned to live with. Main
one being relating to screen brightness. If I set a low default screen
brightness in Windows then it seems to change the range of brightness
Linux can display. This was even more noticable when running LiveUSB
distros! I actually couldn't get the screen bright enough to see what I
was doing without setting the level within Windows bright again!
Is there a setting in regular bios for screen brightness? EFI my leave
some variables around that the OS can continue to manipulat after boot...
wonderful :P
Then I read
(or skimmed) this yesterday and feel even more confused.
https://wiki.archlinux.org/index.php/UEFI
I see what you mean, every time I thought I was getting somewhere, I got
sent to yet another page. The most I got out of it was that EFI is intel's
answer to grub but with more control of the firware settings at the same
time. The old bios included calls to access some of the HW, but no one
used them as they were not muti-task/user friendly. It appears EFI does
the same thing and windows uses it and Linux does not know how to access
at least part of it. (or windows sets up its own calls within it)
But I am starting to think I should try enabling
it with a Linux
install. Especially as I plan to completely banish Windows from the
computer now... But I thought I would ask what more experienced Linux
users have to say about UEFI mode vs BIOS/Legacy mode.
You will get some I don't doubt... it may be hard to tell the truth from
FUD ;) EFI and Linux are still relatively new (3.10ish) and complaints
found in one kernel version may no longer be true.
--
Len Ovens
www.ovenwerks.net
10:21 a.m.
New subject: NOW - UEFI
On 08/29/2014 07:23 PM, dale wrote:
On Fri, 2014-08-29 at 09:45 -0700, Len Ovens wrote:
I guess it must tie into ACPI somehow. Or would that be a silly
assumption? I believe ACPI controls hardware functions, including screen
brightness and fan controllers, while the system is running. Or am I
confused? I know on the rare occasions I've had a crash there have been
lots of ACPI Unknown (or similar) messages in my log! Did mean to look
into it further at some point...
ACPI handles power-related things. It (or something proprietary) may
also handle things like the FN key functions on laptops, which include
brightening, dimming, switching display outputs, on/off/volume of built
in audio hardware, enabling touchpad, wireless, stuffs like that. Well,
actually, keyboard driver has to first recognize those keystrokes, then
the system has to carry out the correct command - which might require
triggering an ACPI event?
--
David W. Jones
gnome(a)hawaii.rr.com
authenticity, honesty, community
http://dancingtreefrog.com
On Fri, 29 Aug 2014, dale wrote:
No and I've looked again and again thinking it must be settable
elsewhere if it can be set from the Lenovo software/Windows and affect
all booted OSes.
This has caused various headaches I have kind
learned to live with. Main
one being relating to screen brightness. If I set a low default screen
brightness in Windows then it seems to change the range of brightness
Linux can display. This was even more noticable when running LiveUSB
distros! I actually couldn't get the screen bright enough to see what I
was doing without setting the level within Windows bright again!
Is there a setting in regular bios for screen brightness? EFI my leave
some variables around that the OS can continue to manipulat after boot...
wonderful :P
Then I
read (or skimmed) this yesterday and feel even more confused.
https://wiki.archlinux.org/index.php/UEFI
I see what you mean, every time I thought I was getting somewhere, I got
sent to yet another page. The most I got out of it was that EFI is intel's
answer to grub but with more control of the firware settings at the same
time. The old bios included calls to access some of the HW, but no one
used them as they were not muti-task/user friendly. It appears EFI does
the same thing and windows uses it and Linux does not know how to access
at least part of it. (or windows sets up its own calls within it)
But I am starting to think I should try enabling
it with a Linux
install. Especially as I plan to completely banish Windows from the
computer now... But I thought I would ask what more experienced Linux
users have to say about UEFI mode vs BIOS/Legacy mode.
You will get some I don't doubt... it may be hard to tell the truth from
FUD ;) EFI and Linux are still relatively new (3.10ish) and complaints
found in one kernel version may no longer be true.
--
Len Ovens
www.ovenwerks.net
29 Aug
29 Aug
10:15 p.m.
New subject: NOW - UEFI
On 08/29/2014 03:20 AM, dale wrote:
On Fri, 2014-08-29 at 18:39 +0545, dale wrote:
Hmm, found this page at the Ubuntu Community about Ubuntu and UEFI.
Apparently it can be installed in SecureBoot mode. I don't know what
other distros can. I have Debian Sid on 2 machines here with EUFI, but
both are in BIOS/Legacy mode.
--
David W. Jones
gnome(a)hawaii.rr.com
authenticity, honesty, community
http://dancingtreefrog.com
Although that still begs the question of whether
it being turned off in
BIOS/UFEI before or after installation actually makes any difference...
Now this is something that has been harder for me to get my head around
than benefit/disadvantages to HT!
When I got this laptop it had Window7 pre-installed with a bunch of
Lenovo software on it. At the time I know nothing of changes from BIOS
to UEFI! One of the first things I did was install Ubuntu Studio 12.04
on it, using Legacy mode as I wasn't sure if it was UEFI compatible and
my laptop seems to allow both.
This has caused various headaches I have kind learned to live with. Main
one being relating to screen brightness. If I set a low default screen
brightness in Windows then it seems to change the range of brightness
Linux can display. This was even more noticable when running LiveUSB
distros! I actually couldn't get the screen bright enough to see what I
was doing without setting the level within Windows bright again!
Then I read (or skimmed) this yesterday and feel even more confused.
https://wiki.archlinux.org/index.php/UEFI
But I am starting to think I should try enabling it with a Linux
install. Especially as I plan to completely banish Windows from the
computer now... But I thought I would ask what more experienced Linux
users have to say about UEFI mode vs BIOS/Legacy mode.
Again thanks for all the help. Dale.
30 Aug
30 Aug
7:30 a.m.
New subject: NOW - UEFI
On Fri, 2014-08-29 at 10:15 -1000, david wrote:
Hmm, found this page at the Ubuntu Community about Ubuntu and UEFI.
Apparently it can be installed in SecureBoot mode. I don't know what
other distros can. I have Debian Sid on 2 machines here with EUFI, but
both are in BIOS/Legacy mode.
I haven't looked in probably over a year but from what I remember at the
time it seemed only Canonical (Ubuntu) and Red Hat Foundation were going
to get the keys required for Secure Boot.
On my laptop I have Secure Boot but it is disabled and separate to the
UEFI option.
Should probably have mentioned at the beginning it's a Lenovo X230,
although most of my questions are of the more general kind.
Dale.
10:17 a.m.
New subject: NOW - UEFI
On 08/29/2014 07:29 PM, dale wrote:
On Fri, 2014-08-29 at 10:15 -1000, david wrote:
Thanks for clarification, both my System76 laptop and ASUS-based desktop
have SecureBoot disabled. The System76 came with Ubuntu 14 installed.
Hmm, found this page at the Ubuntu Community about Ubuntu and UEFI.
Apparently it can be installed in SecureBoot mode. I don't know what
other distros can. I have Debian Sid on 2 machines here with EUFI, but
both are in BIOS/Legacy mode.
I haven't looked in probably over a year but from what I remember at the
time it seemed only Canonical (Ubuntu) and Red Hat Foundation were going
to get the keys required for Secure Boot. On my laptop I have Secure Boot but it is disabled and
separate to the
UEFI option.
Should probably have mentioned at the beginning it's a Lenovo X230,
although most of my questions are of the more general kind.
Personally, I sometimes think the NSA is behind EUFI. What better place
to hide your spyware than built into the firmware? Then, of course,
someone realized that China, maker of most laptops and computers in
world, could be doing the same thing ... ;)
--
David W. Jones
gnome(a)hawaii.rr.com
authenticity, honesty, community
http://dancingtreefrog.com
29 Aug
29 Aug
5:38 p.m.
On Fri, 29 Aug 2014, dale wrote:
Although that still begs the question of whether it
being turned off in
BIOS/UFEI before or after installation actually makes any difference...
(hyperthreading) can be turned off after boot by telling the kernel not to
use either odd or even numbered Cores. I do not think doing it in the bios
is better or more effective as the idea is to make sure one thread does
not interfere with another. The only difference I could see is that it may
be that the bios switch may remove power from the secondary thread parts
of the chip for cooler running, but I do not know.
It should be possible to turn off the use of cores on the fly so that one
could have a low latency record session with less performance and a higher
latency mixdown with more performance (or video processing/editing).
I am just thinking that the P4 I gave to my son still has HT turned off, I
should turn it back on.
--
Len Ovens
www.ovenwerks.net
5:37 p.m.
On Thu, 28 Aug 2014 23:40:01 +0000
Kaza Kore <dj_kaza(a)hotmail.com> wrote:
So can anybody point to any conclusive evidence that
i-series
processors benefit from having HT disabled on a Linux based DAW?
Preferably benchmarks on a system installed with HT Enabled and
Disabled using a recent kernel and system.
Afaik there are 2 points to be made.
1. SMT (at least as implemented on iX cpus) break the entire concept
of realtime. You do get an estimated increase in CPU throughput of
about 25%, at the cost of stealing CPU time from your SCHED_FIFO/RR
thread. What it in effect means is that a SCHED_NORMAL thread can run
on the sibling CPU stealing CPU time from your SCHED_FIFO/RR thread.
2. I suspect that the CPU instruction cache is too small. and that
SMT can also cause cache depletion, which would explain some xruns I
have seen while torture testing the system doing real audio and
running hackbench at the same time.
Speedstep was already covered by someone else.
CPU management is a thorny question. That setting is probably
related to System Management Interrupts (SMIs), which can be very bad
indeed. Normally used for fan control and other functions by the
BIOS. The really bad thing is that they block execution and there is
nothing the kernel can do about it. if it's only for a few usecs,
it's probably insignificant and not a problem, but if it's
milliseconds, then you will get xruns...
There is a program called hwlatdetect in the rt-tests package that can
be used to determine how big the problem is. It consists of a kernel
module and a python script to start it and to report the results back
to the user. What is it does is basically to stop all kernel execution
and then to loop reading TSC timestamps. If it finds breaks in the
data stream they will have been caused by SMIs.
--
Joakim
1 Sep
1 Sep
2:38 a.m.
On Thu, 28 Aug 2014 23:40:01 +0000
Kaza Kore <dj_kaza(a)hotmail.com> wrote:
So can anybody point to any conclusive evidence that
i-series
processors benefit from having HT disabled on a Linux based DAW?
Preferably benchmarks on a system installed with HT Enabled and
Disabled using a recent kernel and system.
I changed email address on this list about a week ago, and posted the
following msg, seems it's didn't get through so I'll send an improved
version :)
AFAIK there are 2 points to be considered.
1. SMT (at least as implemented on iX cpus) break the entire concept
of realtime. You do get an estimated increase in CPU throughput of
about 25%, at the possible cost of stealing CPU time (thus latency) from
your realtime threads. In effect a lower priority thread thread can
run on the sibling CPU (same core) stealing CPU time from your realtime
thread.
2. I suspect that the CPU cache is too small. and that SMT can also
cause cache depletion, which would explain some xruns I have seen while
torture testing the system doing real lowlatency audio and running
hackbench at the same time. Reloading the cache cam take significant
time.
Speedstep was already covered by someone else.
CPU management is a thorny question. That setting is probably
related to System Management Interrupts (SMIs), which can be very bad
indeed. Normally used for fan control and other functions by the
BIOS. The really bad thing is that they block execution and there is
nothing the kernel can do about it. if it's only for a few usecs,
it's probably not a problem, but if it's milliseconds, it is..
There is a program called hwlatdetect in the rt-tests package that can
be used to determine how big the problem is. It consists of a kernel
module and a python script to start it and to report the results back
to the user. What is it does is basically to stop all kernel execution
and then to loop reading TSC timestamps. If it finds breaks in the
data stream they will have been caused by SMIs.
--
Joakim
3:25 a.m.
On Mon, 1 Sep 2014, Joakim Hernberg wrote:
I changed email address on this list about a week ago,
and posted the
following msg, seems it's didn't get through so I'll send an improved
version :)
Do you mean this message?
http://lists.linuxaudio.org/pipermail/linux-audio-user/2014-August/098760.h…
I think it got there. I thought I saw it.
--
Len Ovens
www.ovenwerks.net
3527
days inactive
3531
days old
linux-audio-user@lists.linuxaudio.org
21 comments
9 participants
participants (9)
-
Charles Z Henry -
dale -
david -
Fons Adriaensen -
Joakim Hernberg -
Kaza Kore
-
Len Ovens -
Reuben Martin -
Simon Wise