Re: [REPORT] 2.6.21 vs. 2.6.21-sd046 vs. 2.6.21-CFSv7
Con Kolivas wrote: On Tuesday 01 May 2007 05:29, Bill Davidsen wrote: System: Intel 6600 Core2duo, 2GB RAM, X nice 0 for all tests, display using i945G framebuffer Bill thanks for testing. Test: playing a 'toon with mplayer while kernel build -j20 running. Umm I don't think make -j20 is a realistic load on 2 cores. Not only does it raise your load to 20 but your I/O bandwidth will even be struggling. If video playback was to be smooth at that size a load it would suggest some serious unfairness. I'm not just pushing the fairness barrow here; I mean it would need to be really really unfair unless your combined X and video playback cpu combined added up to less than 1/20th of your total cpu power (which is possible but I kinda doubt it). Do you really use make -j20 to build regularly? Yes, this is a compile and file server, I frequently build a raft of kernels when a security patch comes out. There doesn't seem to be an i/o issue, with 2GB RAM and RAID5 over a SATA array I have enough, but honestly the disk activity is minimal, even with a single drive. Tuning: not yet, all scheduler parameters were default Result: base 2.6.21 showed some pauses and after the pause the sound got louder for a short time (<500ms). With sd-0.46 the playback had many glitches and finally just stopped with the display looping on a small number of frames and no sound. The skips were repeatable, the hang was only two of five runs, I didn't let them go until the make finished (todo list) but killed the mplayer after 10-15 sec. No glitches observed with cfsv7, I thought I saw one but repeating with granularity set to 50 and then with no make running convinced me that it's just a crappy piece of animation at that point. I did notice on your followup email that nice +10 of the 20 makes fixed the playback which sounds pretty good. Yes, I can get around the load doing that. I ran glxgears, again sd-0.46 had frequent pauses and uneven fps reported. Stock 2.6.21 had a visible pause when the frame rate was output, otherwise minimal pauses. CFSv7 appeared smooth at about 250 fps. I assume you mean glxgears when you're running make -j20 again here. Of course. ;-) -- bill davidsen <[EMAIL PROTECTED]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REPORT] 2.6.21 vs. 2.6.21-sd046 vs. 2.6.21-CFSv7
Bill Huey (hui) wrote: On Mon, Apr 30, 2007 at 03:58:45PM -0400, Bill Davidsen wrote: Followup: I reran with sd-0.46, setting rr_interval to 40, and then 5 (default was 16). Neither appeared to give a useful video playback. I did try setting the make to nice 10, and that made the playback perfectly smooth, as well as response to skip forward and volume change happening when the key was pressed instead of eventually. I also tried raising the nice of X to -10, that made things better on display, but I winder if it will let X run ahead of the nice-0 raid threads. Is this my hardware or is there a really odd behavior here? The sd seems to be too fair to cope well with this realistic load, and expecting users to nice things is probably morally correct but unrealistic. People have been reporting very good performance with regards to OpenGL applications under SD. What is your video driver ? NVidia proprietary ? My original post I was following gave my config, built-in graphics using 945G framebuffer. This is a server, I'm not a gamer. The only fancy graphics I have are on a system with no on board video at all, I picked up a moderately high-end Radeon card to drop in. And to give you an idea of what a gamer I am, that uses the vesafb driver ;-) OpenGL, X and direct frame buffer access (mplayer and friends) tend not to interact each other which can result in very different scheduling characteristics between them. -- bill davidsen <[EMAIL PROTECTED]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REPORT] 2.6.21 vs. 2.6.21-sd046 vs. 2.6.21-CFSv7
Bill Huey (hui) wrote: On Mon, Apr 30, 2007 at 03:58:45PM -0400, Bill Davidsen wrote: Followup: I reran with sd-0.46, setting rr_interval to 40, and then 5 (default was 16). Neither appeared to give a useful video playback. I did try setting the make to nice 10, and that made the playback perfectly smooth, as well as response to skip forward and volume change happening when the key was pressed instead of eventually. I also tried raising the nice of X to -10, that made things better on display, but I winder if it will let X run ahead of the nice-0 raid threads. Is this my hardware or is there a really odd behavior here? The sd seems to be too fair to cope well with this realistic load, and expecting users to nice things is probably morally correct but unrealistic. People have been reporting very good performance with regards to OpenGL applications under SD. What is your video driver ? NVidia proprietary ? My original post I was following gave my config, built-in graphics using 945G framebuffer. This is a server, I'm not a gamer. The only fancy graphics I have are on a system with no on board video at all, I picked up a moderately high-end Radeon card to drop in. And to give you an idea of what a gamer I am, that uses the vesafb driver ;-) OpenGL, X and direct frame buffer access (mplayer and friends) tend not to interact each other which can result in very different scheduling characteristics between them. -- bill davidsen [EMAIL PROTECTED] CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REPORT] 2.6.21 vs. 2.6.21-sd046 vs. 2.6.21-CFSv7
Con Kolivas wrote: On Tuesday 01 May 2007 05:29, Bill Davidsen wrote: System: Intel 6600 Core2duo, 2GB RAM, X nice 0 for all tests, display using i945G framebuffer Bill thanks for testing. Test: playing a 'toon with mplayer while kernel build -j20 running. Umm I don't think make -j20 is a realistic load on 2 cores. Not only does it raise your load to 20 but your I/O bandwidth will even be struggling. If video playback was to be smooth at that size a load it would suggest some serious unfairness. I'm not just pushing the fairness barrow here; I mean it would need to be really really unfair unless your combined X and video playback cpu combined added up to less than 1/20th of your total cpu power (which is possible but I kinda doubt it). Do you really use make -j20 to build regularly? Yes, this is a compile and file server, I frequently build a raft of kernels when a security patch comes out. There doesn't seem to be an i/o issue, with 2GB RAM and RAID5 over a SATA array I have enough, but honestly the disk activity is minimal, even with a single drive. Tuning: not yet, all scheduler parameters were default Result: base 2.6.21 showed some pauses and after the pause the sound got louder for a short time (500ms). With sd-0.46 the playback had many glitches and finally just stopped with the display looping on a small number of frames and no sound. The skips were repeatable, the hang was only two of five runs, I didn't let them go until the make finished (todo list) but killed the mplayer after 10-15 sec. No glitches observed with cfsv7, I thought I saw one but repeating with granularity set to 50 and then with no make running convinced me that it's just a crappy piece of animation at that point. I did notice on your followup email that nice +10 of the 20 makes fixed the playback which sounds pretty good. Yes, I can get around the load doing that. I ran glxgears, again sd-0.46 had frequent pauses and uneven fps reported. Stock 2.6.21 had a visible pause when the frame rate was output, otherwise minimal pauses. CFSv7 appeared smooth at about 250 fps. I assume you mean glxgears when you're running make -j20 again here. Of course. ;-) -- bill davidsen [EMAIL PROTECTED] CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REPORT] 2.6.21 vs. 2.6.21-sd046 vs. 2.6.21-CFSv7
On Tuesday 01 May 2007 05:29, Bill Davidsen wrote: > System: Intel 6600 Core2duo, 2GB RAM, X nice 0 for all tests, display > using i945G framebuffer Bill thanks for testing. > > Test: playing a 'toon with mplayer while kernel build -j20 running. Umm I don't think make -j20 is a realistic load on 2 cores. Not only does it raise your load to 20 but your I/O bandwidth will even be struggling. If video playback was to be smooth at that size a load it would suggest some serious unfairness. I'm not just pushing the fairness barrow here; I mean it would need to be really really unfair unless your combined X and video playback cpu combined added up to less than 1/20th of your total cpu power (which is possible but I kinda doubt it). Do you really use make -j20 to build regularly? > Tuning: not yet, all scheduler parameters were default > > Result: base 2.6.21 showed some pauses and after the pause the sound got > louder for a short time (<500ms). With sd-0.46 the playback had many > glitches and finally just stopped with the display looping on a small > number of frames and no sound. The skips were repeatable, the hang was > only two of five runs, I didn't let them go until the make finished > (todo list) but killed the mplayer after 10-15 sec. No glitches observed > with cfsv7, I thought I saw one but repeating with granularity set to > 50 and then with no make running convinced me that it's just a > crappy piece of animation at that point. I did notice on your followup email that nice +10 of the 20 makes fixed the playback which sounds pretty good. > I ran glxgears, again sd-0.46 had frequent pauses and uneven fps > reported. Stock 2.6.21 had a visible pause when the frame rate was > output, otherwise minimal pauses. CFSv7 appeared smooth at about 250 fps. I assume you mean glxgears when you're running make -j20 again here. > All tests gave acceptable typing echo, it seems that X is getting enough > time at that load to echo without major issues. That's nice; shows stability under load. > I will be doing tests with server load later this week, have to add disk > for the database. Great. > Hope this initial report is useful, I may be able to update ctxbench > later today and try that. Also good. -- -ck - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REPORT] 2.6.21 vs. 2.6.21-sd046 vs. 2.6.21-CFSv7
On Mon, Apr 30, 2007 at 03:58:45PM -0400, Bill Davidsen wrote: > Followup: I reran with sd-0.46, setting rr_interval to 40, and then 5 > (default was 16). Neither appeared to give a useful video playback. I > did try setting the make to nice 10, and that made the playback > perfectly smooth, as well as response to skip forward and volume change > happening when the key was pressed instead of eventually. > > I also tried raising the nice of X to -10, that made things better on > display, but I winder if it will let X run ahead of the nice-0 raid threads. > > Is this my hardware or is there a really odd behavior here? The sd seems > to be too fair to cope well with this realistic load, and expecting > users to nice things is probably morally correct but unrealistic. People have been reporting very good performance with regards to OpenGL applications under SD. What is your video driver ? NVidia proprietary ? OpenGL, X and direct frame buffer access (mplayer and friends) tend not to interact each other which can result in very different scheduling characteristics between them. [please CC the relevant people for their own benefit] bill - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REPORT] 2.6.21 vs. 2.6.21-sd046 vs. 2.6.21-CFSv7
Bill Davidsen wrote: System: Intel 6600 Core2duo, 2GB RAM, X nice 0 for all tests, display using i945G framebuffer Test: playing a 'toon with mplayer while kernel build -j20 running. Tuning: not yet, all scheduler parameters were default Result: base 2.6.21 showed some pauses and after the pause the sound got louder for a short time (<500ms). With sd-0.46 the playback had many glitches and finally just stopped with the display looping on a small number of frames and no sound. The skips were repeatable, the hang was only two of five runs, I didn't let them go until the make finished (todo list) but killed the mplayer after 10-15 sec. No glitches observed with cfsv7, I thought I saw one but repeating with granularity set to 50 and then with no make running convinced me that it's just a crappy piece of animation at that point. I ran glxgears, again sd-0.46 had frequent pauses and uneven fps reported. Stock 2.6.21 had a visible pause when the frame rate was output, otherwise minimal pauses. CFSv7 appeared smooth at about 250 fps. All tests gave acceptable typing echo, it seems that X is getting enough time at that load to echo without major issues. I will be doing tests with server load later this week, have to add disk for the database. Hope this initial report is useful, I may be able to update ctxbench later today and try that. Followup: I reran with sd-0.46, setting rr_interval to 40, and then 5 (default was 16). Neither appeared to give a useful video playback. I did try setting the make to nice 10, and that made the playback perfectly smooth, as well as response to skip forward and volume change happening when the key was pressed instead of eventually. I also tried raising the nice of X to -10, that made things better on display, but I winder if it will let X run ahead of the nice-0 raid threads. Is this my hardware or is there a really odd behavior here? The sd seems to be too fair to cope well with this realistic load, and expecting users to nice things is probably morally correct but unrealistic. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[REPORT] 2.6.21 vs. 2.6.21-sd046 vs. 2.6.21-CFSv7
System: Intel 6600 Core2duo, 2GB RAM, X nice 0 for all tests, display using i945G framebuffer Test: playing a 'toon with mplayer while kernel build -j20 running. Tuning: not yet, all scheduler parameters were default Result: base 2.6.21 showed some pauses and after the pause the sound got louder for a short time (<500ms). With sd-0.46 the playback had many glitches and finally just stopped with the display looping on a small number of frames and no sound. The skips were repeatable, the hang was only two of five runs, I didn't let them go until the make finished (todo list) but killed the mplayer after 10-15 sec. No glitches observed with cfsv7, I thought I saw one but repeating with granularity set to 50 and then with no make running convinced me that it's just a crappy piece of animation at that point. I ran glxgears, again sd-0.46 had frequent pauses and uneven fps reported. Stock 2.6.21 had a visible pause when the frame rate was output, otherwise minimal pauses. CFSv7 appeared smooth at about 250 fps. All tests gave acceptable typing echo, it seems that X is getting enough time at that load to echo without major issues. I will be doing tests with server load later this week, have to add disk for the database. Hope this initial report is useful, I may be able to update ctxbench later today and try that. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[REPORT] 2.6.21 vs. 2.6.21-sd046 vs. 2.6.21-CFSv7
System: Intel 6600 Core2duo, 2GB RAM, X nice 0 for all tests, display using i945G framebuffer Test: playing a 'toon with mplayer while kernel build -j20 running. Tuning: not yet, all scheduler parameters were default Result: base 2.6.21 showed some pauses and after the pause the sound got louder for a short time (500ms). With sd-0.46 the playback had many glitches and finally just stopped with the display looping on a small number of frames and no sound. The skips were repeatable, the hang was only two of five runs, I didn't let them go until the make finished (todo list) but killed the mplayer after 10-15 sec. No glitches observed with cfsv7, I thought I saw one but repeating with granularity set to 50 and then with no make running convinced me that it's just a crappy piece of animation at that point. I ran glxgears, again sd-0.46 had frequent pauses and uneven fps reported. Stock 2.6.21 had a visible pause when the frame rate was output, otherwise minimal pauses. CFSv7 appeared smooth at about 250 fps. All tests gave acceptable typing echo, it seems that X is getting enough time at that load to echo without major issues. I will be doing tests with server load later this week, have to add disk for the database. Hope this initial report is useful, I may be able to update ctxbench later today and try that. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REPORT] 2.6.21 vs. 2.6.21-sd046 vs. 2.6.21-CFSv7
Bill Davidsen wrote: System: Intel 6600 Core2duo, 2GB RAM, X nice 0 for all tests, display using i945G framebuffer Test: playing a 'toon with mplayer while kernel build -j20 running. Tuning: not yet, all scheduler parameters were default Result: base 2.6.21 showed some pauses and after the pause the sound got louder for a short time (500ms). With sd-0.46 the playback had many glitches and finally just stopped with the display looping on a small number of frames and no sound. The skips were repeatable, the hang was only two of five runs, I didn't let them go until the make finished (todo list) but killed the mplayer after 10-15 sec. No glitches observed with cfsv7, I thought I saw one but repeating with granularity set to 50 and then with no make running convinced me that it's just a crappy piece of animation at that point. I ran glxgears, again sd-0.46 had frequent pauses and uneven fps reported. Stock 2.6.21 had a visible pause when the frame rate was output, otherwise minimal pauses. CFSv7 appeared smooth at about 250 fps. All tests gave acceptable typing echo, it seems that X is getting enough time at that load to echo without major issues. I will be doing tests with server load later this week, have to add disk for the database. Hope this initial report is useful, I may be able to update ctxbench later today and try that. Followup: I reran with sd-0.46, setting rr_interval to 40, and then 5 (default was 16). Neither appeared to give a useful video playback. I did try setting the make to nice 10, and that made the playback perfectly smooth, as well as response to skip forward and volume change happening when the key was pressed instead of eventually. I also tried raising the nice of X to -10, that made things better on display, but I winder if it will let X run ahead of the nice-0 raid threads. Is this my hardware or is there a really odd behavior here? The sd seems to be too fair to cope well with this realistic load, and expecting users to nice things is probably morally correct but unrealistic. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REPORT] 2.6.21 vs. 2.6.21-sd046 vs. 2.6.21-CFSv7
On Mon, Apr 30, 2007 at 03:58:45PM -0400, Bill Davidsen wrote: Followup: I reran with sd-0.46, setting rr_interval to 40, and then 5 (default was 16). Neither appeared to give a useful video playback. I did try setting the make to nice 10, and that made the playback perfectly smooth, as well as response to skip forward and volume change happening when the key was pressed instead of eventually. I also tried raising the nice of X to -10, that made things better on display, but I winder if it will let X run ahead of the nice-0 raid threads. Is this my hardware or is there a really odd behavior here? The sd seems to be too fair to cope well with this realistic load, and expecting users to nice things is probably morally correct but unrealistic. People have been reporting very good performance with regards to OpenGL applications under SD. What is your video driver ? NVidia proprietary ? OpenGL, X and direct frame buffer access (mplayer and friends) tend not to interact each other which can result in very different scheduling characteristics between them. [please CC the relevant people for their own benefit] bill - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REPORT] 2.6.21 vs. 2.6.21-sd046 vs. 2.6.21-CFSv7
On Tuesday 01 May 2007 05:29, Bill Davidsen wrote: System: Intel 6600 Core2duo, 2GB RAM, X nice 0 for all tests, display using i945G framebuffer Bill thanks for testing. Test: playing a 'toon with mplayer while kernel build -j20 running. Umm I don't think make -j20 is a realistic load on 2 cores. Not only does it raise your load to 20 but your I/O bandwidth will even be struggling. If video playback was to be smooth at that size a load it would suggest some serious unfairness. I'm not just pushing the fairness barrow here; I mean it would need to be really really unfair unless your combined X and video playback cpu combined added up to less than 1/20th of your total cpu power (which is possible but I kinda doubt it). Do you really use make -j20 to build regularly? Tuning: not yet, all scheduler parameters were default Result: base 2.6.21 showed some pauses and after the pause the sound got louder for a short time (500ms). With sd-0.46 the playback had many glitches and finally just stopped with the display looping on a small number of frames and no sound. The skips were repeatable, the hang was only two of five runs, I didn't let them go until the make finished (todo list) but killed the mplayer after 10-15 sec. No glitches observed with cfsv7, I thought I saw one but repeating with granularity set to 50 and then with no make running convinced me that it's just a crappy piece of animation at that point. I did notice on your followup email that nice +10 of the 20 makes fixed the playback which sounds pretty good. I ran glxgears, again sd-0.46 had frequent pauses and uneven fps reported. Stock 2.6.21 had a visible pause when the frame rate was output, otherwise minimal pauses. CFSv7 appeared smooth at about 250 fps. I assume you mean glxgears when you're running make -j20 again here. All tests gave acceptable typing echo, it seems that X is getting enough time at that load to echo without major issues. That's nice; shows stability under load. I will be doing tests with server load later this week, have to add disk for the database. Great. Hope this initial report is useful, I may be able to update ctxbench later today and try that. Also good. -- -ck - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
