[EMAIL PROTECTED] wrote:
Quoting Bill Davidsen <[EMAIL PROTECTED]>:
Disk tests should be at a fixed rate, not all you can do. That's NOT
realistic.
Not true; what you suggest is another thing to check entirely, and that
would
be a valid benchmark too. What I'm
[EMAIL PROTECTED] wrote:
Quoting Bill Davidsen [EMAIL PROTECTED]:
Disk tests should be at a fixed rate, not all you can do. That's NOT
realistic.
Not true; what you suggest is another thing to check entirely, and that
would
be a valid benchmark too. What I'm
On Thu, 2005-07-14 at 09:57 +1000, Con Kolivas wrote:
> On Thu, 14 Jul 2005 03:34, Lee Revell wrote:
> > On Wed, 2005-07-13 at 13:27 +0200, szonyi calin wrote:
> > > I have the following problem with audio:
> > > Xmms is running with threads for audio and spectrum
> > > analyzer(OpenGL).
> > > The
On Thu, 2005-07-14 at 09:57 +1000, Con Kolivas wrote:
On Thu, 14 Jul 2005 03:34, Lee Revell wrote:
On Wed, 2005-07-13 at 13:27 +0200, szonyi calin wrote:
I have the following problem with audio:
Xmms is running with threads for audio and spectrum
analyzer(OpenGL).
The audio eats 5%
Quoting Bill Davidsen <[EMAIL PROTECTED]>:
> Con Kolivas wrote:
>
> >On Thu, 14 Jul 2005 03:54, Bill Davidsen wrote:
> >
> >
> >>Con Kolivas wrote:
> >>
> >>
> >>>On Tue, 12 Jul 2005 21:57, David Lang wrote:
> >>>
> >>>
> for audio and video this would seem to be a fairly simple
Con Kolivas wrote:
On Thu, 14 Jul 2005 03:54, Bill Davidsen wrote:
Con Kolivas wrote:
On Tue, 12 Jul 2005 21:57, David Lang wrote:
for audio and video this would seem to be a fairly simple scaleing factor
(or just doing a fixed amount of work rather then a fixed percentage of
Con Kolivas wrote:
On Thu, 14 Jul 2005 03:54, Bill Davidsen wrote:
Con Kolivas wrote:
On Tue, 12 Jul 2005 21:57, David Lang wrote:
for audio and video this would seem to be a fairly simple scaleing factor
(or just doing a fixed amount of work rather then a fixed percentage of
Quoting Bill Davidsen [EMAIL PROTECTED]:
Con Kolivas wrote:
On Thu, 14 Jul 2005 03:54, Bill Davidsen wrote:
Con Kolivas wrote:
On Tue, 12 Jul 2005 21:57, David Lang wrote:
for audio and video this would seem to be a fairly simple scaleing
factor
(or just doing a
On Thu, 14 Jul 2005 10:46, Con Kolivas wrote:
> On Thu, 14 Jul 2005 10:31, David Lang wrote:
> > On Thu, 14 Jul 2005, Con Kolivas wrote:
> > > On Thu, 14 Jul 2005 03:54, Bill Davidsen wrote:
> > >> Con Kolivas wrote:
> > >>> On Tue, 12 Jul 2005 21:57, David Lang wrote:
> > for audio and video
On Thu, 14 Jul 2005 10:31, David Lang wrote:
> On Thu, 14 Jul 2005, Con Kolivas wrote:
> > On Thu, 14 Jul 2005 03:54, Bill Davidsen wrote:
> >> Con Kolivas wrote:
> >>> On Tue, 12 Jul 2005 21:57, David Lang wrote:
> for audio and video this would seem to be a fairly simple scaleing
>
On Thu, 14 Jul 2005, Con Kolivas wrote:
On Thu, 14 Jul 2005 03:54, Bill Davidsen wrote:
Con Kolivas wrote:
On Tue, 12 Jul 2005 21:57, David Lang wrote:
for audio and video this would seem to be a fairly simple scaleing factor
(or just doing a fixed amount of work rather then a fixed
On Thu, 14 Jul 2005 03:54, Bill Davidsen wrote:
> Con Kolivas wrote:
> > On Tue, 12 Jul 2005 21:57, David Lang wrote:
> >>for audio and video this would seem to be a fairly simple scaleing factor
> >>(or just doing a fixed amount of work rather then a fixed percentage of
> >>the CPU worth of
On Thu, 14 Jul 2005 03:34, Lee Revell wrote:
> On Wed, 2005-07-13 at 13:27 +0200, szonyi calin wrote:
> > I have the following problem with audio:
> > Xmms is running with threads for audio and spectrum
> > analyzer(OpenGL).
> > The audio eats 5% cpu, the spectrum analyzer about 80 %. The
> >
Con Kolivas wrote:
On Tue, 12 Jul 2005 21:57, David Lang wrote:
this looks very interesting, however one thing that looks odd to me in
this is the thought of comparing the results for significantly different
hardware.
for some of the loads you really are going to be independant of the speed
On Wed, 2005-07-13 at 13:27 +0200, szonyi calin wrote:
> I have the following problem with audio:
> Xmms is running with threads for audio and spectrum
> analyzer(OpenGL).
> The audio eats 5% cpu, the spectrum analyzer about 80 %. The
> problem is that sometimes the spectrum analyzer is eating all
--- Con Kolivas <[EMAIL PROTECTED]> a écrit :
> Interbench - The Linux Interactivity Benchmark v0.20
>
> http://interbench.kolivas.org
>
> direct download link:
> http://ck.kolivas.org/apps/interbench/interbench-0.20.tar.bz2
>
>
[snip]
> Audio:
> Audio is simulated as a thread that
--- Con Kolivas [EMAIL PROTECTED] a écrit :
Interbench - The Linux Interactivity Benchmark v0.20
http://interbench.kolivas.org
direct download link:
http://ck.kolivas.org/apps/interbench/interbench-0.20.tar.bz2
[snip]
Audio:
Audio is simulated as a thread that tries to run
On Wed, 2005-07-13 at 13:27 +0200, szonyi calin wrote:
I have the following problem with audio:
Xmms is running with threads for audio and spectrum
analyzer(OpenGL).
The audio eats 5% cpu, the spectrum analyzer about 80 %. The
problem is that sometimes the spectrum analyzer is eating all of
Con Kolivas wrote:
On Tue, 12 Jul 2005 21:57, David Lang wrote:
this looks very interesting, however one thing that looks odd to me in
this is the thought of comparing the results for significantly different
hardware.
for some of the loads you really are going to be independant of the speed
On Thu, 14 Jul 2005 03:34, Lee Revell wrote:
On Wed, 2005-07-13 at 13:27 +0200, szonyi calin wrote:
I have the following problem with audio:
Xmms is running with threads for audio and spectrum
analyzer(OpenGL).
The audio eats 5% cpu, the spectrum analyzer about 80 %. The
problem is that
On Thu, 14 Jul 2005 03:54, Bill Davidsen wrote:
Con Kolivas wrote:
On Tue, 12 Jul 2005 21:57, David Lang wrote:
for audio and video this would seem to be a fairly simple scaleing factor
(or just doing a fixed amount of work rather then a fixed percentage of
the CPU worth of work), however
On Thu, 14 Jul 2005, Con Kolivas wrote:
On Thu, 14 Jul 2005 03:54, Bill Davidsen wrote:
Con Kolivas wrote:
On Tue, 12 Jul 2005 21:57, David Lang wrote:
for audio and video this would seem to be a fairly simple scaleing factor
(or just doing a fixed amount of work rather then a fixed
On Thu, 14 Jul 2005 10:31, David Lang wrote:
On Thu, 14 Jul 2005, Con Kolivas wrote:
On Thu, 14 Jul 2005 03:54, Bill Davidsen wrote:
Con Kolivas wrote:
On Tue, 12 Jul 2005 21:57, David Lang wrote:
for audio and video this would seem to be a fairly simple scaleing
factor (or just doing a
On Thu, 14 Jul 2005 10:46, Con Kolivas wrote:
On Thu, 14 Jul 2005 10:31, David Lang wrote:
On Thu, 14 Jul 2005, Con Kolivas wrote:
On Thu, 14 Jul 2005 03:54, Bill Davidsen wrote:
Con Kolivas wrote:
On Tue, 12 Jul 2005 21:57, David Lang wrote:
for audio and video this would seem to
On Tue, 12 Jul 2005, Con Kolivas wrote:
> It runs a real time high priority timing thread that wakes up the thread
Nice, but why is it threaded?
Forking would be more realistic!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
On Wed, 13 Jul 2005 06:55, Al Boldi wrote:
> On Tue, 12 Jul 2005, Con Kolivas wrote:
> > It runs a real time high priority timing thread that wakes up the thread
>
> Nice, but why is it threaded?
Because I'm an amateur, and I had to start somewhere.
> Forking would be more realistic!
Something
On Tue, 2005-07-12 at 10:55 -0700, David Lang wrote:
> On Tue, 12 Jul 2005, Lee Revell wrote:
>
> > On Tue, 2005-07-12 at 05:17 -0700, David Lang wrote:
> >> for example a series 1 DirectTv tivo manages to write two program
> >> streams to disk while reading and viewing a third
> >
> > Actually
On Tue, 12 Jul 2005, Lee Revell wrote:
On Tue, 2005-07-12 at 05:17 -0700, David Lang wrote:
for example a series 1 DirectTv tivo manages to write two program
streams to disk while reading and viewing a third
Actually it writes two streams to disk while reading and viewing one of
them, unless
On Tue, 2005-07-12 at 05:17 -0700, David Lang wrote:
> for example a series 1 DirectTv tivo manages to write two program
> streams to disk while reading and viewing a third
Actually it writes two streams to disk while reading and viewing one of
them, unless they released a model with three
On Tue, 12 Jul 2005 22:17, David Lang wrote:
> which brings up another possible config option/test case, changing the
> read/write tests to try to do X MB/sec rather then the max possible speed
> (probably defaulting to max if nothing is specified)
That's a good idea. I was planning on adding a
On Tue, 12 Jul 2005, Con Kolivas wrote:
On Tue, 12 Jul 2005 21:57, David Lang wrote:
this looks very interesting, however one thing that looks odd to me in
this is the thought of comparing the results for significantly different
hardware.
for some of the loads you really are going to be
On Tue, 12 Jul 2005 21:57, David Lang wrote:
> this looks very interesting, however one thing that looks odd to me in
> this is the thought of comparing the results for significantly different
> hardware.
>
> for some of the loads you really are going to be independant of the speed
> of the
this looks very interesting, however one thing that looks odd to me in
this is the thought of comparing the results for significantly different
hardware.
for some of the loads you really are going to be independant of the speed
of the hardware (burn, compile, etc will use whatever you have)
Interbench - The Linux Interactivity Benchmark v0.20
http://interbench.kolivas.org
direct download link:
http://ck.kolivas.org/apps/interbench/interbench-0.20.tar.bz2
Introduction
This benchmark application is designed to benchmark interactivity in Linux.
On Wed, 13 Jul 2005 06:55, Al Boldi wrote:
On Tue, 12 Jul 2005, Con Kolivas wrote:
It runs a real time high priority timing thread that wakes up the thread
Nice, but why is it threaded?
Because I'm an amateur, and I had to start somewhere.
Forking would be more realistic!
Something for
On Tue, 12 Jul 2005, Con Kolivas wrote:
It runs a real time high priority timing thread that wakes up the thread
Nice, but why is it threaded?
Forking would be more realistic!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
Interbench - The Linux Interactivity Benchmark v0.20
http://interbench.kolivas.org
direct download link:
http://ck.kolivas.org/apps/interbench/interbench-0.20.tar.bz2
Introduction
This benchmark application is designed to benchmark interactivity in Linux.
this looks very interesting, however one thing that looks odd to me in
this is the thought of comparing the results for significantly different
hardware.
for some of the loads you really are going to be independant of the speed
of the hardware (burn, compile, etc will use whatever you have)
On Tue, 12 Jul 2005 21:57, David Lang wrote:
this looks very interesting, however one thing that looks odd to me in
this is the thought of comparing the results for significantly different
hardware.
for some of the loads you really are going to be independant of the speed
of the hardware
On Tue, 12 Jul 2005, Con Kolivas wrote:
On Tue, 12 Jul 2005 21:57, David Lang wrote:
this looks very interesting, however one thing that looks odd to me in
this is the thought of comparing the results for significantly different
hardware.
for some of the loads you really are going to be
On Tue, 12 Jul 2005 22:17, David Lang wrote:
which brings up another possible config option/test case, changing the
read/write tests to try to do X MB/sec rather then the max possible speed
(probably defaulting to max if nothing is specified)
That's a good idea. I was planning on adding a
On Tue, 2005-07-12 at 05:17 -0700, David Lang wrote:
for example a series 1 DirectTv tivo manages to write two program
streams to disk while reading and viewing a third
Actually it writes two streams to disk while reading and viewing one of
them, unless they released a model with three
On Tue, 12 Jul 2005, Lee Revell wrote:
On Tue, 2005-07-12 at 05:17 -0700, David Lang wrote:
for example a series 1 DirectTv tivo manages to write two program
streams to disk while reading and viewing a third
Actually it writes two streams to disk while reading and viewing one of
them, unless
On Tue, 2005-07-12 at 10:55 -0700, David Lang wrote:
On Tue, 12 Jul 2005, Lee Revell wrote:
On Tue, 2005-07-12 at 05:17 -0700, David Lang wrote:
for example a series 1 DirectTv tivo manages to write two program
streams to disk while reading and viewing a third
Actually it writes two
44 matches
Mail list logo
