Hi All, @David: I hope you don't mind the reply-to-list.
Thanks for your suggestion. I agree that packet handling would be an interesting topic, but i can't really get an idea on how to actually test it. Of course, suggestions are welcome :-) In the meantime a made a script and did some general benchmarking. 1) dd'ing from /dev/zero to /dev/null, to see if and when we reach full memory bandwidth 2) dd'ing from /dev/urandom to /dev/null, to see how a kernel space CPU intensive task differs between SMP and non-SMP 3) Calculating 4000 digits of PI using BC, to see how a user space CPU intensive task differs between SMP and non-SMP All tests are done three times: With 1 proces, with 2 concurrent processes and with 3 concurrent processes. Of course these processes are doing the same thing, they are not 3 threads working on the same process. So in case of test 3 we're calculating PI 3 times. The script i made to do this is attached to this email, also a PDF export of the results is attached to this email. *** warning for the script *** I used "killall" to kill processes, on Linux this allows you to kill processes based on their name, but i understood that within *BSD it does what it says on the box and kills all processes on the system. My conlusions: Based on test 1 you can see a pure memory bound process doesn't gain or loose much with SMP. However, it never reached the full 1500 MB/s reported by memtest86+. Based on test 2 and 3 you can see a clear difference between SMP and non-SMP when it comes to CPU bound tasks. However, when i relate this to your specific case: When there was only one process running (ie. the packet handling process) there is barely a difference between SMP and non-SMP. However, i think you may gain from SMP when there are other processes running at the same time (syslog, whatever). Since there's not much to loose i'd go for SMP anyway. I don't think this will reflect 32bit vs. 64bit nicely, suggestions this this are welcome. Best regards, Wesley --- On Sat, 6/15/13, David Ruggiero <thatseattle...@gmail.com> wrote: > From: David Ruggiero <thatseattle...@gmail.com> > Subject: Re: [Soekris] net6501 : CPU architecture ? > To: "Wesley PA4WDH" <pa4...@yahoo.com> > Date: Saturday, June 15, 2013, 11:19 PM > Wesley - > > I'd be interested in any single-threaded benchmarks with SMP > vs > non-SMP - especially those involving ethernet packet > handling. > "Single-threaded" because I'm curious if SMP will still help > by > allowing the OS system functions to use some of the other > Hyper-thread > core, and if that happens if it's enough to overcome the > native extra > work that dealing with SMP causes. "Packet handling" because > the > overhead of interrupt service is something I'd like to > include in > that. > > You could do some sort of fake loopback using a crossover > cable coming > out of one eth port back into another. > > Though I'm using openBSD, this would be applicable to those > of us > using our machines mostly for PF (which is > single-threaded). > > But really, anything you come up with will be of interest! > > cheers > david > > > On Fri, Jun 14, 2013 at 10:43 AM, Wesley PA4WDH <pa4...@yahoo.com> > wrote: > > Hi All, > > > > I'm sorry to pick such an old topic again. > > > > --- On Wed, 5/15/13, David Ruggiero <thatseattle...@gmail.com> > wrote: > >> A few months ago I asked the question here about > what the > >> pros and > >> cons would be of running the OpenBSD SMP kernel > (bsd.mp) on > >> the > >> net6501, versus the standard uniprocessor kernel - > seeing > >> that the > >> E6XX series has HyperTransport and therefore > something > >> approximating > >> multiple cores. There wasn't, as I recall, any > consensus, or > >> even much > >> information at all (*). So from this discussion, as > far as I > >> can tell, > >> I have a choice of _four_ different OpenBSD kernels > that > >> could > >> legitimately be booted on my net6501 and would > probably > >> run: > >> > >> 32-bit i386 uniprocessor > >> 32-bit i386 SMP > >> 64-bit amd64 uniprocessor > >> 64-bit amd64 SMP > >> > >> I'm sure a similar list of possible alternatives > exists for > >> other BSD > >> variants and for Linux. > >> > >> A different company than Soekris might do some > quick > >> testing, or at > >> least provide some pithy engineering insight and > give its > >> customers a > >> quick rundown from their point of view on the > advantages > >> and > >> disadvantages of 32 vs 64bit and non-smp vs smp - > whether in > >> general, > >> or for specific common application needs. But at > the risk of > >> being > >> flamed here, I'll say that I'm not holding my > breath for > >> any > >> information like that from the company anytime > soon... > >> > >> If anyone has data points around these questions > from actual > >> personal > >> experience and actual real-world testing, like > Kyle's, I'm > >> sure many > >> would be grateful for that. > > > > I just received my 6501 and i don't have any disks yet. > However, i'm able to boot into 32bit 64bit linux kernels and > i'm able to enable/disable SMP. > > The kernel version will be 2.6.37 with some Gentoo > patches. > > > > Since i can't yet use it for what i planned to do with > it i'm happy to do some performance testing. Anything that > doesn't take too much disk space or requires installation of > additional packages is possible. Just keep in mind that > whatever i boot, userspace will always be 32bit. If it's > really nescessary i can see if i can change that but i > rather not. > > > > Any test suggestions ? > > > > Best regards, > > Wesley > > _______________________________________________ > > Soekris-tech mailing list > > Soekris-tech@lists.soekris.com > > http://lists.soekris.com/mailman/listinfo/soekris-tech >
results.pdf
Description: application/download
benchmark.sh
Description: application/shellscript
_______________________________________________ Soekris-tech mailing list Soekris-tech@lists.soekris.com http://lists.soekris.com/mailman/listinfo/soekris-tech
