BUG: 2.6.12-ck5 (2.6.12.4) forcedeth driver
My x86-64 system has two network cards, a r8169 and a forcedeth, the r8169 works fine on my network, but when I attempt to use the forcedeth card, I get the following errors in dmesg: NETDEV WATCHDOG: eth0: transmit timed out nv_stop_tx: TransmitterStatus remained busy<7>eth0: tx_timeout: dead entries! --REPEATS-- I thought it might be a pci routing issues, so I tried pci=routeirq, but it made no difference. lspci reports: :00:05.0 Bridge: nVidia Corporation CK8S Ethernet Controller (rev a2) Subsystem: Micro-Star International Co., Ltd.: Unknown device 0250 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
BUG: 2.6.12-ck5 (2.6.12.4) forcedeth driver
is not set # CONFIG_CRYPTO_CAST6 is not set # CONFIG_CRYPTO_TEA is not set # CONFIG_CRYPTO_ARC4 is not set # CONFIG_CRYPTO_KHAZAD is not set # CONFIG_CRYPTO_ANUBIS is not set # CONFIG_CRYPTO_DEFLATE is not set # CONFIG_CRYPTO_MICHAEL_MIC is not set # CONFIG_CRYPTO_CRC32C is not set # CONFIG_CRYPTO_TEST is not set # # Hardware crypto devices # # # Library routines # # CONFIG_CRC_CCITT is not set CONFIG_CRC32=y # CONFIG_LIBCRC32C is not set CONFIG_ZLIB_INFLATE=y Do I have something configured wrong? Or is this really a bug, let me know how I can help. Thanks! -- Gabriel Devenyi [EMAIL PROTECTED] - 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: [ck] Re: [PATCH] i386 No-Idle-Hz aka Dynamic-Ticks 5
Along the same lines, is there an x86_64 patch around? On August 07, 2005 21:30, Con Kolivas wrote: > On Mon, 8 Aug 2005 11:20 am, Kyle Moffett wrote: > > On Aug 7, 2005, at 19:51:25, Con Kolivas wrote: > > > On Mon, 8 Aug 2005 02:58, Srivatsa Vaddagiri wrote: > > >> Con, > > >> I am afraid until SMP correctness is resolved, then this is not > > >> in a position to go in (unless you want to enable it only for UP, > > >> which > > >> I think should not be our target). I am working on making this work > > >> correctly on SMP systems. Hopefully I will post a patch soon. > > > > > > Great! I wasn't sure what time frame you meant when you last > > > posted. I won't > > > do anything more, leaving this patch as it is, and pass the baton > > > to you. > > > > I'm curious what has happened to the PPC side of the patch. IIRC, > > someone > > was working on such a port, but it seems to have been lost along the way > > at some point. Is there any additional information on that patch? > > Tony said he had it lying around somewhere and needed to find time to dust > it off and get it up to speed. > > Cheers, > Con > ___ > [EMAIL PROTECTED] > ck mailing list. Please reply-to-all when posting. > If replying to an email please reply below the original message. > http://bhhdoa.org.au/mailman/listinfo/ck -- Gabriel Devenyi [EMAIL PROTECTED] - 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: [ck] Re: [PATCH] i386 No-Idle-Hz aka Dynamic-Ticks 5
Along the same lines, is there an x86_64 patch around? On August 07, 2005 21:30, Con Kolivas wrote: On Mon, 8 Aug 2005 11:20 am, Kyle Moffett wrote: On Aug 7, 2005, at 19:51:25, Con Kolivas wrote: On Mon, 8 Aug 2005 02:58, Srivatsa Vaddagiri wrote: Con, I am afraid until SMP correctness is resolved, then this is not in a position to go in (unless you want to enable it only for UP, which I think should not be our target). I am working on making this work correctly on SMP systems. Hopefully I will post a patch soon. Great! I wasn't sure what time frame you meant when you last posted. I won't do anything more, leaving this patch as it is, and pass the baton to you. I'm curious what has happened to the PPC side of the patch. IIRC, someone was working on such a port, but it seems to have been lost along the way at some point. Is there any additional information on that patch? Tony said he had it lying around somewhere and needed to find time to dust it off and get it up to speed. Cheers, Con ___ [EMAIL PROTECTED] ck mailing list. Please reply-to-all when posting. If replying to an email please reply below the original message. http://bhhdoa.org.au/mailman/listinfo/ck -- Gabriel Devenyi [EMAIL PROTECTED] - 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: [ck] [ANNOUNCE] Interbench 0.27
After conducting some further research I've determined that cool n quiet has no effect on this "bug" if you can call it that. With the system running in init 1, and cool n quiet disabled in the bios, a sleep(N>0) results in the run_time value afterwards always being nearly the same value of ~995000 on my athlon64, similarly, my server an athlon-tbird, which definitely has no power saving features, hovers at ~1496000 Obviously since these values are nowhere near 1, the loops_per_ms benchmark runs forever, has anyone seen/read about sleep on amd machines doing something odd? Can anyone else with an amd machine confirm this behavior? Con: should we attempt to get the attention of LKML to see why amd chips act differently? -- Gabriel Devenyi [EMAIL PROTECTED] - 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: [ck] [ANNOUNCE] Interbench 0.27
After conducting some further research I've determined that cool n quiet has no effect on this bug if you can call it that. With the system running in init 1, and cool n quiet disabled in the bios, a sleep(N0) results in the run_time value afterwards always being nearly the same value of ~995000 on my athlon64, similarly, my server an athlon-tbird, which definitely has no power saving features, hovers at ~1496000 Obviously since these values are nowhere near 1, the loops_per_ms benchmark runs forever, has anyone seen/read about sleep on amd machines doing something odd? Can anyone else with an amd machine confirm this behavior? Con: should we attempt to get the attention of LKML to see why amd chips act differently? -- Gabriel Devenyi [EMAIL PROTECTED] - 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: [ck] [ANNOUNCE] Interbench 0.27
Con Kolivas wrote: I'd appreciate it. It's almost like some power stepping that's responsible. I've never seen it happen on any intel processor (including the pentiumM ones which have truckloads of power saving features). I've asked many people if they're running some equivalent of cool'n'quiet or powernow* and they all insist they're not... I'm not that familiar with all the powersaving techs though. I'm certainly not running any powersaving features on my athlon-tbird(it doesn't have any AFAIK, and its the hottest running AMD processor there is) However I've realized I did have cool n' quiet with the ondemand governor running on my athlon64, so that might indicate an issue, again, I'll look into that tonight. -- Gabriel Devenyi [EMAIL PROTECTED] - 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: [ck] [ANNOUNCE] Interbench 0.27
Con Kolivas wrote: On Thu, 4 Aug 2005 21:44, Gabriel Devenyi wrote: Hi Con, You must hate me by now... No. A bug report is a bug report. I hate the fact that I coded up 2000 lines of code and am still suffering from a problem in the same 10 lines that I did in version .01. PEBKAC. I guess we all have our weaknesses, mine is off-by-one errors, which are a bad thing when writing code for a statistics class at school ;) The "Gaming" benchmark has the same issue with nan coming out of the STDEV calculations, probably requires the same fix as before. Anyway Peter Williams has promised to fix it for me (yay!). Secondly, the benchmarking of loops_per_ms is running forever, and I managed to determine where its happening. In calibrate loops you run a while loop and iterate to get 1000 for run_time, then you calculate it one more time to ensure it was right *however* you put a sleep(1) before that. It seems to seriously skew the results, as it consistently adds ~500 to run_time, as run_time is now 1500, it jumps back up to redo because of the goto statement, and runs the while loop again, continue ad nausium. I added some simple debugging output which prints run time at the end of each while loop, and right before the goto if statement, this is the output. The solution I used is of course to simply comment out the sleep statement, then everything works nicely, however your comments appear to indicate that the sleep is there to make the system settle a little, perhaps another method needs to be used. Thanks for your time! I have to think about it. This seems a problem only on one type of cpu for some strange reason (lemme guess; athlon?) and indeed leaving out the sleep 1 followed by the check made results far less reliable. This way with the sleep 1 I have not had spurious results returned by the calibration. I'm open to suggestions if anyone's got one. Yeah, thats right, it spins forever on both my athlon-tbird and my athlon64 (in x86_64 mode). I'll take another look at the code tonight, to see if I can figure out why its causing this, or another way of incurring the delay you're looking for. Cheers, Con -- Gabriel Devenyi [EMAIL PROTECTED] - 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: [ck] [ANNOUNCE] Interbench 0.27
Hi Con, You must hate me by now... The "Gaming" benchmark has the same issue with nan coming out of the STDEV calculations, probably requires the same fix as before. Secondly, the benchmarking of loops_per_ms is running forever, and I managed to determine where its happening. In calibrate loops you run a while loop and iterate to get 1000 for run_time, then you calculate it one more time to ensure it was right *however* you put a sleep(1) before that. It seems to seriously skew the results, as it consistently adds ~500 to run_time, as run_time is now 1500, it jumps back up to redo because of the goto statement, and runs the while loop again, continue ad nausium. I added some simple debugging output which prints run time at the end of each while loop, and right before the goto if statement, this is the output. --cut-- loops_per_ms unknown; benchmarking... while: 224 while: 649 while: 993 while: 1025 while: 976 while: 1001 while: 1000 1494 while: 671 while: 997 while: 1000 1496 --cut-- The solution I used is of course to simply comment out the sleep statement, then everything works nicely, however your comments appear to indicate that the sleep is there to make the system settle a little, perhaps another method needs to be used. Thanks for your time! -- Gabriel Devenyi [EMAIL PROTECTED] Con Kolivas wrote: Interbench is a benchmark application is designed to benchmark interactivity in Linux. Direct download link: http://ck.kolivas.org/apps/interbench/interbench-0.27.tar.bz2 Web page: http://interbench.kolivas.org Changes: Standard deviation and average latency calculation was corrected. Gaming standard deviation was implemented. Cheers, Con ___ [EMAIL PROTECTED] ck mailing list. Please reply-to-all when posting. If replying to an email please reply below the original message. http://bhhdoa.org.au/mailman/listinfo/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: [ck] [ANNOUNCE] Interbench 0.27
Hi Con, You must hate me by now... The Gaming benchmark has the same issue with nan coming out of the STDEV calculations, probably requires the same fix as before. Secondly, the benchmarking of loops_per_ms is running forever, and I managed to determine where its happening. In calibrate loops you run a while loop and iterate to get 1000 for run_time, then you calculate it one more time to ensure it was right *however* you put a sleep(1) before that. It seems to seriously skew the results, as it consistently adds ~500 to run_time, as run_time is now 1500, it jumps back up to redo because of the goto statement, and runs the while loop again, continue ad nausium. I added some simple debugging output which prints run time at the end of each while loop, and right before the goto if statement, this is the output. --cut-- loops_per_ms unknown; benchmarking... while: 224 while: 649 while: 993 while: 1025 while: 976 while: 1001 while: 1000 1494 while: 671 while: 997 while: 1000 1496 --cut-- The solution I used is of course to simply comment out the sleep statement, then everything works nicely, however your comments appear to indicate that the sleep is there to make the system settle a little, perhaps another method needs to be used. Thanks for your time! -- Gabriel Devenyi [EMAIL PROTECTED] Con Kolivas wrote: Interbench is a benchmark application is designed to benchmark interactivity in Linux. Direct download link: http://ck.kolivas.org/apps/interbench/interbench-0.27.tar.bz2 Web page: http://interbench.kolivas.org Changes: Standard deviation and average latency calculation was corrected. Gaming standard deviation was implemented. Cheers, Con ___ [EMAIL PROTECTED] ck mailing list. Please reply-to-all when posting. If replying to an email please reply below the original message. http://bhhdoa.org.au/mailman/listinfo/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: [ck] [ANNOUNCE] Interbench 0.27
Con Kolivas wrote: On Thu, 4 Aug 2005 21:44, Gabriel Devenyi wrote: Hi Con, You must hate me by now... No. A bug report is a bug report. I hate the fact that I coded up 2000 lines of code and am still suffering from a problem in the same 10 lines that I did in version .01. PEBKAC. I guess we all have our weaknesses, mine is off-by-one errors, which are a bad thing when writing code for a statistics class at school ;) The Gaming benchmark has the same issue with nan coming out of the STDEV calculations, probably requires the same fix as before. Anyway Peter Williams has promised to fix it for me (yay!). Secondly, the benchmarking of loops_per_ms is running forever, and I managed to determine where its happening. In calibrate loops you run a while loop and iterate to get 1000 for run_time, then you calculate it one more time to ensure it was right *however* you put a sleep(1) before that. It seems to seriously skew the results, as it consistently adds ~500 to run_time, as run_time is now 1500, it jumps back up to redo because of the goto statement, and runs the while loop again, continue ad nausium. I added some simple debugging output which prints run time at the end of each while loop, and right before the goto if statement, this is the output. The solution I used is of course to simply comment out the sleep statement, then everything works nicely, however your comments appear to indicate that the sleep is there to make the system settle a little, perhaps another method needs to be used. Thanks for your time! I have to think about it. This seems a problem only on one type of cpu for some strange reason (lemme guess; athlon?) and indeed leaving out the sleep 1 followed by the check made results far less reliable. This way with the sleep 1 I have not had spurious results returned by the calibration. I'm open to suggestions if anyone's got one. Yeah, thats right, it spins forever on both my athlon-tbird and my athlon64 (in x86_64 mode). I'll take another look at the code tonight, to see if I can figure out why its causing this, or another way of incurring the delay you're looking for. Cheers, Con -- Gabriel Devenyi [EMAIL PROTECTED] - 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: [ck] [ANNOUNCE] Interbench 0.27
Con Kolivas wrote: I'd appreciate it. It's almost like some power stepping that's responsible. I've never seen it happen on any intel processor (including the pentiumM ones which have truckloads of power saving features). I've asked many people if they're running some equivalent of cool'n'quiet or powernow* and they all insist they're not... I'm not that familiar with all the powersaving techs though. I'm certainly not running any powersaving features on my athlon-tbird(it doesn't have any AFAIK, and its the hottest running AMD processor there is) However I've realized I did have cool n' quiet with the ondemand governor running on my athlon64, so that might indicate an issue, again, I'll look into that tonight. -- Gabriel Devenyi [EMAIL PROTECTED] - 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: [ck] [ANNOUNCE] Interbench v0.26
You haven't quite completely fixed the SD calculations it seems: --- Benchmarking simulated cpu of Gaming in the presence of simulated--- LoadLatency +/- SD (ms) Max Latency % Desired CPU None 2.44 +/- nan 48.698.7 Video 12.8 +/- nan 55.2 89 X 89.7 +/- nan 49452.8 Burn400 +/- nan 100420.1 Write 49.2 +/- nan 34367.2 Read 4.14 +/- nan 56.796.7 Compile 551 +/- nan 136915.4 -- Gabriel Devenyi [EMAIL PROTECTED] Con Kolivas wrote: This benchmark application is designed to benchmark interactivity in Linux. Direct download link: http://ck.kolivas.org/apps/interbench/interbench-0.26.tar.bz2 Web site: http://interbench.kolivas.org Changes since v0.24: v0.25: The timekeeping thread of background load no longer runs SCHED_FIFO. The benchmark is allowed to proceed if it does not detect swap and instead disables mem_load. The documentation was updated. v0.26: Fixed the standard deviation measurements at last (thanks Peter Williams). There should be no practical limit to how long you can run a benchmark for now. Cheers, Con ___ [EMAIL PROTECTED] ck mailing list. Please reply-to-all when posting. If replying to an email please reply below the original message. http://bhhdoa.org.au/mailman/listinfo/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: [ck] [ANNOUNCE] Interbench v0.26
You haven't quite completely fixed the SD calculations it seems: --- Benchmarking simulated cpu of Gaming in the presence of simulated--- LoadLatency +/- SD (ms) Max Latency % Desired CPU None 2.44 +/- nan 48.698.7 Video 12.8 +/- nan 55.2 89 X 89.7 +/- nan 49452.8 Burn400 +/- nan 100420.1 Write 49.2 +/- nan 34367.2 Read 4.14 +/- nan 56.796.7 Compile 551 +/- nan 136915.4 -- Gabriel Devenyi [EMAIL PROTECTED] Con Kolivas wrote: This benchmark application is designed to benchmark interactivity in Linux. Direct download link: http://ck.kolivas.org/apps/interbench/interbench-0.26.tar.bz2 Web site: http://interbench.kolivas.org Changes since v0.24: v0.25: The timekeeping thread of background load no longer runs SCHED_FIFO. The benchmark is allowed to proceed if it does not detect swap and instead disables mem_load. The documentation was updated. v0.26: Fixed the standard deviation measurements at last (thanks Peter Williams). There should be no practical limit to how long you can run a benchmark for now. Cheers, Con ___ [EMAIL PROTECTED] ck mailing list. Please reply-to-all when posting. If replying to an email please reply below the original message. http://bhhdoa.org.au/mailman/listinfo/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: [ck] [ANNOUNCE] Interbench v0.24
Thats correct, does it need it? -- Gabriel Devenyi [EMAIL PROTECTED] Con Kolivas wrote: On Fri, 29 Jul 2005 21:11, Gabriel Devenyi wrote: Hello Con, Attempting to run this on my 2.6.12-ck3s system results in the following error: sawtooth interbench-0.24 # ./interbench loops_per_ms unknown; benchmarking... 690936 loops_per_ms saved to file interbench.loops_per_ms Could not get memory or swap size Bug perhaps? My configuration hasn't changed since interbench 0.23 AFAIK. No swap? Cheers, Con - 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: [ck] [ANNOUNCE] Interbench v0.24
Thats correct, does it need it? -- Gabriel Devenyi [EMAIL PROTECTED] Con Kolivas wrote: On Fri, 29 Jul 2005 21:11, Gabriel Devenyi wrote: Hello Con, Attempting to run this on my 2.6.12-ck3s system results in the following error: sawtooth interbench-0.24 # ./interbench loops_per_ms unknown; benchmarking... 690936 loops_per_ms saved to file interbench.loops_per_ms Could not get memory or swap size Bug perhaps? My configuration hasn't changed since interbench 0.23 AFAIK. No swap? Cheers, Con - 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: amd64 Interbench Results
If these are reasonable numbers, is there any methods available to improve the responsiveness of X? I find I can't get smooth drawing, both scrolling text (in konsole) and dragging windows around, yields "skips" where the drawing isn't fluid. Secondly, what are the suggested settings for preempt in the ck kernel configuration? Thanks for your time. -- Gabriel Devenyi [EMAIL PROTECTED] On July 20, 2005 00:42, Con Kolivas wrote: > On Wed, 20 Jul 2005 12:46 pm, Gabriel Devenyi wrote: > > I've been using the the -ck patchset for a very long time, and I recently > > switched to a amd64 arch. I found that while my throughput improved, my > > system responsiveness has "felt" much lower than it did on my old x86 > > machine. > > > > Now that interbench is around, I have some quantitative results. Attached > > is my interbench results with *nothing* running other than agetty and a > > single bash console. My system is an AMD Athlon(tm) 64 Processor 3200+, > > with 1gig DDR400 RAM. Also attached is my kernel config. > > > > Seems to me there are some pretty high latencies for such a powerful > > system, is there anything I can do to improve this? Thanks for all your > > help. > > Those results don't look too bad to me. Absolute numbers don't mean much in > their own right unless you compare them to something else. Try a vanilla > kernel and then compare the results side by side. > > Cheers, > Con - 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: amd64 Interbench Results
If these are reasonable numbers, is there any methods available to improve the responsiveness of X? I find I can't get smooth drawing, both scrolling text (in konsole) and dragging windows around, yields skips where the drawing isn't fluid. Secondly, what are the suggested settings for preempt in the ck kernel configuration? Thanks for your time. -- Gabriel Devenyi [EMAIL PROTECTED] On July 20, 2005 00:42, Con Kolivas wrote: On Wed, 20 Jul 2005 12:46 pm, Gabriel Devenyi wrote: I've been using the the -ck patchset for a very long time, and I recently switched to a amd64 arch. I found that while my throughput improved, my system responsiveness has felt much lower than it did on my old x86 machine. Now that interbench is around, I have some quantitative results. Attached is my interbench results with *nothing* running other than agetty and a single bash console. My system is an AMD Athlon(tm) 64 Processor 3200+, with 1gig DDR400 RAM. Also attached is my kernel config. Seems to me there are some pretty high latencies for such a powerful system, is there anything I can do to improve this? Thanks for all your help. Those results don't look too bad to me. Absolute numbers don't mean much in their own right unless you compare them to something else. Try a vanilla kernel and then compare the results side by side. Cheers, Con - 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/
amd64 Interbench Results
I've been using the the -ck patchset for a very long time, and I recently switched to a amd64 arch. I found that while my throughput improved, my system responsiveness has "felt" much lower than it did on my old x86 machine. Now that interbench is around, I have some quantitative results. Attached is my interbench results with *nothing* running other than agetty and a single bash console. My system is an AMD Athlon(tm) 64 Processor 3200+, with 1gig DDR400 RAM. Also attached is my kernel config. Seems to me there are some pretty high latencies for such a powerful system, is there anything I can do to improve this? Thanks for all your help. -- Gabriel Devenyi [EMAIL PROTECTED] Using 1047120 loops per ms, running every load for 30 seconds Benchmarking kernel 2.6.12-ck3-r1 at datestamp 200507192216 --- Benchmarking Audio in the presence of loads --- Latency +/- SD (ms) Max Latency % Desired CPU % Deadlines Met None 0 +/- 0 0 100 95.3 Video 0.003 +/- 0.0227 0.246 100 95.3 X Using 1047120 loops per ms, running every load for 30 seconds Benchmarking kernel 2.6.12-ck3-r1 at datestamp 200507192218 --- Benchmarking Audio in the presence of loads --- Latency +/- SD (ms) Max Latency % Desired CPU % Deadlines Met None 0 +/- 0 0 100 95.3 Video 0.089 +/- 0.172 0.796 100 95.3 X 1.88 +/- 2.81 9.7 100 95.3 Burn 0.199 +/- 1.1 9.2 100 95.3 Write 0.021 +/- 0.2684.9 100 95.3 Read 0 +/- 0 0 100 95.3 Compile 0.378 +/- 1.06 100 100 94.8 Memload 0.354 +/- 0.359200 100 94.8 --- Benchmarking Video in the presence of loads --- Latency +/- SD (ms) Max Latency % Desired CPU % Deadlines Met None 0.001 +/- 0.001330.003 100 95.3 X 4.02 +/- 3.5122.6 100 86.2 Burn 0.206 +/- 0.813 16.7 100 94.8 Write 0.058 +/- 0.534 16.7 100 95.2 Read 0.009 +/- 0.0854 1.43 100 95.3 Compile 0.281 +/- 1.2 16.7 100 94.8 Memload 0.086 +/- 0.29 50 100 95 --- Benchmarking X in the presence of loads --- Latency +/- SD (ms) Max Latency % Desired CPU % Deadlines Met None 0.013 +/- 0.013 2 100 94.3 Video 11.8 +/- 11.8 66 100 60.7 Burn 0.013 +/- 0.013 2 100 94.3 Write 0.024 +/- 0.024 2 100 93.7 Read 0.013 +/- 0.013 2 100 94.3 Compile 0.013 +/- 0.013 2 100 94 Memload 0.029 +/- 0.0968 3 100 94.7 # # Automatically generated make config: don't edit # Linux kernel version: 2.6.12-ck3-r1 # Tue Jul 19 20:47:45 2005 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_MMU=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y # CONFIG_IKCONFIG is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set # CONFIG_KMOD is not set # # Processor type and features # CONFIG_MK8=y # CONFIG_MPSC is not set # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y # CONFIG_SMP is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y # CONFIG_NUMA is not set CONFIG_HPET_TIMER=y CONFIG_X86_PM_TIMER=y CONFIG_HPET_EMULATE_RTC=y # CONFIG_GART_IOMMU is not set CONFIG_DUMMY_IOMMU=y CONFIG_X86_MCE=y # CONFIG_X86_MCE_INTEL is not set # CONFIG_SECCOMP is not set CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_ISA_DMA_API=y # # Power management options # CONFIG_PM=y # CONFIG_PM_DEBUG is not set # CONFIG_SOFTWARE_SUSPEND is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_F
amd64 Interbench Results
I've been using the the -ck patchset for a very long time, and I recently switched to a amd64 arch. I found that while my throughput improved, my system responsiveness has felt much lower than it did on my old x86 machine. Now that interbench is around, I have some quantitative results. Attached is my interbench results with *nothing* running other than agetty and a single bash console. My system is an AMD Athlon(tm) 64 Processor 3200+, with 1gig DDR400 RAM. Also attached is my kernel config. Seems to me there are some pretty high latencies for such a powerful system, is there anything I can do to improve this? Thanks for all your help. -- Gabriel Devenyi [EMAIL PROTECTED] Using 1047120 loops per ms, running every load for 30 seconds Benchmarking kernel 2.6.12-ck3-r1 at datestamp 200507192216 --- Benchmarking Audio in the presence of loads --- Latency +/- SD (ms) Max Latency % Desired CPU % Deadlines Met None 0 +/- 0 0 100 95.3 Video 0.003 +/- 0.0227 0.246 100 95.3 X Using 1047120 loops per ms, running every load for 30 seconds Benchmarking kernel 2.6.12-ck3-r1 at datestamp 200507192218 --- Benchmarking Audio in the presence of loads --- Latency +/- SD (ms) Max Latency % Desired CPU % Deadlines Met None 0 +/- 0 0 100 95.3 Video 0.089 +/- 0.172 0.796 100 95.3 X 1.88 +/- 2.81 9.7 100 95.3 Burn 0.199 +/- 1.1 9.2 100 95.3 Write 0.021 +/- 0.2684.9 100 95.3 Read 0 +/- 0 0 100 95.3 Compile 0.378 +/- 1.06 100 100 94.8 Memload 0.354 +/- 0.359200 100 94.8 --- Benchmarking Video in the presence of loads --- Latency +/- SD (ms) Max Latency % Desired CPU % Deadlines Met None 0.001 +/- 0.001330.003 100 95.3 X 4.02 +/- 3.5122.6 100 86.2 Burn 0.206 +/- 0.813 16.7 100 94.8 Write 0.058 +/- 0.534 16.7 100 95.2 Read 0.009 +/- 0.0854 1.43 100 95.3 Compile 0.281 +/- 1.2 16.7 100 94.8 Memload 0.086 +/- 0.29 50 100 95 --- Benchmarking X in the presence of loads --- Latency +/- SD (ms) Max Latency % Desired CPU % Deadlines Met None 0.013 +/- 0.013 2 100 94.3 Video 11.8 +/- 11.8 66 100 60.7 Burn 0.013 +/- 0.013 2 100 94.3 Write 0.024 +/- 0.024 2 100 93.7 Read 0.013 +/- 0.013 2 100 94.3 Compile 0.013 +/- 0.013 2 100 94 Memload 0.029 +/- 0.0968 3 100 94.7 # # Automatically generated make config: don't edit # Linux kernel version: 2.6.12-ck3-r1 # Tue Jul 19 20:47:45 2005 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_MMU=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y # CONFIG_IKCONFIG is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set # CONFIG_KMOD is not set # # Processor type and features # CONFIG_MK8=y # CONFIG_MPSC is not set # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y # CONFIG_SMP is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y # CONFIG_NUMA is not set CONFIG_HPET_TIMER=y CONFIG_X86_PM_TIMER=y CONFIG_HPET_EMULATE_RTC=y # CONFIG_GART_IOMMU is not set CONFIG_DUMMY_IOMMU=y CONFIG_X86_MCE=y # CONFIG_X86_MCE_INTEL is not set # CONFIG_SECCOMP is not set CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_ISA_DMA_API=y # # Power management options # CONFIG_PM=y # CONFIG_PM_DEBUG is not set # CONFIG_SOFTWARE_SUSPEND is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y CONFIG_ACPI_AC=y CONFIG_ACPI_BATTERY
