Date: Thu, 28 Feb 2002 15:46:16 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: "Frost, Stephen C" <stephen.c.frost@intel.com> Cc: "'freebsd-smp@freebsd.org'" <freebsd-smp@FreeBSD.ORG> Subject: RE: FreeBSD, SMP and Performance Speeds? Message-ID: <Pine.BSF.4.21.0202281538030.6492-100000@InterJet.elischer.org> In-Reply-To: <5.1.0.14.0.20020301001536.01cd5610@mail.drwilco.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 1 Mar 2002, Rogier R. Mulhuijzen wrote: > > Frost, Stephen C says: > >Regarding my SMP query, Doc asks: [...] > > > >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. That sounds wrong if the system is being compared to a UP kernel. What is the script actually DOING? > > I'm no expert but I'm going to have a shot at this anyways. Comments are > welcome. =) > > When you run a benchmark or a process where network performance is the > bottleneck instead of CPU time, you're not going to have SMP help you at > all. Currently in the 4.X kernels the kernel can run on only one CPU at a > given time. That means that when raw network performance is the bottleneck > only one CPU is actually doing the work, and running in SMP mode gives you > a lot of overhead. > > The same is true for a situation where a single single-threaded process is > involved. A single-threaded process can only run on one CPU at a given > time, so having a 2nd CPU only adds overhead. > > Have you tried running 4 jobs simultaneously and timing that? > > So what sort of application are you using exactly, is it multi-process, > multithreaded, CPU intensive, network intensive? Where do you think the > bottleneck in the performance lies at this moment? To expand on this: WHile it may be that we can inprove the throughput of your TCP stack with some tuning, it is true that 4.x SMP will only show a gain for compute bound user processes running in parallel. This is the reason for all the work being done in 5.x. Stephen, If you could tell us a little more about th e exact tests you are seeing we may be able to improve them a little but it's unlikely that we can do much about network throughput.. This is the same problem that Linux had in their earlier MP kernels. It is possible that we can reduce the contention fot the kernel by tuning things if we knew exactly what the system, was doing, but it's also possible that we can't.. The 40% drop (or was that 40% of throughput?) seems a bit much so it's likely we can do SOMETHING. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0202281538030.6492-100000>