.
uwaysi@Millennium:~/Kildekode/sched_deadline-schedtool-dl$ ./schedtool -E
-t 500:1000 3718
ERROR: could not set PID 3718 to E: SCHED_DEADLINE - Function not
implemented
uwaysi@Millennium:~/Kildekode/sched_deadline-schedtool-dl$
On Sun, 04 Nov 2012 20:02:25 +0100, Uwaysi Bin Kareem
wrote:
How does
uwaysi@Millennium:~/Kildekode/sched_deadline-schedtool-dl$ ./schedtool -E
-t 500:1000 3718
ERROR: could not set PID 3718 to E: SCHED_DEADLINE - Function not
implemented
uwaysi@Millennium:~/Kildekode/sched_deadline-schedtool-dl$
On Sun, 04 Nov 2012 20:02:25 +0100, Uwaysi Bin Kareem
wrote
How does the modified schedtool work? There is no updated documentation.
http://gitorious.org/sched_deadline/schedtool-dl/commits/latest/2.6.36-dl-V3
If anyone could give an example of a 1000uS period / 500uS time, with
schedtool, or any other relevant information.
Most examples online use
Hi. I am trying the Sched_deadline patch.
I am getting an error compiling:
kernel/sched/dl.c: In function ‘dl_runtime_exceeded’:
kernel/sched/dl.c:551:7: warning: unused variable ‘damount’
[-Wunused-variable]
kernel/sched/dl.c:558:7: warning: unused variable ‘ramount’
[-Wunused-variable]
On Fri, 05 Oct 2012 14:04:29 +0200, el es wrote:
Hello,
first of all, the posts that inspired me to write this up,
were from Uwaysi Bin Kareem (paradoxuncreated dot com).
Here is what I think:
could the source of graphic/video jitter as most people
perceive it, be something that could
Ok, anyway realtime processes did not work quite as expected.
("overloaded" machine, even though cpu-time is only 10%). So I guess I
have to enable cgroups and live with the overhead then.
If I set cpu-limits there, does that involve an absolute value, or is it
normalized, so that even if
Ok, anyway realtime processes did not work quite as expected.
(overloaded machine, even though cpu-time is only 10%). So I guess I
have to enable cgroups and live with the overhead then.
If I set cpu-limits there, does that involve an absolute value, or is it
normalized, so that even if I
On Fri, 05 Oct 2012 14:04:29 +0200, el es el.es...@gmail.com wrote:
Hello,
first of all, the posts that inspired me to write this up,
were from Uwaysi Bin Kareem (paradoxuncreated dot com).
Here is what I think:
could the source of graphic/video jitter as most people
perceive it, be something
Hi. I am trying the Sched_deadline patch.
I am getting an error compiling:
kernel/sched/dl.c: In function ‘dl_runtime_exceeded’:
kernel/sched/dl.c:551:7: warning: unused variable ‘damount’
[-Wunused-variable]
kernel/sched/dl.c:558:7: warning: unused variable ‘ramount’
[-Wunused-variable]
How does the modified schedtool work? There is no updated documentation.
http://gitorious.org/sched_deadline/schedtool-dl/commits/latest/2.6.36-dl-V3
If anyone could give an example of a 1000uS period / 500uS time, with
schedtool, or any other relevant information.
Most examples online use
uwaysi@Millennium:~/Kildekode/sched_deadline-schedtool-dl$ ./schedtool -E
-t 500:1000 3718
ERROR: could not set PID 3718 to E: SCHED_DEADLINE - Function not
implemented
uwaysi@Millennium:~/Kildekode/sched_deadline-schedtool-dl$
On Sun, 04 Nov 2012 20:02:25 +0100, Uwaysi Bin Kareem
.
uwaysi@Millennium:~/Kildekode/sched_deadline-schedtool-dl$ ./schedtool -E
-t 500:1000 3718
ERROR: could not set PID 3718 to E: SCHED_DEADLINE - Function not
implemented
uwaysi@Millennium:~/Kildekode/sched_deadline-schedtool-dl$
On Sun, 04 Nov 2012 20:02:25 +0100, Uwaysi Bin Kareem
uwaysi.bin.kar
--- Forwarded message ---
From: "Uwaysi Bin Kareem"
To: "Mike Galbraith"
Cc:
Subject: Re: Scheduler queues for less os-jitter?
Date: Sun, 04 Nov 2012 02:19:39 +0100
On Thu, 11 Oct 2012 04:46:34 +0200, Mike Galbraith wrote:
On Wed, 2012-10-10 at 20:13 +0200, Uwa
--- Forwarded message ---
From: Uwaysi Bin Kareem uwaysi.bin.kar...@paradoxuncreated.com
To: Mike Galbraith efa...@gmx.de
Cc:
Subject: Re: Scheduler queues for less os-jitter?
Date: Sun, 04 Nov 2012 02:19:39 +0100
On Thu, 11 Oct 2012 04:46:34 +0200, Mike Galbraith efa...@gmx.de wrote
On Tue, 23 Oct 2012 01:56:57 +0200, Uwaysi Bin Kareem
wrote:
As those who have seen my posts on LKML, I am all about jitter.
10 years ago I said why not do an OpenGL desktop, and now we have
wayland.
10 years ago, I said, don`t do excessive buffering, and now we have
"fig
On Tue, 23 Oct 2012 01:56:57 +0200, Uwaysi Bin Kareem
uwaysi.bin.kar...@paradoxuncreated.com wrote:
As those who have seen my posts on LKML, I am all about jitter.
10 years ago I said why not do an OpenGL desktop, and now we have
wayland.
10 years ago, I said, don`t do excessive buffering
As those who have seen my posts on LKML, I am all about jitter.
10 years ago I said why not do an OpenGL desktop, and now we have wayland.
10 years ago, I said, don`t do excessive buffering, and now we have
"fighting bufferbloat".
10 years ago, I talked about how responsive vintage computers
--- Forwarded message ---
From: "Uwaysi Bin Kareem"
To: "Thomas Gleixner"
Cc:
Subject: Re: [ANNOUNCE] 3.6.2-rt4
Date: Mon, 22 Oct 2012 18:08:20 +0200
I tried it. Just low-latency desktop, seems slighty of less jitter, than
mainline.
Unfortunately the problem of t
Hiya, I compiled the kernel with V=1 and noticed "-mno-sse -mno-mmx
-mno-sse2 -mno-3dnow -mno-avx". Is there a way to turn this on? Alt, in
what file is this string, so I can try without it.
Peace Be With You.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
Hiya, I compiled the kernel with V=1 and noticed -mno-sse -mno-mmx
-mno-sse2 -mno-3dnow -mno-avx. Is there a way to turn this on? Alt, in
what file is this string, so I can try without it.
Peace Be With You.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
--- Forwarded message ---
From: Uwaysi Bin Kareem uwaysi.bin.kar...@paradoxuncreated.com
To: Thomas Gleixner t...@linutronix.de
Cc:
Subject: Re: [ANNOUNCE] 3.6.2-rt4
Date: Mon, 22 Oct 2012 18:08:20 +0200
I tried it. Just low-latency desktop, seems slighty of less jitter, than
mainline
As those who have seen my posts on LKML, I am all about jitter.
10 years ago I said why not do an OpenGL desktop, and now we have wayland.
10 years ago, I said, don`t do excessive buffering, and now we have
fighting bufferbloat.
10 years ago, I talked about how responsive vintage computers was,
Not many are discussing this.
So odd since an overloaded computer, looks like a computer with jitter. So
removing jitter = higher performance.
I changed X to nice -20 though instead. It is hard to predict jitter, and
maybe some measure of fairness is good.
Still daemons wouldn`t mind
Not many are discussing this.
So odd since an overloaded computer, looks like a computer with jitter. So
removing jitter = higher performance.
I changed X to nice -20 though instead. It is hard to predict jitter, and
maybe some measure of fairness is good.
Still daemons wouldn`t mind
Hi.
I have made a little script, optimizing Ubuntu abit. If you have any good
and relevant information, reasonable arguments, please post them.
Do note this script is something I have quickly made, and can probably be
improved. Feedback from experienced desktop-optimizers is appreciated. The
Hi.
I have made a little script, optimizing Ubuntu abit. If you have any good
and relevant information, reasonable arguments, please post them.
Do note this script is something I have quickly made, and can probably be
improved. Feedback from experienced desktop-optimizers is appreciated. The
Ok, I just learned that X was singlethreaded. Setting it to realtime fifo,
pri 98, fixes slowing down doom 3 (which I use for testing), when moving
other windows, as that is probably due to waiting for X.
Now I wonder should RCU priority boost be at 99, or below X? Probably
above right?
Ok, I just learned that X was singlethreaded. Setting it to realtime fifo,
pri 98, fixes slowing down doom 3 (which I use for testing), when moving
other windows, as that is probably due to waiting for X.
Now I wonder should RCU priority boost be at 99, or below X? Probably
above right?
http://www.phoronix.com/scan.php?page=news_item=MTIwNzM
While Phoronix usually miss the point of these configs, these benchmarks
still show that low-jitter on the desktop, does not affect desktop
performance negatively.
Only if you are running Apache, on a server, you`d want a different
http://www.phoronix.com/scan.php?page=news_itempx=MTIwNzM
While Phoronix usually miss the point of these configs, these benchmarks
still show that low-jitter on the desktop, does not affect desktop
performance negatively.
Only if you are running Apache, on a server, you`d want a different
I was just wondering, have you considered this?
If daemons are contributing to os-jitter, wouldn`t having them all on
their own queue reduce jitter? So people could have the stuff like in
Ubuntu they want, without affecting jitter, or needing stuff like Tiny
Core, for tiny jitter?
So you
I was just wondering, have you considered this?
If daemons are contributing to os-jitter, wouldn`t having them all on
their own queue reduce jitter? So people could have the stuff like in
Ubuntu they want, without affecting jitter, or needing stuff like Tiny
Core, for tiny jitter?
So you
Threadirqs still not working here (and never did). Email me if you want to
sort it out.
Peace Be With You.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
I also compiled a 3.6.1 with a local shave (only components I want) + my
low jitter config and tweaks. (most notably 90hz timer, which is where
many go wrong.)
Quake 2, with software renderer, in wine, went from 15/30 fps, to 60fps
with some jitter, with full distro low-jitter kernel, to perfect
I also compiled a 3.6.1 with a local shave (only components I want) + my
low jitter config and tweaks. (most notably 90hz timer, which is where
many go wrong.)
Quake 2, with software renderer, in wine, went from 15/30 fps, to 60fps
with some jitter, with full distro low-jitter kernel, to perfect
Threadirqs still not working here (and never did). Email me if you want to
sort it out.
Peace Be With You.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at
out game-performance. Some of the
GUI in doom3, running completely smooth, shows some great potential for
GUI-ideas aswell :)
Peace Be With You.
On Sat, 06 Oct 2012 16:53:16 +0200, el_es wrote:
Uwaysi Bin Kareem paradoxuncreated.com> writes:
[sorry for cutting out the context],
for latency, you try to finish everything as soon as you
can. Since some things take longer than others, jitter increases.
David Lang
On Sat, 6 Oct 2012, Uwaysi Bin Kareem wrote:
Reducing jitter seems central for many things.
First of all keypresses seem faster. (less jitter = less latency).
Doom 3
On Fri, 05 Oct 2012 23:29:23 +0200, wrote:
On Sun, 30 Sep 2012 14:54:07 +0200, Uwaysi Bin Kareem said:
Compiled 3.6-rc7, with a hz timer of 3956 for a "natural" psychovisual
profile jitter level in OpenGL, and a shaved config for minimal jitter.
I'll bite - how did y
On Fri, 05 Oct 2012 23:29:23 +0200, valdis.kletni...@vt.edu wrote:
On Sun, 30 Sep 2012 14:54:07 +0200, Uwaysi Bin Kareem said:
Compiled 3.6-rc7, with a hz timer of 3956 for a natural psychovisual
profile jitter level in OpenGL, and a shaved config for minimal jitter.
I'll bite - how did you
optimize for latency, you try to finish everything as soon as you
can. Since some things take longer than others, jitter increases.
David Lang
On Sat, 6 Oct 2012, Uwaysi Bin Kareem wrote:
Reducing jitter seems central for many things.
First of all keypresses seem faster. (less jitter = less
of the
GUI in doom3, running completely smooth, shows some great potential for
GUI-ideas aswell :)
Peace Be With You.
On Sat, 06 Oct 2012 16:53:16 +0200, el_es el.es...@gmail.com wrote:
Uwaysi Bin Kareem uwaysi.bin.kareem at paradoxuncreated.com writes:
[sorry for cutting out the context
Reducing jitter seems central for many things.
First of all keypresses seem faster. (less jitter = less latency).
Doom 3 and similar jittersensitive OpenGL applications run smoothly, and
better than windows. Doom 3 was also my main app to get running well, and
measuring jitter in the
Ok I have gained a bit more information on this now. Apparently, the
filter is there, for HPC loads to exclude scheduler activity itself from
the scheduler?
Filtering all the processes for this, seems completely unessecary though.
Depending on what resolution these filters run at, you have
Ok I have gained a bit more information on this now. Apparently, the
filter is there, for HPC loads to exclude scheduler activity itself from
the scheduler?
Filtering all the processes for this, seems completely unessecary though.
Depending on what resolution these filters run at, you have
Reducing jitter seems central for many things.
First of all keypresses seem faster. (less jitter = less latency).
Doom 3 and similar jittersensitive OpenGL applications run smoothly, and
better than windows. Doom 3 was also my main app to get running well, and
measuring jitter in the
Hiya, does anyone have RME Fireface UCX in Classcompliant USB-mode,
working?
Peace Be With You.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hiya, does anyone have RME Fireface UCX in Classcompliant USB-mode,
working?
Peace Be With You.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
At 100hz, shaved kernel, for lowest jitter, and maximal performance, and
the following hardwirings in fair.c
unsigned int sysctl_sched_min_granularity = 1158500ULL;
unsigned int normalized_sysctl_sched_min_granularity = 1158500ULL;
unsigned int __read_mostly sysctl_sched_shares_window = 0UL;
Ok at 100hz, granularity seems to work as expected. Actually 1000hz for
desktop seems to be a myth. I have less jitter with 100hz. Very nice. I
think jitter is 99.99% eliminated from doom 3 now.
Peace Be With You!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Ok at 100hz, granularity seems to work as expected. Actually 1000hz for
desktop seems to be a myth. I have less jitter with 100hz. Very nice. I
think jitter is 99.99% eliminated from doom 3 now.
Peace Be With You!
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
At 100hz, shaved kernel, for lowest jitter, and maximal performance, and
the following hardwirings in fair.c
unsigned int sysctl_sched_min_granularity = 1158500ULL;
unsigned int normalized_sysctl_sched_min_granularity = 1158500ULL;
unsigned int __read_mostly sysctl_sched_shares_window = 0UL;
The 10 ms averager is not the only strange thing. Obviously there are some
good things in this scheduler, since it performs quite well. But I am not
criticising the good.
But the documentation makes a distinction between desktop and server with
the "resolution" parameter.
I tried some
On Tue, 02 Oct 2012 13:22:53 +0200, Mike Galbraith wrote:
On Tue, 2012-10-02 at 10:07 +0200, Uwaysi Bin Kareem wrote:
On Tue, 02 Oct 2012 11:19:15 +0200, Mike Galbraith
wrote:
> On Tue, 2012-10-02 at 08:56 +0200, Uwaysi Bin Kareem wrote:
>
>> What you can do for the time being
On Tue, 02 Oct 2012 11:19:15 +0200, Mike Galbraith wrote:
On Tue, 2012-10-02 at 08:56 +0200, Uwaysi Bin Kareem wrote:
What you can do for the time being is just set it to 1nS. If that
doesn`t
negatively impact anything, then you know it is bogus.
I already know that there is negative
This is just too much code for me to do a quick patch on. It really needs
to be evaulated with concerns to what an optimal scheduler is. That would
be to operate on actual system load ofcourse, not a filtered system load
that doesn`t represent what is actually happening on a computer.
What
odd. You don`t even know the average before
5ms.
I am going to look at the code, and see if I can make a patch.
Peace Be With You.
On Tue, 02 Oct 2012 04:50:02 +0200, Mike Galbraith wrote:
On Mon, 2012-10-01 at 15:24 +0200, Uwaysi Bin Kareem wrote:
Are you sure this isn`t just a design
odd. You don`t even know the average before
5ms.
I am going to look at the code, and see if I can make a patch.
Peace Be With You.
On Tue, 02 Oct 2012 04:50:02 +0200, Mike Galbraith efa...@gmx.de wrote:
On Mon, 2012-10-01 at 15:24 +0200, Uwaysi Bin Kareem wrote:
Are you sure this isn`t
This is just too much code for me to do a quick patch on. It really needs
to be evaulated with concerns to what an optimal scheduler is. That would
be to operate on actual system load ofcourse, not a filtered system load
that doesn`t represent what is actually happening on a computer.
What
On Tue, 02 Oct 2012 11:19:15 +0200, Mike Galbraith efa...@gmx.de wrote:
On Tue, 2012-10-02 at 08:56 +0200, Uwaysi Bin Kareem wrote:
What you can do for the time being is just set it to 1nS. If that
doesn`t
negatively impact anything, then you know it is bogus.
I already know
On Tue, 02 Oct 2012 13:22:53 +0200, Mike Galbraith efa...@gmx.de wrote:
On Tue, 2012-10-02 at 10:07 +0200, Uwaysi Bin Kareem wrote:
On Tue, 02 Oct 2012 11:19:15 +0200, Mike Galbraith efa...@gmx.de
wrote:
On Tue, 2012-10-02 at 08:56 +0200, Uwaysi Bin Kareem wrote:
What you can do
The 10 ms averager is not the only strange thing. Obviously there are some
good things in this scheduler, since it performs quite well. But I am not
criticising the good.
But the documentation makes a distinction between desktop and server with
the resolution parameter.
I tried some values
On Mon, 01 Oct 2012 06:06:37 +0200, Mike Galbraith wrote:
On Sun, 2012-09-30 at 13:44 +0200, Uwaysi Bin Kareem wrote:
Hiya. I just had an initial look at fair.c
There seems to be a 10ms averager in there?
You are aware that that means you work on delayed values?
Isn`t that counterintuitive
On Mon, 01 Oct 2012 06:06:37 +0200, Mike Galbraith efa...@gmx.de wrote:
On Sun, 2012-09-30 at 13:44 +0200, Uwaysi Bin Kareem wrote:
Hiya. I just had an initial look at fair.c
There seems to be a 10ms averager in there?
You are aware that that means you work on delayed values?
Isn`t
is the filtered spike, much lower, but it lasts long beyond the
100uS spike. (10ms). Why would that be used in something that should
represent cpu-usage?
Peace Be With You.
On Sun, 30 Sep 2012 13:44:14 +0200, Uwaysi Bin Kareem
wrote:
Hiya. I just had an initial look at fair.c
There seems
Compiled 3.6-rc7, with a hz timer of 3956 for a "natural" psychovisual
profile jitter level in OpenGL, and a shaved config for minimal jitter.
Also changed the 10ms filter in fair.c to 1. And I suggest the whole
filter to be removed. https://lkml.org/lkml/2012/9/30/78
There is very few clicks
Compiled 3.6-rc7, with a hz timer of 3956 for a "natural" psychovisual
profile jitter level in OpenGL, and a shaved config for minimal jitter.
Also changed the 10ms filter in fair.c to 1. And I suggest the whole
filter to be removed. https://lkml.org/lkml/2012/9/30/78
There is very few
I also did a quick hack changing some of those values, giving
non-interrputed audiostream with audioapp alone, at 0.7ms. (on a core2duo
@ 2.5ghz)
That is actually better than BFS.
Peace Be With You.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Hiya. I just had an initial look at fair.c
There seems to be a 10ms averager in there?
You are aware that that means you work on delayed values?
Isn`t that counterintuitive to the principle of sharing?
That means short bursts of cpu-use will be filtered out, and given less
cpu time.
Hiya. I just had an initial look at fair.c
There seems to be a 10ms averager in there?
You are aware that that means you work on delayed values?
Isn`t that counterintuitive to the principle of sharing?
That means short bursts of cpu-use will be filtered out, and given less
cpu time.
I also did a quick hack changing some of those values, giving
non-interrputed audiostream with audioapp alone, at 0.7ms. (on a core2duo
@ 2.5ghz)
That is actually better than BFS.
Peace Be With You.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
Compiled 3.6-rc7, with a hz timer of 3956 for a natural psychovisual
profile jitter level in OpenGL, and a shaved config for minimal jitter.
Also changed the 10ms filter in fair.c to 1. And I suggest the whole
filter to be removed. https://lkml.org/lkml/2012/9/30/78
There is very few
Compiled 3.6-rc7, with a hz timer of 3956 for a natural psychovisual
profile jitter level in OpenGL, and a shaved config for minimal jitter.
Also changed the 10ms filter in fair.c to 1. And I suggest the whole
filter to be removed. https://lkml.org/lkml/2012/9/30/78
There is very few clicks
is the filtered spike, much lower, but it lasts long beyond the
100uS spike. (10ms). Why would that be used in something that should
represent cpu-usage?
Peace Be With You.
On Sun, 30 Sep 2012 13:44:14 +0200, Uwaysi Bin Kareem
uwaysi.bin.kar...@paradoxuncreated.com wrote:
Hiya. I just had an initial
Hiya, I sendt this to the ubuntu suggestions box. I am emailing a copy
here aswell.
---
Mark Shuttleworth has talked about "ultrasmooth" gaming, desktop etc. You
can have that now already, or atleast quite close. Games will be perfect.
Webanims and videoes will depend on syncing code or
Hiya, I sendt this to the ubuntu suggestions box. I am emailing a copy
here aswell.
---
Mark Shuttleworth has talked about ultrasmooth gaming, desktop etc. You
can have that now already, or atleast quite close. Games will be perfect.
Webanims and videoes will depend on syncing code or
in the thread
though, but quite common.
Please also read my response to this:
http://phoronix.com/forums/showthread.php?71741-A-Low-Latency-Kernel-For-Linux-Gaming=284229#post284229
Peace Be With You.
On Fri, 31 Aug 2012 00:50:28 +0200, Uwaysi Bin Kareem
wrote:
I have done some research
in the thread
though, but quite common.
Please also read my response to this:
http://phoronix.com/forums/showthread.php?71741-A-Low-Latency-Kernel-For-Linux-Gamingp=284229#post284229
Peace Be With You.
On Fri, 31 Aug 2012 00:50:28 +0200, Uwaysi Bin Kareem
uwaysi.bin.kar...@paradoxuncreated.com
I have done some research on latency. I have config`d a linux kernel to
run 0.3ms reliable latency with audiostreams, under normal worksituations.
(An audioapp, and maybe some small tasks in between).
This also resulted in an extremely smooth gameplaying experience, like an
asm-programmed
I have done some research on latency. I have config`d a linux kernel to
run 0.3ms reliable latency with audiostreams, under normal worksituations.
(An audioapp, and maybe some small tasks in between).
This also resulted in an extremely smooth gameplaying experience, like an
asm-programmed
. (Although
Win 7 has some security policies that reduce performance gains that come
through priority elevation somewhat.)
SoundMan and Richmond are key words that will lead you to it via Google.
{^_^}
On 2012/08/28 12:01, Uwaysi Bin Kareem wrote:
Some may remember me as commenting
Some may remember me as commenting on the excellent state of the
linux-kernel, after I achieved 0.3ms reliable latency for audio-streams.
I have now decided to try and get as close as possible on Windows XP
though. However some of the drivers on my windows XP install, is from
2001. Windows
Some may remember me as commenting on the excellent state of the
linux-kernel, after I achieved 0.3ms reliable latency for audio-streams.
I have now decided to try and get as close as possible on Windows XP
though. However some of the drivers on my windows XP install, is from
2001. Windows
for quite some time now. (Although
Win 7 has some security policies that reduce performance gains that come
through priority elevation somewhat.)
SoundMan and Richmond are key words that will lead you to it via Google.
{^_^}
On 2012/08/28 12:01, Uwaysi Bin Kareem wrote:
Some may remember me
84 matches
Mail list logo
