Re: sched: SCHED_DEADLINE v6
Nobody knows? This is really obscure for an EDF patch. Making things a bit more accessible should be a priority. I think a lot of enthusiasts would like to have smooth control over stuff, without windows-jitter. If you can do a robot arm, jitter-free with this, then I am very interested. 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 parameters that are no longer supported. 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 Please read the FAQ at http://www.tux.org/lkml/
Re: sched: SCHED_DEADLINE v6
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 parameters that are no longer supported. 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 Please read the FAQ at http://www.tux.org/lkml/
Re: sched: SCHED_DEADLINE v6
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 parameters that are no longer supported. 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 Please read the FAQ at http://www.tux.org/lkml/
re: sched: SCHED_DEADLINE v6
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] kernel/sched/dl.c: In function ‘init_sched_dl_class’: kernel/sched/dl.c:1521:6: error: ‘GFP_KERNEL’ undeclared (first use in this function) kernel/sched/dl.c:1521:6: note: each undeclared identifier is reported only once for each function it appears in kernel/sched/dl.c: At top level: kernel/sched/dl.c:965:13: warning: ‘start_hrtick_dl’ defined but not used [-Wunused-function] make[2]: *** [kernel/sched/dl.o] Error 1 make[1]: *** [kernel/sched] Error 2 make: *** [kernel] Error 2 make: *** Waiting for unfinished jobs 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 Please read the FAQ at http://www.tux.org/lkml/
Re: The uncatchable jitter, or may the scheduler wars be over?
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 be technically defined as 'graphic buffer underrun', caused by the scheduler unable to align the deadline for some userspace programs that are crucial to video/opengl output v-refresh, that being really HARD RT ? As in, say the scheduler could sometimes decide to preempt the userspace in the middle of OpenGL/fb call [pretty easy to imagine this : userspace that often blocks on calls to the video hardware, or has a usespace thread that does that, and is unable to finish some opengl pipeline calls before end of its slice, or in case of misalignment, can execute enough commands to create one (or several) frame(s), and then is cut in the middle of creating another one and has to wait for its turn again, and in the mean time, vsync/video buffer swap occurs, and that last frame is lost/discarded/created with time settings from previous slice which are wrong] Bearing in mind, that the most length the video/fb/opengl buffer can have, is probably 3 (triple buffering as in some game settings), as opposed to (at least some) sound hw which can have buffers several ms long, it's not hard to imagine what happens if userspace cannot make it in time to update the buffer, causing 'underruns'. This would also explain why it doesn't matter to 'server' people - they don't have RT video hw/buffers they care for... (but they tune the below for max throughput instead) But whether it is measurable or not - I don't know. The OP (Uwaysi) has been fiddling with HZ value and the averaging period of the scheduler (which he called 'filter') (and granularity too). He's had some interesting results IMO. Hope the above makes sense and not much gibberish :) Lukasz I have now tried both CFS and BFS.Doom 3 is now running with very low jitter on both. Both need a 90hz timer, no highres timer, and a granularity/interval suited for "natural" (psychovisual profile). I also compiled them with some optimizations, and options for low jitter. (KBUILD_CFLAGS += -O3 -fno-defer-pop --param prefetch-latency=200) With Vsync on in doom3, it runs very smooth. Vsync off, BFS has less jitter than CFS. Doom 3 does 3 passes to opengl, and therefore seems more jitter-sensitive, so getting it to run well, means minimizing jitter. Compatibility layers, like Wine adds complexity though, and I have HL2 running in an intensely tweaked XP install, perfectly (without jitter). With wine and BFS, it runs as good, but with some major one second jitters. With CFS, some more smaller jitters / higher average jitter. But the major jitters are of less lenght. Videojitter on youtube, seems less with CFS aswell. So for "scheduler wars" indeed, identifying those jitters, and getting the best of both, is optimal. This with "low-latency desktop" preemption. I have yet to get the realtime patch/threadirqs working, however within the month I will have a new e5 computer, which probably will be a whole lot more fun to test that on. Also like I stated elsewhere, since daemons seem to make a difference, optimally putting daemons or processes that can, on a low-jitter queue, transparent to the user, seems optimal. Unfortunately realtime is not quite working as one would expect, causing input to be choked at times, if you want to have one main app, and the rest on sched_other, as a low-jitter queue. So I am still iterating this. Reducing jitter, seems to generally improve the computing experience, setting also higher expectations to quality. Also a machine with jitter ofcourse, behaves like a lower-end computer. So reducing jitter, seems to be central to an enjoyable computing experience. This all without unreasonable effort ofcourse. 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 Please read the FAQ at http://www.tux.org/lkml/
Re: Scheduler queues for less os-jitter?
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 do 0.001% cpu for processes, they get all
cpu, when there is nothing running?
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
Please read the FAQ at http://www.tux.org/lkml/
Re: Scheduler queues for less os-jitter?
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 do 0.001% cpu for processes, they get all cpu, when there is nothing running? 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 Please read the FAQ at http://www.tux.org/lkml/
Re: The uncatchable jitter, or may the scheduler wars be over?
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 that could be technically defined as 'graphic buffer underrun', caused by the scheduler unable to align the deadline for some userspace programs that are crucial to video/opengl output v-refresh, that being really HARD RT ? As in, say the scheduler could sometimes decide to preempt the userspace in the middle of OpenGL/fb call [pretty easy to imagine this : userspace that often blocks on calls to the video hardware, or has a usespace thread that does that, and is unable to finish some opengl pipeline calls before end of its slice, or in case of misalignment, can execute enough commands to create one (or several) frame(s), and then is cut in the middle of creating another one and has to wait for its turn again, and in the mean time, vsync/video buffer swap occurs, and that last frame is lost/discarded/created with time settings from previous slice which are wrong] Bearing in mind, that the most length the video/fb/opengl buffer can have, is probably 3 (triple buffering as in some game settings), as opposed to (at least some) sound hw which can have buffers several ms long, it's not hard to imagine what happens if userspace cannot make it in time to update the buffer, causing 'underruns'. This would also explain why it doesn't matter to 'server' people - they don't have RT video hw/buffers they care for... (but they tune the below for max throughput instead) But whether it is measurable or not - I don't know. The OP (Uwaysi) has been fiddling with HZ value and the averaging period of the scheduler (which he called 'filter') (and granularity too). He's had some interesting results IMO. Hope the above makes sense and not much gibberish :) Lukasz I have now tried both CFS and BFS.Doom 3 is now running with very low jitter on both. Both need a 90hz timer, no highres timer, and a granularity/interval suited for natural (psychovisual profile). I also compiled them with some optimizations, and options for low jitter. (KBUILD_CFLAGS += -O3 -fno-defer-pop --param prefetch-latency=200) With Vsync on in doom3, it runs very smooth. Vsync off, BFS has less jitter than CFS. Doom 3 does 3 passes to opengl, and therefore seems more jitter-sensitive, so getting it to run well, means minimizing jitter. Compatibility layers, like Wine adds complexity though, and I have HL2 running in an intensely tweaked XP install, perfectly (without jitter). With wine and BFS, it runs as good, but with some major one second jitters. With CFS, some more smaller jitters / higher average jitter. But the major jitters are of less lenght. Videojitter on youtube, seems less with CFS aswell. So for scheduler wars indeed, identifying those jitters, and getting the best of both, is optimal. This with low-latency desktop preemption. I have yet to get the realtime patch/threadirqs working, however within the month I will have a new e5 computer, which probably will be a whole lot more fun to test that on. Also like I stated elsewhere, since daemons seem to make a difference, optimally putting daemons or processes that can, on a low-jitter queue, transparent to the user, seems optimal. Unfortunately realtime is not quite working as one would expect, causing input to be choked at times, if you want to have one main app, and the rest on sched_other, as a low-jitter queue. So I am still iterating this. Reducing jitter, seems to generally improve the computing experience, setting also higher expectations to quality. Also a machine with jitter ofcourse, behaves like a lower-end computer. So reducing jitter, seems to be central to an enjoyable computing experience. This all without unreasonable effort ofcourse. 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 Please read the FAQ at http://www.tux.org/lkml/
re: sched: SCHED_DEADLINE v6
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] kernel/sched/dl.c: In function ‘init_sched_dl_class’: kernel/sched/dl.c:1521:6: error: ‘GFP_KERNEL’ undeclared (first use in this function) kernel/sched/dl.c:1521:6: note: each undeclared identifier is reported only once for each function it appears in kernel/sched/dl.c: At top level: kernel/sched/dl.c:965:13: warning: ‘start_hrtick_dl’ defined but not used [-Wunused-function] make[2]: *** [kernel/sched/dl.o] Error 1 make[1]: *** [kernel/sched] Error 2 make: *** [kernel] Error 2 make: *** Waiting for unfinished jobs 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 Please read the FAQ at http://www.tux.org/lkml/
Re: sched: SCHED_DEADLINE v6
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 parameters that are no longer supported. 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 Please read the FAQ at http://www.tux.org/lkml/
Re: sched: SCHED_DEADLINE v6
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...@paradoxuncreated.com 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 parameters that are no longer supported. 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 Please read the FAQ at http://www.tux.org/lkml/
Re: sched: SCHED_DEADLINE v6
Nobody knows? This is really obscure for an EDF patch. Making things a bit more accessible should be a priority. I think a lot of enthusiasts would like to have smooth control over stuff, without windows-jitter. If you can do a robot arm, jitter-free with this, then I am very interested. 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...@paradoxuncreated.com 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 parameters that are no longer supported. 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 Please read the FAQ at http://www.tux.org/lkml/
Fwd: Re: Scheduler queues for less os-jitter?
--- 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, Uwaysi Bin Kareem wrote: 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 get (simplified) something like mainapp - process1 in queue 2, mainapp - process2 in queue 2, mainapp - process 3 in queue 2, etc. Or is that already batch maybe, lol. You could try SCHED_AUTOGROUP, or create whatever task groups manually, or use systemd to do that for you. Like everything else having anything to do with scheduling, all are double edged swords, so may help, may hurt. -Mike Actually I did achieve this with fifo-relatime. Low jitter OpenGL seems to be able to do, running the opengl app as realtime, with a low sched_rt_period_us value and a high sched_rt_runtime_us value. 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 Please read the FAQ at http://www.tux.org/lkml/
Fwd: Re: Scheduler queues for less os-jitter?
--- 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 Wed, 2012-10-10 at 20:13 +0200, Uwaysi Bin Kareem wrote: 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 get (simplified) something like mainapp - process1 in queue 2, mainapp - process2 in queue 2, mainapp - process 3 in queue 2, etc. Or is that already batch maybe, lol. You could try SCHED_AUTOGROUP, or create whatever task groups manually, or use systemd to do that for you. Like everything else having anything to do with scheduling, all are double edged swords, so may help, may hurt. -Mike Actually I did achieve this with fifo-relatime. Low jitter OpenGL seems to be able to do, running the opengl app as realtime, with a low sched_rt_period_us value and a high sched_rt_runtime_us value. 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 Please read the FAQ at http://www.tux.org/lkml/
Re: Jitter
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 "fighting bufferbloat". 10 years ago, I talked about how responsive vintage computers was, without "OS". And I have taken that further, and now work with low-jitter for the desktop. Low latency all the way, or atleast down to 0.2ms max latency and jitter. In the mean time, the masses are unaware of jitter, unless it is very noticable such as recent discussions on "microstutter". Most still advise to "not turn off services" in windows, yet show me benchmarks of "motherboards" with DPC latency of 50-300uS. I am already running at 5uS in windows here. And it is not "the motherboard". This is about OS-jitter. And in linux, I am running with even less jitter, now trying rt-patch only at "low latency" preemption yet, but still. And even in the linuxcommunity many seem not to understand. Those who do are much higher then on windows though. And while many also make completely absurd statements and attack what I am doing, I am very happily running what feels like a high performance computer. With a lot of activity being there on the next frame, and ultrasmooth framerates in OpenGL. Indeed optimizing and removing jitter, seeing improvements on what goes on, on the highest performing bus in the computer, seems to improve general desktop computing. I think I have tried most things now, and unless you want to wait 10 years for people to catch on, you should consider low-jitter aswell. And I am also interested in any patches that currently are not mainline. - Please repost in this thread if you have any. Or any other information, or ongoing development. If it is not all in the RT patch, that is. Peace Be With You. I am also buying a machine particulary made for low-jitter/low-latency now. Soemthing like this: http://paradoxuncreated.com/Blog/wordpress/?p=3866 I intuitively follow the praises of God, in brilliance and excellence, and eternal divinity. And now I am reducing jitter, and so should you. Imagine having low-latency video-communication online, jitterfree tearingless. Smooth and accurate 72fps. It puts the power of the media in the individuals hands. And that supports the growth of those who are far above the common society. And that again everyone benefits from. Forget about those being slaves to commercial contructs and the ever evil boss. They are free to follow the praises of God aswell. And the ignorance of society will no longer matter to those who can reach those levels. They will instead be followers. Wouldn`t you rather put power and finacial means in their hands? Are they not the fittest to set trends? Ofcourse, with the safetymeasure of moral guidelines. Which no doubt is a good discussion in itself. No more TV, marketing inanities, and oppression of the developed individualist. Instead, imagine for instance a concept of "individual developments" recognizing high-reaching talent, and supporting them by individual channels, on a state-developed online network. Just take communication to the next level. 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 Please read the FAQ at http://www.tux.org/lkml/
Re: Jitter
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, and now we have fighting bufferbloat. 10 years ago, I talked about how responsive vintage computers was, without OS. And I have taken that further, and now work with low-jitter for the desktop. Low latency all the way, or atleast down to 0.2ms max latency and jitter. In the mean time, the masses are unaware of jitter, unless it is very noticable such as recent discussions on microstutter. Most still advise to not turn off services in windows, yet show me benchmarks of motherboards with DPC latency of 50-300uS. I am already running at 5uS in windows here. And it is not the motherboard. This is about OS-jitter. And in linux, I am running with even less jitter, now trying rt-patch only at low latency preemption yet, but still. And even in the linuxcommunity many seem not to understand. Those who do are much higher then on windows though. And while many also make completely absurd statements and attack what I am doing, I am very happily running what feels like a high performance computer. With a lot of activity being there on the next frame, and ultrasmooth framerates in OpenGL. Indeed optimizing and removing jitter, seeing improvements on what goes on, on the highest performing bus in the computer, seems to improve general desktop computing. I think I have tried most things now, and unless you want to wait 10 years for people to catch on, you should consider low-jitter aswell. And I am also interested in any patches that currently are not mainline. - Please repost in this thread if you have any. Or any other information, or ongoing development. If it is not all in the RT patch, that is. Peace Be With You. I am also buying a machine particulary made for low-jitter/low-latency now. Soemthing like this: http://paradoxuncreated.com/Blog/wordpress/?p=3866 I intuitively follow the praises of God, in brilliance and excellence, and eternal divinity. And now I am reducing jitter, and so should you. Imagine having low-latency video-communication online, jitterfree tearingless. Smooth and accurate 72fps. It puts the power of the media in the individuals hands. And that supports the growth of those who are far above the common society. And that again everyone benefits from. Forget about those being slaves to commercial contructs and the ever evil boss. They are free to follow the praises of God aswell. And the ignorance of society will no longer matter to those who can reach those levels. They will instead be followers. Wouldn`t you rather put power and finacial means in their hands? Are they not the fittest to set trends? Ofcourse, with the safetymeasure of moral guidelines. Which no doubt is a good discussion in itself. No more TV, marketing inanities, and oppression of the developed individualist. Instead, imagine for instance a concept of individual developments recognizing high-reaching talent, and supporting them by individual channels, on a state-developed online network. Just take communication to the next level. 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 Please read the FAQ at http://www.tux.org/lkml/
Jitter
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, without "OS". And I have taken that further, and now work with low-jitter for the desktop. Low latency all the way, or atleast down to 0.2ms max latency and jitter. In the mean time, the masses are unaware of jitter, unless it is very noticable such as recent discussions on "microstutter". Most still advise to "not turn off services" in windows, yet show me benchmarks of "motherboards" with DPC latency of 50-300uS. I am already running at 5uS in windows here. And it is not "the motherboard". This is about OS-jitter. And in linux, I am running with even less jitter, now trying rt-patch only at "low latency" preemption yet, but still. And even in the linuxcommunity many seem not to understand. Those who do are much higher then on windows though. And while many also make completely absurd statements and attack what I am doing, I am very happily running what feels like a high performance computer. With a lot of activity being there on the next frame, and ultrasmooth framerates in OpenGL. Indeed optimizing and removing jitter, seeing improvements on what goes on, on the highest performing bus in the computer, seems to improve general desktop computing. I think I have tried most things now, and unless you want to wait 10 years for people to catch on, you should consider low-jitter aswell. And I am also interested in any patches that currently are not mainline. - Please repost in this thread if you have any. Or any other information, or ongoing development. If it is not all in the RT patch, that is. 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 Please read the FAQ at http://www.tux.org/lkml/
Fwd: Re: [ANNOUNCE] 3.6.2-rt4
--- 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 threadedirqs continue, they never worked on my machine. I saw someone discuss a possibility to run basic realtime without threaded irqs, but the full patch required it. Could you or anyone detail it? If you want any info, just say what. 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 Please read the FAQ at http://www.tux.org/lkml/
Compilation options
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 of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Compilation options
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 of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Fwd: Re: [ANNOUNCE] 3.6.2-rt4
--- 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. Unfortunately the problem of threadedirqs continue, they never worked on my machine. I saw someone discuss a possibility to run basic realtime without threaded irqs, but the full patch required it. Could you or anyone detail it? If you want any info, just say what. 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 Please read the FAQ at http://www.tux.org/lkml/
Jitter
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, without OS. And I have taken that further, and now work with low-jitter for the desktop. Low latency all the way, or atleast down to 0.2ms max latency and jitter. In the mean time, the masses are unaware of jitter, unless it is very noticable such as recent discussions on microstutter. Most still advise to not turn off services in windows, yet show me benchmarks of motherboards with DPC latency of 50-300uS. I am already running at 5uS in windows here. And it is not the motherboard. This is about OS-jitter. And in linux, I am running with even less jitter, now trying rt-patch only at low latency preemption yet, but still. And even in the linuxcommunity many seem not to understand. Those who do are much higher then on windows though. And while many also make completely absurd statements and attack what I am doing, I am very happily running what feels like a high performance computer. With a lot of activity being there on the next frame, and ultrasmooth framerates in OpenGL. Indeed optimizing and removing jitter, seeing improvements on what goes on, on the highest performing bus in the computer, seems to improve general desktop computing. I think I have tried most things now, and unless you want to wait 10 years for people to catch on, you should consider low-jitter aswell. And I am also interested in any patches that currently are not mainline. - Please repost in this thread if you have any. Or any other information, or ongoing development. If it is not all in the RT patch, that is. 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 Please read the FAQ at http://www.tux.org/lkml/
re: Optimizing scheduling policies for Ubuntu (desktop), for low-jitter.
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 running sequentially as simple round robin, or? I would like to see a lowpriority round-robin, and not just the realtime one. Maybe a modification on "idle" pri. I just want to know daemons can be made transparent to jitter. Or atleast some measure of fairness to sequentialness that keeps the lowest jitter. Anyone following ? :) 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 Please read the FAQ at http://www.tux.org/lkml/
re: Optimizing scheduling policies for Ubuntu (desktop), for low-jitter.
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 running sequentially as simple round robin, or? I would like to see a lowpriority round-robin, and not just the realtime one. Maybe a modification on idle pri. I just want to know daemons can be made transparent to jitter. Or atleast some measure of fairness to sequentialness that keeps the lowest jitter. Anyone following ? :) 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 Please read the FAQ at http://www.tux.org/lkml/
Optimizing scheduling policies for Ubuntu (desktop), for low-jitter.
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 point is to get waiting due to suboptimal policies out. Making the desktop as responsive as it can be. What it does for the time being, is set X to realtime, so that it`s singlethreadedness does not become a performance bottleneck. And all daemons to idle pri. Also idle pri, would ofcourse work best, if they are queued in a way separately, from normal apps, so they don`t all kick in at once. (and cause jitter) Peace Be With You. Please CC me. -- #initctl list | grep running #for running daemons echo "Setting intelligent scheduling policies." # realtime priority for that which need it # RCU boost to 99 sudo schedtool -p 97 -n -20 -F `pgrep X` # X is singlethreaded, this makes it perform the best. #does any other thread benefit(desktop) from realtime? #for pid in `pgrep "softirqs"`; do # sudo schedtool -F -p 98 -n -20 $pid #done # idle priority for daemons for pid in `pgrep "upstart"`; do sudo schedtool -D -p 0 -n 19 $pid done for pid in `pgrep "udev"`; do sudo schedtool -D -p 0 -n 19 $pid done sudo schedtool -p 0 -n 19 -D `pgrep rsyslogd` for pid in `pgrep "dbus"`; do sudo schedtool -D -p 0 -n 19 $pid done sudo schedtool -p 0 -n 19 -D `pgrep modem-manager` sudo schedtool -p 0 -n 19 -D `pgrep cupsd` sudo schedtool -p 0 -n 19 -D `pgrep acpid` sudo schedtool -p 0 -n 19 -D `pgrep cron` sudo schedtool -p 0 -n 19 -D `pgrep atd` for pid in `pgrep "avahi"`; do sudo schedtool -D -p 0 -n 19 $pid done sudo schedtool -p 0 -n 19 -D `pgrep whoopsie` for pid in `pgrep "winbindd"`; do sudo schedtool -D -p 0 -n 19 $pid done sudo schedtool -p 0 -n 19 -D `pgrep polkit` sudo schedtool -p 0 -n 19 -D `pgrep timidity` sudo schedtool -p 0 -n 19 -D `pgrep accounts` sudo schedtool -p 0 -n 19 -D `pgrep console` sudo schedtool -p 0 -n 19 -D `pgrep upowerd` sudo schedtool -p 0 -n 19 -D `pgrep colord` sudo schedtool -p 0 -n 19 -D `pgrep rtkit` #ubuntu has set this to nice 1? sudo schedtool -p 0 -n 19 -D `pgrep keyring` for pid in `pgrep "gvfs"`; do sudo schedtool -D -p 0 -n 19 $pid done sudo schedtool -p 0 -n 19 -D `pgrep gconf` # remomve unneeded #sudo stop tty6 #sudo stop tty5 #sudo stop tty4 #sudo stop tty3 #sudo stop tty2 #sudo stop tty1 #sudo modprobe -r usb-storage sudo modprobe -r snd_seq_dummy # is anyone using this? sudo modprobe -r snd_seq_oss sudo modprobe -r snd_seq_midi sudo modprobe -r snd_rawmidi sudo modprobe -r snd_seq_midi_event #sudo modprobe -r snd_seq sudo modprobe -r snd_pcm_oss sudo modprobe -r snd_mixer_oss sudo modprobe -r serio_raw -- 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 Please read the FAQ at http://www.tux.org/lkml/
Optimizing scheduling policies for Ubuntu (desktop), for low-jitter.
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 point is to get waiting due to suboptimal policies out. Making the desktop as responsive as it can be. What it does for the time being, is set X to realtime, so that it`s singlethreadedness does not become a performance bottleneck. And all daemons to idle pri. Also idle pri, would ofcourse work best, if they are queued in a way separately, from normal apps, so they don`t all kick in at once. (and cause jitter) Peace Be With You. Please CC me. -- #initctl list | grep running #for running daemons echo Setting intelligent scheduling policies. # realtime priority for that which need it # RCU boost to 99 sudo schedtool -p 97 -n -20 -F `pgrep X` # X is singlethreaded, this makes it perform the best. #does any other thread benefit(desktop) from realtime? #for pid in `pgrep softirqs`; do # sudo schedtool -F -p 98 -n -20 $pid #done # idle priority for daemons for pid in `pgrep upstart`; do sudo schedtool -D -p 0 -n 19 $pid done for pid in `pgrep udev`; do sudo schedtool -D -p 0 -n 19 $pid done sudo schedtool -p 0 -n 19 -D `pgrep rsyslogd` for pid in `pgrep dbus`; do sudo schedtool -D -p 0 -n 19 $pid done sudo schedtool -p 0 -n 19 -D `pgrep modem-manager` sudo schedtool -p 0 -n 19 -D `pgrep cupsd` sudo schedtool -p 0 -n 19 -D `pgrep acpid` sudo schedtool -p 0 -n 19 -D `pgrep cron` sudo schedtool -p 0 -n 19 -D `pgrep atd` for pid in `pgrep avahi`; do sudo schedtool -D -p 0 -n 19 $pid done sudo schedtool -p 0 -n 19 -D `pgrep whoopsie` for pid in `pgrep winbindd`; do sudo schedtool -D -p 0 -n 19 $pid done sudo schedtool -p 0 -n 19 -D `pgrep polkit` sudo schedtool -p 0 -n 19 -D `pgrep timidity` sudo schedtool -p 0 -n 19 -D `pgrep accounts` sudo schedtool -p 0 -n 19 -D `pgrep console` sudo schedtool -p 0 -n 19 -D `pgrep upowerd` sudo schedtool -p 0 -n 19 -D `pgrep colord` sudo schedtool -p 0 -n 19 -D `pgrep rtkit` #ubuntu has set this to nice 1? sudo schedtool -p 0 -n 19 -D `pgrep keyring` for pid in `pgrep gvfs`; do sudo schedtool -D -p 0 -n 19 $pid done sudo schedtool -p 0 -n 19 -D `pgrep gconf` # remomve unneeded #sudo stop tty6 #sudo stop tty5 #sudo stop tty4 #sudo stop tty3 #sudo stop tty2 #sudo stop tty1 #sudo modprobe -r usb-storage sudo modprobe -r snd_seq_dummy # is anyone using this? sudo modprobe -r snd_seq_oss sudo modprobe -r snd_seq_midi sudo modprobe -r snd_rawmidi sudo modprobe -r snd_seq_midi_event #sudo modprobe -r snd_seq sudo modprobe -r snd_pcm_oss sudo modprobe -r snd_mixer_oss sudo modprobe -r serio_raw -- 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 Please read the FAQ at http://www.tux.org/lkml/
Realtime threads for less jitter (w/ X)?
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? And are there other threads, that X is again waiting for, that should be above X? 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 Please read the FAQ at http://www.tux.org/lkml/
Realtime threads for less jitter (w/ X)?
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? And are there other threads, that X is again waiting for, that should be above X? 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 Please read the FAQ at http://www.tux.org/lkml/
Low-jitter kernel benchmark.
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 config. And then not even X, so this is not related to "desktop". So this should weigh heavily with any sane desktop-distro maker, for his config. Ubuntu configgers have no valid argument about throughput anymore, for instance. 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 Please read the FAQ at http://www.tux.org/lkml/
Low-jitter kernel benchmark.
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 config. And then not even X, so this is not related to desktop. So this should weigh heavily with any sane desktop-distro maker, for his config. Ubuntu configgers have no valid argument about throughput anymore, for instance. 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 Please read the FAQ at http://www.tux.org/lkml/
Scheduler queues for less os-jitter?
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 get (simplified) something like mainapp - process1 in queue 2, mainapp - process2 in queue 2, mainapp - process 3 in queue 2, etc. Or is that already batch maybe, lol. 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 Please read the FAQ at http://www.tux.org/lkml/
Scheduler queues for less os-jitter?
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 get (simplified) something like mainapp - process1 in queue 2, mainapp - process2 in queue 2, mainapp - process 3 in queue 2, etc. Or is that already batch maybe, lol. 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 Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.6.1
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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Minimal jitter = good desktop.
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 on the local shaved. Wine seems indeed also to be extremely jitter-sensitive. So low-jitter seems to be good, for many things. Also stopping ubuntu-daemons was neccesary. 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 Please read the FAQ at http://www.tux.org/lkml/
Re: Minimal jitter = good desktop.
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 on the local shaved. Wine seems indeed also to be extremely jitter-sensitive. So low-jitter seems to be good, for many things. Also stopping ubuntu-daemons was neccesary. 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 Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.6.1
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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Minimal jitter = good desktop.
This is really simple, and I don`t care about top posting, down posting, in the middle comments or whatever. Do whatehver you like, and have no other rule that what is in your soul. That is what drives ultimately society. Look up Aristotle natural-law. Which actually is based in divine nature. Now jitter, is really easy. Jitter-sensitive OpenGL applications will show visible jitter. Doom 3 is extremely sensitive. I have tried to make it run well many times, but it wasn`t until I became aware of more unintuitive behaviour not according to theory with some settings, and I started trying reversing them. And then I found 90hz to be optimal, and giving a perfectly running doom 3. Someone actually suggested I try 1hz BFS patch, because "it would reduce latency." Which I did. But then I also tried 20hz, and there was little difference on BFS. Ultimately I arrived at 90hz with CFS, and tweaking it`s granularity a bit, and it worked well. (Better than BFS). So in that case, JITTER is solved. Also a lot of low-jitter configs use low hz. So that seems to back it up. And everything on my computer seems to be running better. Smoother, more responsive. Even the ads in my browser ;( I also appreciate those who can measure small jitter in the uS range, and mitigate it. But I would also like for those, to check if a simple hold-logic would be better. For the 10ms filter I mentioned. Say hold for 1ms at 0, and then to regular peak values. It seems that would be a better filter. This just me being a perfectionist ofcourse. So yes, according to the general definition of "os-jitter" it seems highly reduced. I don`t know at all why you are mentioning opengl calls. Obviously games, do run quite well. Atleast now. It is also going to be great to test new games coming, and keep iterating knowledge and tuning. Also ofcourse OpenGL is a great part of Wayland, and I hear more h/w is used there, and hopefully it doesn`t stop performance in games, so one can have an effectful desktop, without worrying about 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], but it's been topposted] But the problem is, we cannot measure 'jitter' directly. There is no reliable benchmark that produces results adherent to what someones' definition of 'jitter' is. At software level we only have a notion of latency, and that leads to jitter as david said, but as the kernel is not real-time, you cannot guarantee every opengl command/fb transfer will be finished in time for next frame to be drawn. Maybe if someone could get the information of % finished frames (or % dropped frames) within one slice of userspace, that would be something to build on, but it's still a derivative and with unknown bias level. Lukasz -- 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 Please read the FAQ at http://www.tux.org/lkml/ -- 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 Please read the FAQ at http://www.tux.org/lkml/
Re: Minimal jitter = good desktop.
In the context of os-jitter, delay/latency is measured as jitter. Peace Be With You. On Sat, 06 Oct 2012 03:06:57 +0200, wrote: less jitter != less latency you could (in theory) eliminate jitter by delaying every keypress processed for exactly 1 second by having the code paths that process keypresses faster insert delays before implementing the results. that would result in zero jitter, but horrific latency. latency is how long it takes to do something, jitter is how much the latency varies. normally, if you optimize for one you make the other worse. If 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 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 signalpath of OpenGL improved the overall computing experience. Even youtube videos who are not synced to refresh, with a refresh of 60, and a videofps of 30, runs quite well. http://paradoxuncreated.com/Blog/wordpress/?p=3221 System is responsive, and I have only had one problem, and that is packing seems not to work at the moment. For a fast test in Ubuntu, try http://paradoxuncreated.com/Blog/wordpress/?p=2268 Definately a recommended config on the desktop. 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 Please read the FAQ at http://www.tux.org/lkml/ -- 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 Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.5-rc7
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 you measure the difference between 3956 and 4000? The other stuff in your note sounds sane, but I'm having a hard time believing that 3956 was arrived at in any sort of systematic or measured way - it smells like cargo cult programming to me... Well, you might not like the answer. It is based on purification of the senses by meditation. You can read about it here. http://www.youtube.com/watch?v=Cz8fCnMBnuc=related And then in a pure state, simply tuning the hz, to ones liking, trying to find a "natural value", which probably corresponds with the fact that, natural phenomna such as wind, temperature, influence similar phenomena to "jitter". Also based on 10 years of work with DSP ;) Don`t worry about the 3956 timer anymore though, I use 90hz now. For some reasons many places online state higher HZ = higher resolution, and lower latency. For audio and opengl this is not true. Audio still has the same latency at 90hz, and OpenGL performs better, with less jitter. You can take my low-jitter kernel for a spin, here. http://paradoxuncreated.com/Blog/wordpress/?p=2268 Particulary note that OpenGL in doom3 is very smooth, (if you have any jitter try killing background daemons). Audio latency is stable at 1ms, and few clicks at 0.3. I have also run it at 0.3ms stable latency with realtime threads, with a firewire audio card. Simple HDA soundchip seems to perform poorer for some reason. One would think that an onboard soundchip would have less potential latency. The whole system runs well. I am also using this info for thoughts on cfs. If granularity should be tuned up for more processes running, maybe related granuarlity to processes, for best resource usage. Currently also I think the 10ms filter could be replaced with a simpler hold logic, so you don`t have to update it more that neccesary, or compute share based on filters impulse response. Just some small observations. 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 Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.5-rc7
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 measure the difference between 3956 and 4000? The other stuff in your note sounds sane, but I'm having a hard time believing that 3956 was arrived at in any sort of systematic or measured way - it smells like cargo cult programming to me... Well, you might not like the answer. It is based on purification of the senses by meditation. You can read about it here. http://www.youtube.com/watch?v=Cz8fCnMBnucfeature=related And then in a pure state, simply tuning the hz, to ones liking, trying to find a natural value, which probably corresponds with the fact that, natural phenomna such as wind, temperature, influence similar phenomena to jitter. Also based on 10 years of work with DSP ;) Don`t worry about the 3956 timer anymore though, I use 90hz now. For some reasons many places online state higher HZ = higher resolution, and lower latency. For audio and opengl this is not true. Audio still has the same latency at 90hz, and OpenGL performs better, with less jitter. You can take my low-jitter kernel for a spin, here. http://paradoxuncreated.com/Blog/wordpress/?p=2268 Particulary note that OpenGL in doom3 is very smooth, (if you have any jitter try killing background daemons). Audio latency is stable at 1ms, and few clicks at 0.3. I have also run it at 0.3ms stable latency with realtime threads, with a firewire audio card. Simple HDA soundchip seems to perform poorer for some reason. One would think that an onboard soundchip would have less potential latency. The whole system runs well. I am also using this info for thoughts on cfs. If granularity should be tuned up for more processes running, maybe related granuarlity to processes, for best resource usage. Currently also I think the 10ms filter could be replaced with a simpler hold logic, so you don`t have to update it more that neccesary, or compute share based on filters impulse response. Just some small observations. 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 Please read the FAQ at http://www.tux.org/lkml/
Re: Minimal jitter = good desktop.
In the context of os-jitter, delay/latency is measured as jitter. Peace Be With You. On Sat, 06 Oct 2012 03:06:57 +0200, da...@lang.hm wrote: less jitter != less latency you could (in theory) eliminate jitter by delaying every keypress processed for exactly 1 second by having the code paths that process keypresses faster insert delays before implementing the results. that would result in zero jitter, but horrific latency. latency is how long it takes to do something, jitter is how much the latency varies. normally, if you optimize for one you make the other worse. If 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 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 signalpath of OpenGL improved the overall computing experience. Even youtube videos who are not synced to refresh, with a refresh of 60, and a videofps of 30, runs quite well. http://paradoxuncreated.com/Blog/wordpress/?p=3221 System is responsive, and I have only had one problem, and that is packing seems not to work at the moment. For a fast test in Ubuntu, try http://paradoxuncreated.com/Blog/wordpress/?p=2268 Definately a recommended config on the desktop. 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 Please read the FAQ at http://www.tux.org/lkml/ -- 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 Please read the FAQ at http://www.tux.org/lkml/
Re: Minimal jitter = good desktop.
This is really simple, and I don`t care about top posting, down posting, in the middle comments or whatever. Do whatehver you like, and have no other rule that what is in your soul. That is what drives ultimately society. Look up Aristotle natural-law. Which actually is based in divine nature. Now jitter, is really easy. Jitter-sensitive OpenGL applications will show visible jitter. Doom 3 is extremely sensitive. I have tried to make it run well many times, but it wasn`t until I became aware of more unintuitive behaviour not according to theory with some settings, and I started trying reversing them. And then I found 90hz to be optimal, and giving a perfectly running doom 3. Someone actually suggested I try 1hz BFS patch, because it would reduce latency. Which I did. But then I also tried 20hz, and there was little difference on BFS. Ultimately I arrived at 90hz with CFS, and tweaking it`s granularity a bit, and it worked well. (Better than BFS). So in that case, JITTER is solved. Also a lot of low-jitter configs use low hz. So that seems to back it up. And everything on my computer seems to be running better. Smoother, more responsive. Even the ads in my browser ;( I also appreciate those who can measure small jitter in the uS range, and mitigate it. But I would also like for those, to check if a simple hold-logic would be better. For the 10ms filter I mentioned. Say hold for 1ms at 0, and then to regular peak values. It seems that would be a better filter. This just me being a perfectionist ofcourse. So yes, according to the general definition of os-jitter it seems highly reduced. I don`t know at all why you are mentioning opengl calls. Obviously games, do run quite well. Atleast now. It is also going to be great to test new games coming, and keep iterating knowledge and tuning. Also ofcourse OpenGL is a great part of Wayland, and I hear more h/w is used there, and hopefully it doesn`t stop performance in games, so one can have an effectful desktop, without worrying about 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 el.es...@gmail.com wrote: Uwaysi Bin Kareem uwaysi.bin.kareem at paradoxuncreated.com writes: [sorry for cutting out the context], but it's been topposted] But the problem is, we cannot measure 'jitter' directly. There is no reliable benchmark that produces results adherent to what someones' definition of 'jitter' is. At software level we only have a notion of latency, and that leads to jitter as david said, but as the kernel is not real-time, you cannot guarantee every opengl command/fb transfer will be finished in time for next frame to be drawn. Maybe if someone could get the information of % finished frames (or % dropped frames) within one slice of userspace, that would be something to build on, but it's still a derivative and with unknown bias level. Lukasz -- 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 Please read the FAQ at http://www.tux.org/lkml/ -- 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 Please read the FAQ at http://www.tux.org/lkml/
Minimal jitter = good desktop.
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 signalpath of OpenGL improved the overall computing experience. Even youtube videos who are not synced to refresh, with a refresh of 60, and a videofps of 30, runs quite well. http://paradoxuncreated.com/Blog/wordpress/?p=3221 System is responsive, and I have only had one problem, and that is packing seems not to work at the moment. For a fast test in Ubuntu, try http://paradoxuncreated.com/Blog/wordpress/?p=2268 Definately a recommended config on the desktop. 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 Please read the FAQ at http://www.tux.org/lkml/
Re: The 10ms averager in fair.c
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 50 filters running at resolution X, only to do that, with 50 processes. Why not just replace that with a simple, on off, say cpu usage = 0 for the first 1 ms. Scheduler activity probably doesn`t last longer than that, atleast with preempt on. And with a filter you will have 10ms activity indication after the last input. That should just be truncated, and after 1ms things should just work on peak values. (not average). From thinking about how this filter would improve anything, that seems like the better way to do anything like that. 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 Please read the FAQ at http://www.tux.org/lkml/
Re: The 10ms averager in fair.c
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 50 filters running at resolution X, only to do that, with 50 processes. Why not just replace that with a simple, on off, say cpu usage = 0 for the first 1 ms. Scheduler activity probably doesn`t last longer than that, atleast with preempt on. And with a filter you will have 10ms activity indication after the last input. That should just be truncated, and after 1ms things should just work on peak values. (not average). From thinking about how this filter would improve anything, that seems like the better way to do anything like that. 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 Please read the FAQ at http://www.tux.org/lkml/
Minimal jitter = good desktop.
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 signalpath of OpenGL improved the overall computing experience. Even youtube videos who are not synced to refresh, with a refresh of 60, and a videofps of 30, runs quite well. http://paradoxuncreated.com/Blog/wordpress/?p=3221 System is responsive, and I have only had one problem, and that is packing seems not to work at the moment. For a fast test in Ubuntu, try http://paradoxuncreated.com/Blog/wordpress/?p=2268 Definately a recommended config on the desktop. 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 Please read the FAQ at http://www.tux.org/lkml/
RME Fireface UCX in Classcompliant USB-mode, is not working?
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 Please read the FAQ at http://www.tux.org/lkml/
RME Fireface UCX in Classcompliant USB-mode, is not working?
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 Please read the FAQ at http://www.tux.org/lkml/
Doom 3 perfect on linux.
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; I finally got doom 3 to run perfectly. I just wanted you to know. Any comments to this email please. An ubuntu distro-kernel with the same philosophy, can also be downloaded from here http://paradoxuncreated.com/tmp/linux-headers-3.5.4_3.5.4-10.00.Custom_amd64.deb http://paradoxuncreated.com/tmp/linux-image-3.5.4_3.5.4-10.00.Custom_amd64.deb Some more info: (not updated yet with the new kernel - http://paradoxuncreated.com/Blog/wordpress/?p=2268 (please disregard the high hz here, reducing hz gained better jitter levels than higher hz) 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 Please read the FAQ at http://www.tux.org/lkml/
Re: The 10ms averager in fair.c + granularity
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 the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The 10ms averager in fair.c + granularity
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 the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Doom 3 perfect on linux.
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; I finally got doom 3 to run perfectly. I just wanted you to know. Any comments to this email please. An ubuntu distro-kernel with the same philosophy, can also be downloaded from here http://paradoxuncreated.com/tmp/linux-headers-3.5.4_3.5.4-10.00.Custom_amd64.deb http://paradoxuncreated.com/tmp/linux-image-3.5.4_3.5.4-10.00.Custom_amd64.deb Some more info: (not updated yet with the new kernel - http://paradoxuncreated.com/Blog/wordpress/?p=2268 (please disregard the high hz here, reducing hz gained better jitter levels than higher hz) 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 Please read the FAQ at http://www.tux.org/lkml/
Re: The 10ms averager in fair.c + granularity
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 and "echo 45 > sched_min_granularity_ns" which would be strongly tuned towards server, only reduced jitter in doom 3. Which means it is a good value for desktop. So that doesn`t seem to cohere with what is stated aswell. Anyway.. One needs to get really deep into the code to understand why it is so. So you know, I don know. I am going to take a look at it, and there probably won`t be any patch anytime soon. 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 Please read the FAQ at http://www.tux.org/lkml/
Re: The 10ms averager in fair.c
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 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 impact. > > -Mike > You already know? Then please elaborate, what a 10ms smoother is doing in a nanosecond resolution scheduler. I already told you. I passed a piece of information along that I thought would be of use to you. That's all. I don't like your tone, and owe you nothing, so have a nice day, and goodbye. -Mike Lol. Well, I will just have to fix this on my own then. Imagine if you have a nanosecond cpu burst, and calculating load on a 10ms smoothed version of that. I really thought that would be easy to understand. I am very suprised to find it there, and very surprised at your attitude. If you had something actual to say about this, you would have done it in the first post. "A lot of groups" means nothing. 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 Please read the FAQ at http://www.tux.org/lkml/
Re: The 10ms averager in fair.c
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 impact. -Mike You already know? Then please elaborate, what a 10ms smoother is doing in a nanosecond resolution scheduler. Superficially there is no negative impact with Renoise, doom 3, chromium, on a shaved+low/latency/low jitter kernel, core 2 duo desktop. Chromium actually got faster. Well it felt faster, and that is what I care about. You can probably config differently and get more throughput for servers, but that does not equate to throughput when talking about displayed frames on screen. So please elaborate what you mean by negative impact. 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 Please read the FAQ at http://www.tux.org/lkml/
Re: The 10ms averager in fair.c
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 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. 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 Please read the FAQ at http://www.tux.org/lkml/
Re: The 10ms averager in fair.c
Ok, so you don`t know. Well, then it looks like what I said, to me. What is a 100us load, that gets filtered by a 10ms filter? Nothing. Or a very very small value that rises and falls over 10ms. Load-distribution based on a spike that happened a long time ago (in computing terms) seems very 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-philosophy that was done, without much knowledge of filters? Are you? I see "I don't see the point", along with "I haven't looked closely". If you look, perhaps you'll see a better way, and can post patches. That's the strength of opensource. -Mike -- 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 Please read the FAQ at http://www.tux.org/lkml/
Re: The 10ms averager in fair.c
Ok, so you don`t know. Well, then it looks like what I said, to me. What is a 100us load, that gets filtered by a 10ms filter? Nothing. Or a very very small value that rises and falls over 10ms. Load-distribution based on a spike that happened a long time ago (in computing terms) seems very 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 just a design-philosophy that was done, without much knowledge of filters? Are you? I see I don't see the point, along with I haven't looked closely. If you look, perhaps you'll see a better way, and can post patches. That's the strength of opensource. -Mike -- 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 Please read the FAQ at http://www.tux.org/lkml/
Re: The 10ms averager in fair.c
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 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. 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 Please read the FAQ at http://www.tux.org/lkml/
Re: The 10ms averager in fair.c
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 that there is negative impact. -Mike You already know? Then please elaborate, what a 10ms smoother is doing in a nanosecond resolution scheduler. Superficially there is no negative impact with Renoise, doom 3, chromium, on a shaved+low/latency/low jitter kernel, core 2 duo desktop. Chromium actually got faster. Well it felt faster, and that is what I care about. You can probably config differently and get more throughput for servers, but that does not equate to throughput when talking about displayed frames on screen. So please elaborate what you mean by negative impact. 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 Please read the FAQ at http://www.tux.org/lkml/
Re: The 10ms averager in fair.c
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 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 impact. -Mike You already know? Then please elaborate, what a 10ms smoother is doing in a nanosecond resolution scheduler. I already told you. I passed a piece of information along that I thought would be of use to you. That's all. I don't like your tone, and owe you nothing, so have a nice day, and goodbye. -Mike Lol. Well, I will just have to fix this on my own then. Imagine if you have a nanosecond cpu burst, and calculating load on a 10ms smoothed version of that. I really thought that would be easy to understand. I am very suprised to find it there, and very surprised at your attitude. If you had something actual to say about this, you would have done it in the first post. A lot of groups means nothing. 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 Please read the FAQ at http://www.tux.org/lkml/
Re: The 10ms averager in fair.c + granularity
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 and echo 45 sched_min_granularity_ns which would be strongly tuned towards server, only reduced jitter in doom 3. Which means it is a good value for desktop. So that doesn`t seem to cohere with what is stated aswell. Anyway.. One needs to get really deep into the code to understand why it is so. So you know, I don know. I am going to take a look at it, and there probably won`t be any patch anytime soon. 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 Please read the FAQ at http://www.tux.org/lkml/
Re: The 10ms averager in fair.c
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 to the principle of sharing? Not if you want to be able to use lots of groups, and still do something other than in-kernel arithmetic. -Mike "Use lots of groups"? I don`t even see the point with that. Currently doesn`t cfs manipulate nice levels? If you set constant nice levels, and remove the filter, things will work more as expected. High nice value, should be short slice. That is your "group", for instance "low priority stuff". That a filter filters out the initial cpu spike, only to starve it and elevate the priority later, is silly. That is delayed execution. Now I haven`t looked that close at the whole scheduler yet, but no.. I can`t possibly think what a filter does in there, that smears at 100uS spike, over 10ms. Btw, I did set it to 1ns, and it only improved things. So that it should have some function seems odd to me. Are you sure this isn`t just a design-philosophy that was done, without much knowledge of filters? 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 Please read the FAQ at http://www.tux.org/lkml/
Re: The 10ms averager in fair.c
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 that counterintuitive to the principle of sharing? Not if you want to be able to use lots of groups, and still do something other than in-kernel arithmetic. -Mike Use lots of groups? I don`t even see the point with that. Currently doesn`t cfs manipulate nice levels? If you set constant nice levels, and remove the filter, things will work more as expected. High nice value, should be short slice. That is your group, for instance low priority stuff. That a filter filters out the initial cpu spike, only to starve it and elevate the priority later, is silly. That is delayed execution. Now I haven`t looked that close at the whole scheduler yet, but no.. I can`t possibly think what a filter does in there, that smears at 100uS spike, over 10ms. Btw, I did set it to 1ns, and it only improved things. So that it should have some function seems odd to me. Are you sure this isn`t just a design-philosophy that was done, without much knowledge of filters? 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 Please read the FAQ at http://www.tux.org/lkml/
Re: The 10ms averager in fair.c
Just to illustrate, you have a filter that lasts 10ms, and a cpu process that lasts 100uS Original spike 5 | 4 | 3 | 2 | 1 | 0 | 0ms___10ms Filtered spike 5 4 3 2 1 . 0.. .. 0ms10ms Not only 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 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. Starting applications won`t have their cpu-usage before 5ms, which is quite a bit on modern machines. Well if you use a linearphase filter, I don`t know what kind of averager you use. The best would ofcourse be to use a minimalphase gaussian averager. Which might be overkill. Atleast a one-pole iir, buf = buf + (-buf + in) * cut)); One pole IIRs also have a better frequency response. When you are working with low-latencies, wouldn`t it be better if such things are tuned for target latency. I think few care about latency after 0.2ms. So say the filter should be set to 0.4ms max. Why would you want to filter cpu-usage also really? Peace Be With You. (please CC me.) -- 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 Please read the FAQ at http://www.tux.org/lkml/
re: Linux 3.6-rc7
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 with ALSA + onboard soundcard at 0.3ms lantecy now, without RT-threads. Meaning os-jitter is near optimal for audio/video. I think few care once it is below 0.2ms. Ofcourse one always wants lower, but at that point, things feel like hardware, and becomes unnoticable to the user. 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 Please read the FAQ at http://www.tux.org/lkml/
re: Linux 3.5-rc7
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 with ALSA + onboard soundcard at 0.3ms lantecy now, without RT-threads. Meaning os-jitter is near optimal for audio/video. I think few care once it is below 0.2ms. Ofcourse one always wants lower, but at that point, things feel like hardware, and becomes unnoticable to the user. 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 Please read the FAQ at http://www.tux.org/lkml/
re: The 10ms averager in fair.c
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 message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
The 10ms averager in fair.c
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. Starting applications won`t have their cpu-usage before 5ms, which is quite a bit on modern machines. Well if you use a linearphase filter, I don`t know what kind of averager you use. The best would ofcourse be to use a minimalphase gaussian averager. Which might be overkill. Atleast a one-pole iir, buf = buf + (-buf + in) * cut)); One pole IIRs also have a better frequency response. When you are working with low-latencies, wouldn`t it be better if such things are tuned for target latency. I think few care about latency after 0.2ms. So say the filter should be set to 0.4ms max. Why would you want to filter cpu-usage also really? Peace Be With You. (please CC me.) -- 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 Please read the FAQ at http://www.tux.org/lkml/
The 10ms averager in fair.c
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. Starting applications won`t have their cpu-usage before 5ms, which is quite a bit on modern machines. Well if you use a linearphase filter, I don`t know what kind of averager you use. The best would ofcourse be to use a minimalphase gaussian averager. Which might be overkill. Atleast a one-pole iir, buf = buf + (-buf + in) * cut)); One pole IIRs also have a better frequency response. When you are working with low-latencies, wouldn`t it be better if such things are tuned for target latency. I think few care about latency after 0.2ms. So say the filter should be set to 0.4ms max. Why would you want to filter cpu-usage also really? Peace Be With You. (please CC me.) -- 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 Please read the FAQ at http://www.tux.org/lkml/
re: The 10ms averager in fair.c
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 message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
re: Linux 3.5-rc7
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 with ALSA + onboard soundcard at 0.3ms lantecy now, without RT-threads. Meaning os-jitter is near optimal for audio/video. I think few care once it is below 0.2ms. Ofcourse one always wants lower, but at that point, things feel like hardware, and becomes unnoticable to the user. 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 Please read the FAQ at http://www.tux.org/lkml/
re: Linux 3.6-rc7
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 with ALSA + onboard soundcard at 0.3ms lantecy now, without RT-threads. Meaning os-jitter is near optimal for audio/video. I think few care once it is below 0.2ms. Ofcourse one always wants lower, but at that point, things feel like hardware, and becomes unnoticable to the user. 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 Please read the FAQ at http://www.tux.org/lkml/
Re: The 10ms averager in fair.c
Just to illustrate, you have a filter that lasts 10ms, and a cpu process that lasts 100uS Original spike 5 | 4 | 3 | 2 | 1 | 0 | 0ms___10ms Filtered spike 5 4 3 2 1 . 0.. .. 0ms10ms Not only 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 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. Starting applications won`t have their cpu-usage before 5ms, which is quite a bit on modern machines. Well if you use a linearphase filter, I don`t know what kind of averager you use. The best would ofcourse be to use a minimalphase gaussian averager. Which might be overkill. Atleast a one-pole iir, buf = buf + (-buf + in) * cut)); One pole IIRs also have a better frequency response. When you are working with low-latencies, wouldn`t it be better if such things are tuned for target latency. I think few care about latency after 0.2ms. So say the filter should be set to 0.4ms max. Why would you want to filter cpu-usage also really? Peace Be With You. (please CC me.) -- 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 Please read the FAQ at http://www.tux.org/lkml/
Low os-jitter operating system.
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 target frame rate. First of all drop unessecary layers from the kernel. Config it for minimal latency. (max preemption, more preemption = less os-jitter = less latency) Standard config usually is not configged this way, and leads to uneccesary chopping/frames dropped. That is not the way you want it. Use low-jitter applications. For instance - Webkit based browsers have lower jitter. Resulting in smoother youtube playback among other things. Webanimation in general. So you`d want to use Chromium as the default browser. Intelligent priorities for tasks. If you have background tasks that are insensitive to jitter and latency (non audio/video/net), let them have lower priority and only one cpu, so they are transparent to the user. Etc. Automatic lower priority for a wordprocessor for instance, would also fit the profile. Consider system applications with lowest jitter. This will also prepare the OS well for Wayland which is opengl based. Low-jitter = smoothest opengl experience. You should also consider promoting a refresh rate of 72, as optimal. Research shows that many prefer 72hz refresh rate. I can personally also confirm that this is a nice rate, quiet and peaceful, and if one shall describe it a "minimal psychovisual noise" setting. More seems to only add noise to the screen. Less is flickery. I further tuned this to 72.734hz, which you can try and confirm, as a "minimal psychovisual noise" profile. One should also inform about videos with 30fps, should have 60/90hz refresh rate, to avoid video-jitter. Or 25fps, 75hz etc. Similar for other formats. An automatically changing screenmode syncing mediaplayer would be optimal, with 72.734hz as standard mode, for hzadapting games or other. Peace Be With You. PS: If you need a video, to test with low-jitter, I have a low-jitter video here: This should play smoothly on a well-configged system @ 60hz refresh rate. Unfortunately I doubt the clocks are synced, so there still will be small jitter. Should not be much though. http://paradoxuncreated.com/Blog/wordpress/?page_id=70 -- 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 Please read the FAQ at http://www.tux.org/lkml/
Low os-jitter operating system.
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 target frame rate. First of all drop unessecary layers from the kernel. Config it for minimal latency. (max preemption, more preemption = less os-jitter = less latency) Standard config usually is not configged this way, and leads to uneccesary chopping/frames dropped. That is not the way you want it. Use low-jitter applications. For instance - Webkit based browsers have lower jitter. Resulting in smoother youtube playback among other things. Webanimation in general. So you`d want to use Chromium as the default browser. Intelligent priorities for tasks. If you have background tasks that are insensitive to jitter and latency (non audio/video/net), let them have lower priority and only one cpu, so they are transparent to the user. Etc. Automatic lower priority for a wordprocessor for instance, would also fit the profile. Consider system applications with lowest jitter. This will also prepare the OS well for Wayland which is opengl based. Low-jitter = smoothest opengl experience. You should also consider promoting a refresh rate of 72, as optimal. Research shows that many prefer 72hz refresh rate. I can personally also confirm that this is a nice rate, quiet and peaceful, and if one shall describe it a minimal psychovisual noise setting. More seems to only add noise to the screen. Less is flickery. I further tuned this to 72.734hz, which you can try and confirm, as a minimal psychovisual noise profile. One should also inform about videos with 30fps, should have 60/90hz refresh rate, to avoid video-jitter. Or 25fps, 75hz etc. Similar for other formats. An automatically changing screenmode syncing mediaplayer would be optimal, with 72.734hz as standard mode, for hzadapting games or other. Peace Be With You. PS: If you need a video, to test with low-jitter, I have a low-jitter video here: This should play smoothly on a well-configged system @ 60hz refresh rate. Unfortunately I doubt the clocks are synced, so there still will be small jitter. Should not be much though. http://paradoxuncreated.com/Blog/wordpress/?page_id=70 -- 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 Please read the FAQ at http://www.tux.org/lkml/
Re: Latency.
There is a whole thread on phoronix, regarding this, where many people have similar sentiments. Good to see others who understand the same. :) http://phoronix.com/forums/showthread.php?71741-A-Low-Latency-Kernel-For-Linux-Gaming Some people don`t seem to be noticing it. They are fewer 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 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 custom hardware arcade. (Why gamebox-developers isn`t using this, is a mystery). Recently I also tried to come as close to that experience on windows, and found that win32priorityseparation on 25, all processes on idle, to avoid cpu2 stalling cpu1, and minimal drivers, services, and processes gave a similar experience. Windows btw, also gives lower latency, if one moves windows, which one can use/abuse in a script/hack. The feeling from low latency systems brings back the exhilaration of custom hardware and assembly programming. It gives a different feel, and I do believe it sets a high quality expectation to software and I wonder if that is why the Amiga is said to have so much good software, and responsible for it`s reputation. My windows-partition now runs as good as an Amiga, and I managed to make it run even better, reminding me of singletasking systems like Mac OS. Games are just so much more fun with this. And the overall os is so much more responsive. More optimized stuff like Wayland will ofcourse even improve things more. I do think that for "desktop" the focus should really be on low-latency systems. If "desktop" and "server" are the two different profiles you usually config for in linux, how about two different standard configs? Or are these merging aswell, since I would think multi-cpu servers appreciate low os-jitter aswell? Just some thoughts. 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 Please read the FAQ at http://www.tux.org/lkml/
Re: Latency.
There is a whole thread on phoronix, regarding this, where many people have similar sentiments. Good to see others who understand the same. :) http://phoronix.com/forums/showthread.php?71741-A-Low-Latency-Kernel-For-Linux-Gaming Some people don`t seem to be noticing it. They are fewer 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 wrote: 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 custom hardware arcade. (Why gamebox-developers isn`t using this, is a mystery). Recently I also tried to come as close to that experience on windows, and found that win32priorityseparation on 25, all processes on idle, to avoid cpu2 stalling cpu1, and minimal drivers, services, and processes gave a similar experience. Windows btw, also gives lower latency, if one moves windows, which one can use/abuse in a script/hack. The feeling from low latency systems brings back the exhilaration of custom hardware and assembly programming. It gives a different feel, and I do believe it sets a high quality expectation to software and I wonder if that is why the Amiga is said to have so much good software, and responsible for it`s reputation. My windows-partition now runs as good as an Amiga, and I managed to make it run even better, reminding me of singletasking systems like Mac OS. Games are just so much more fun with this. And the overall os is so much more responsive. More optimized stuff like Wayland will ofcourse even improve things more. I do think that for desktop the focus should really be on low-latency systems. If desktop and server are the two different profiles you usually config for in linux, how about two different standard configs? Or are these merging aswell, since I would think multi-cpu servers appreciate low os-jitter aswell? Just some thoughts. 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 Please read the FAQ at http://www.tux.org/lkml/
Latency.
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 custom hardware arcade. (Why gamebox-developers isn`t using this, is a mystery). Recently I also tried to come as close to that experience on windows, and found that win32priorityseparation on 25, all processes on idle, to avoid cpu2 stalling cpu1, and minimal drivers, services, and processes gave a similar experience. Windows btw, also gives lower latency, if one moves windows, which one can use/abuse in a script/hack. The feeling from low latency systems brings back the exhilaration of custom hardware and assembly programming. It gives a different feel, and I do believe it sets a high quality expectation to software and I wonder if that is why the Amiga is said to have so much good software, and responsible for it`s reputation. My windows-partition now runs as good as an Amiga, and I managed to make it run even better, reminding me of singletasking systems like Mac OS. Games are just so much more fun with this. And the overall os is so much more responsive. More optimized stuff like Wayland will ofcourse even improve things more. I do think that for "desktop" the focus should really be on low-latency systems. If "desktop" and "server" are the two different profiles you usually config for in linux, how about two different standard configs? Or are these merging aswell, since I would think multi-cpu servers appreciate low os-jitter aswell? Just some thoughts. 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 Please read the FAQ at http://www.tux.org/lkml/
Latency.
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 custom hardware arcade. (Why gamebox-developers isn`t using this, is a mystery). Recently I also tried to come as close to that experience on windows, and found that win32priorityseparation on 25, all processes on idle, to avoid cpu2 stalling cpu1, and minimal drivers, services, and processes gave a similar experience. Windows btw, also gives lower latency, if one moves windows, which one can use/abuse in a script/hack. The feeling from low latency systems brings back the exhilaration of custom hardware and assembly programming. It gives a different feel, and I do believe it sets a high quality expectation to software and I wonder if that is why the Amiga is said to have so much good software, and responsible for it`s reputation. My windows-partition now runs as good as an Amiga, and I managed to make it run even better, reminding me of singletasking systems like Mac OS. Games are just so much more fun with this. And the overall os is so much more responsive. More optimized stuff like Wayland will ofcourse even improve things more. I do think that for desktop the focus should really be on low-latency systems. If desktop and server are the two different profiles you usually config for in linux, how about two different standard configs? Or are these merging aswell, since I would think multi-cpu servers appreciate low os-jitter aswell? Just some thoughts. 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 Please read the FAQ at http://www.tux.org/lkml/
Re: System-drivers ported to Windows XP?
I have a list of drivers here, many of them dated 2001.
http://paradoxuncreated.com/Blog/wordpress/?p=1608 (MS making me upset as
usual.)
I am really just looking for better drivers, and thought maybe someone
knew if more current opensource versions existed. I have not found
anything online though, so therefore I ask here.
I have also thought about the ReactOS project, and wonder if they have
more current drivers, seeing as they work on the project currently, I am
discussing in their forum now, but communication is going slow.
Peace Be With You.
On Wed, 29 Aug 2012 00:50:31 +0200, jdow wrote:
You might look into the ASIO drivers. Although for very heavy audio use
64 byte buffers are a more reliable than the ultra-short buffers you seem
to be using. 100 channels with 7 ms latency through an audio matrix is
a commercial product for XP and Win 7 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 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
update is ofcourse not giving me the available ones from 2012, and they
are hard
to track down.
I was wondering if anyone had ported generic-system drivers, which then
would
probably be more optimized, than the 2001-ones, to windows XP?
If anyone wants to read about my findings on Windows XP, please read:
http://paradoxuncreated.com/Blog/wordpress/?p=1506
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
Please read the FAQ at http://www.tux.org/lkml/
--
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
Please read the FAQ at http://www.tux.org/lkml/
System-drivers ported to Windows XP?
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 update is ofcourse not giving me the available ones from 2012, and they are hard to track down. I was wondering if anyone had ported generic-system drivers, which then would probably be more optimized, than the 2001-ones, to windows XP? If anyone wants to read about my findings on Windows XP, please read: http://paradoxuncreated.com/Blog/wordpress/?p=1506 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 Please read the FAQ at http://www.tux.org/lkml/
System-drivers ported to Windows XP?
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 update is ofcourse not giving me the available ones from 2012, and they are hard to track down. I was wondering if anyone had ported generic-system drivers, which then would probably be more optimized, than the 2001-ones, to windows XP? If anyone wants to read about my findings on Windows XP, please read: http://paradoxuncreated.com/Blog/wordpress/?p=1506 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 Please read the FAQ at http://www.tux.org/lkml/
Re: System-drivers ported to Windows XP?
I have a list of drivers here, many of them dated 2001.
http://paradoxuncreated.com/Blog/wordpress/?p=1608 (MS making me upset as
usual.)
I am really just looking for better drivers, and thought maybe someone
knew if more current opensource versions existed. I have not found
anything online though, so therefore I ask here.
I have also thought about the ReactOS project, and wonder if they have
more current drivers, seeing as they work on the project currently, I am
discussing in their forum now, but communication is going slow.
Peace Be With You.
On Wed, 29 Aug 2012 00:50:31 +0200, jdow j...@earthlink.net wrote:
You might look into the ASIO drivers. Although for very heavy audio use
64 byte buffers are a more reliable than the ultra-short buffers you seem
to be using. 100 channels with 7 ms latency through an audio matrix is
a commercial product for XP and Win 7 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 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
update is ofcourse not giving me the available ones from 2012, and they
are hard
to track down.
I was wondering if anyone had ported generic-system drivers, which then
would
probably be more optimized, than the 2001-ones, to windows XP?
If anyone wants to read about my findings on Windows XP, please read:
http://paradoxuncreated.com/Blog/wordpress/?p=1506
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
Please read the FAQ at http://www.tux.org/lkml/
--
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
Please read the FAQ at http://www.tux.org/lkml/
