[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
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 s
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
t
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
> fact
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 percentag
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),
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
> > probl
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
of
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 tri
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 PROTECTE
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 f
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
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 tuners.
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 co
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 indep
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 hardwar
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) ho
21 matches
Mail list logo
