Date: Fri, 01 Mar 2002 11:45:11 -0500 From: Glenn Gombert <ggombert@imatowns.com> To: Nathan Kunkee <nkunkee@umr.edu>, hackers@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: freebsd-hackers SMP performance question Message-ID: <3.0.6.32.20020301114511.00dafba0@imatowns.com> In-Reply-To: <20020301162258.GA24102@umr.edu> References: <bulk.31923.20020228114416@hub.freebsd.org> <bulk.31923.20020228114416@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
There are *many* issue(s) in -Current right now realted to KDE operationg (or not operating) as the case manybe. Older versions of KDE (2.1 for example) seem to run much better than the current 2.2 version. I have much better luck when running X in FreeBSD/Current by using a 'lighter weight' wm such as blackbox or icewm..... GG At 10:22 AM 3/1/2002 -0600, Nathan Kunkee wrote: >> >> I'm crossposting to freebsd-smp@freebsd.org, as per suggestion. >> >> My original post, edited: >> >> > > ... why any kernels compiled with SMP enabled seem >> > > to be slowing the whole system down? Throughput goes down by 40%. >> Tasks >> > > take twice as long to run, etc, etc... >> > > ... it appears to be system-wide. And is directly linked to >> > > SMP: two kernels, identical EXCEPT that one has SMP enabled, the other >> not. >> > > The enabled kernel that *should* be fully utilizing multi-procs is >> suddenly >> > > effectively running at half speed. >> >> Thanks to all for replies. >Since i am having the same problem, I'll tack my info next to yours and see if >both of us can get an answer. > >I'm using a dual P120, 64M ram, built my own SMP kernel, and have noticed the >same thing: performance/through put slows to nothing. my best example of this >is when in X I move the mouse. no mouse motion, ~6% cpu usage. move the mouse, >~40-55% usage. Are all interrupts being mapped to a single cpu?? > > >> >> Regarding my SMP query, Doc asks: >> > What sort of throughput? What sort of processes are you >> > running? Do you >> > actually have multiple processes fighting for CPU? >> >> Yes, I'm using netperf, iperf or nttcp to measure TCP throughput using the >> server (the box in question) in response to ten simultaneous clients. >> Chariot allegedly did not show the performance hit. But then, even >> measuring the process time to run a single simple script shows ~half the >> speed with SMP enabled. >> >Yes. does KDE with konqueror (and user ppp in background) count? konqueror is >so slow it is nearly unusable. I figured that dual cpus would provide closer >to my K6 233 performance, meaning comfortable interaction. building the kernel >(make -j2 depend; make -j2; make -j2 install) seems to take as long as a single >proc.. don't have actual wall clock time, got too bored. > >I also have some other quirks that i think are related. Occasionaly, my scsi >drive (ahb eisa) will timeout while trying to reset. loading an smp kernel helped >reduce this trouble, but not eliminate it. My sound card, which works fine AFAIK >in other machines, has timeout trouble in this one. how can i determine if >these are hardware troubles, or SMP related?? > >Is there a way to dynamicaly disable/enable a cpu? so that i can disable one and >see how that affects performance?? I tried sysctl machdep.smp_active=1, or =2, >but according to top, no difference. both procs are still getting programs and >time slices. > >> Chris F. asks: >> > Is this an old Pentium? If so, update to a recent -stable; >> > a fix was committed a few weeks ago fixing a problem where >> > the caches on both processors were not enabled on Pentiums. >> > Otherwise, we have a few PII and PIII boxes here that work >> > quite under 4.5. >> >> This includes multiple configurations, incl: dual PIII 700s, dual PIII 800s, >> quad PIII Zeon 550s, etc... No old procs, per se. I'm running the released >> version of 4.5. Was a proc-specific fix implemented *after* its release? >> >yes, p120. I will endeavor to setup and download the latest this weekend. will >take some time since i'm on dialup.... > >> Greg L states: >> > It would also be interesting to see if you get the same results >> > running 5-CURRENT. While this version isn't suited to production use, >> > it's based on a very different implementation, and the information >> > would help us work out what's going on here. >> >I will endeavor to get this d/l as well. again, dialup will not make this quick >or easy... > >> Unfortunately, I do not get a whole lot of time to get experimental due to >> compressed testing schedules but, if a hole opens up, I will attempt to get >> some testing done using 5-CURRENT. Will report any results to you. Thanks >> for your interest. >> >> This scenario has been replicated on several (virtually any and all) test >> boxes by multiple engineers. Any other tips are greatly appreciated. >> >> TIA - >> >> -=C. Stephen Frost=- >> Intel Corp. >> ICG - Network Quality Labs >> Software Test Engineer >> 503.264.8300 >> >> All opinions are my own, not those of Intel Corporation > >As well, thanks for all the information and help. > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-smp" in the body of the message > Glenn Gombert ggombert@imatowns.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.6.32.20020301114511.00dafba0>