Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On Tue, Dec 20, 2011 at 03:29:25PM -0800, Jeremy Chadwick wrote: > > This also interested me: > > * Linux system crashed > http://leaf.dragonflybsd.org/mailarchive/kernel/2011-11/msg8.html > > * OpenIndiana system crashed same way as Linux system > http://leaf.dragonflybsd.org/mailarchive/kernel/2011-11/msg00017.html > > I cannot help but wonder if the Linux and OpenIndiana installations were > more stressful on the hardware -- getting more out of the system, maybe > resulting in increased power/load, which in turn resulted in the systems > locking up (shoddy PSU, unstable mainboard, MCH problems, etc.). > > My point is that Francois states these things in such a way to imply > that "DragonflyBSD was more stable", Same thing can be said for FreeBSD, only Linux and OpenIndiana crashed reliably if I remember correctly. > when in fact I happen to wonder the > opposite point -- that is to say, Linux and OpenIndiana were trying to > use the hardware more-so than DragonflyBSD, thus tickled what may be a > hardware-level problem. I actually ran the benchmarks on two different machines with the same hardware -- brand new Supermicro boxes with ECC memory and no cut corners. Since then, I've found I could stop the Linux crashes by disabling some options in the BIOS setup: - advanced ACPI settings (don't remember exactly which ones) - and a new WHEA one. WHEA means Windows Hardware Error Architecture. For all I know, it may have been the only culprit but I didn't have time to verify if the machines also ran fine with only this option disabled. -- Francois Tigeot ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Is the svn2cvs gateway down ?
On 21. Dec 2011, at 02:23 , Doug Barton wrote: > On 12/20/2011 02:01, Claude Buisson wrote: >> Hi, >> >> It seems (from my own csup's and cvswe.cgi) that the src commits are lost, >> starting with r228697 Sun Dec 18 22:04:55 2011) > > Yeah, my warning 2 days ago that this was going to happen seems to have > gone un-heeded. :) I'm sure you can take bz' word that it's being > looked at now though. It's been fixed and the changes should propagate to cvsup mirrors close to everyone the next two hours. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Unbalanced timer interrupts under VMWare?
I have a strange situation on a VMWare 5-hosted machine: # vmstat -i interrupt total rate irq1: atkbd0 74 0 irq6: fdc011 0 irq15: ata1 17 0 irq18: em0 42122 1 cpu0:timer 2246291 54 irq256: mpt0 141402 3 cpu1:timer280800 6 Total2710717 65 The cpu0 timer interrupt rate is 54 Hz and cpu1 rate is 6 Hz. The same is visible when monitoring the system in real time with "systat -vm". This is a default FreeBSD 9 RC3 amd64 system, HZ is the default 100. Unless the tickless kernel project has advanced more than I think, this looks like a problem... so I looked elsewhere and it turns out I cannot get more than about 55 interrupts/s with the disk controller either. Any ideas? I have another host running VMware 5 but only an 8-stable machine in it, which works fine. Does anyone else run 9.x on VMware 5? The host is a Xeon X3360 CPU (4 cores, no HTT, 2.8 GHz). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
REMAINDER: Call for FreeBSD Status Reports - 4Q/2011
Dear all, I would like to remind you that the next round of status reports covering the fourth quarter of 2011 are due on January 15th, 2011. As this initiative is very popular among our users, I would like to ask you to submit your status reports as sooner than later (holidays are quickly approaching), so that we can compile the report in a timely fashion. Do not hesitate and write a few lines; a short description about what you are working on, what your plans and goals are, or any other information that you consider interested is always welcome. This way we can inform our community about your great work! Check out the reports from the past to get some inspiration of what your submission should look like. If you know about a project that should be included in the status report, please let us know as well, so we can poke the responsible people to provide us with something useful. Updates to submissions from the last report are welcome as well. Note that the submissions are accepted from anyone involved within the FreeBSD community, you do not have to be a FreeBSD committer. Anything related to FreeBSD can be covered. Please email us the filled-in XML template which can be found at http://www.freebsd.org/news/status/report-sample.xml to mont...@freebsd.org, or alternatively use our web based form located at http://www.freebsd.org/cgi/monthly.cgi. For more information, please visit http://www.freebsd.org/news/status/. We are looking forward to see your submissions! -- Kind regards Daniel Gerzo ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Unbalanced timer interrupts under VMWare?
Hello! On Wed, Dec 21, 2011 at 12:02:04PM +0100, Ivan Voras wrote: > I have a strange situation on a VMWare 5-hosted machine: > > # vmstat -i > interrupt total rate > irq1: atkbd0 74 0 > irq6: fdc011 0 > irq15: ata1 17 0 > irq18: em0 42122 1 > cpu0:timer 2246291 54 > irq256: mpt0 141402 3 > cpu1:timer280800 6 > Total2710717 65 > > The cpu0 timer interrupt rate is 54 Hz and cpu1 rate is 6 Hz. The > same is visible when monitoring the system in real time with "systat > -vm". > > This is a default FreeBSD 9 RC3 amd64 system, HZ is the default 100. > Unless the tickless kernel project has advanced more than I think, It is, actually. Many thanks to mav@ for his amazing work. $ sysctl kern.eventtimer.periodic kern.eventtimer.periodic: 0 $ vmstat -i | grep timer cpu0:timer 72769640 47 And down to 37 i/s as seen in "systat -vm". Idle virtual machine now takes 2 times less CPU on my laptop as seen from the host. > this looks like a problem... so I looked elsewhere and it turns out > I cannot get more than about 55 interrupts/s with the disk > controller either. Happily goes to 6k i/s here (though it's under VirtualBox and a bit old -current, not 9.0). (Just in case: note that vmstat report rate since boot, "systat -vm" may be better to look at current values.) > Any ideas? I have another host running VMware 5 but only an 8-stable > machine in it, which works fine. Does anyone else run 9.x on VMware > 5? > > The host is a Xeon X3360 CPU (4 cores, no HTT, 2.8 GHz). Maxim Dounin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Unbalanced timer interrupts under VMWare?
On 21.12.2011. 14:48, Maxim Dounin wrote: Hello! On Wed, Dec 21, 2011 at 12:02:04PM +0100, Ivan Voras wrote: Unless the tickless kernel project has advanced more than I think, It is, actually. Many thanks to mav@ for his amazing work. $ sysctl kern.eventtimer.periodic kern.eventtimer.periodic: 0 $ vmstat -i | grep timer cpu0:timer 72769640 47 Ah, great! I missed that commit :) Thanks mav! And down to 37 i/s as seen in "systat -vm". Idle virtual machine now takes 2 times less CPU on my laptop as seen from the host. this looks like a problem... so I looked elsewhere and it turns out I cannot get more than about 55 interrupts/s with the disk controller either. Happily goes to 6k i/s here (though it's under VirtualBox and a bit old -current, not 9.0). Yes, it looks like it's not related to the tickless mode, the disk IO is slow even when kern.eventtimer.periodic=1. Something else is broken. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: directory listing hangs in "ufs" state
On 15.12.2011 17:01, Kostik Belousov wrote:
On Thu, Dec 15, 2011 at 03:51:02PM +0400, Andrey Zonov wrote:
On Thu, Dec 15, 2011 at 12:42 AM, Jeremy Chadwick
wrote:
On Wed, Dec 14, 2011 at 11:47:10PM +0400, Andrey Zonov wrote:
On 14.12.2011 22:22, Jeremy Chadwick wrote:
On Wed, Dec 14, 2011 at 10:11:47PM +0400, Andrey Zonov wrote:
Hi Jeremy,
This is not hardware problem, I've already checked that. I also ran
fsck today and got no errors.
After some more exploration of how mongodb works, I found that then
listing hangs, one of mongodb thread is in "biowr" state for a long
time. It periodically calls msync(MS_SYNC) accordingly to ktrace
out.
If I'll remove msync() calls from mongodb, how often data will be
sync by OS?
--
Andrey Zonov
On 14.12.2011 2:15, Jeremy Chadwick wrote:
On Wed, Dec 14, 2011 at 01:11:19AM +0400, Andrey Zonov wrote:
Have you any ideas what is going on? or how to catch the problem?
Assuming this isn't a file on the root filesystem, try booting the
machine in single-user mode and using "fsck -f" on the filesystem in
question.
Can you verify there's no problems with the disk this file lives on as
well (smartctl -a /dev/disk)? I'm doubting this is the problem, but
thought I'd mention it.
I have no real answer, I'm sorry. msync(2) indicates it's effectively
deprecated (see BUGS). It looks like this is effectively a mmap-version
of fsync(2).
I replaced msync(2) with fsync(2). Unfortunately, from man pages it
is not obvious that I can do this. Anyway, thanks.
Sorry, that wasn't what I was implying. Let me try to explain
differently.
msync(2) looks, to me, like an mmap-specific version of fsync(2). Based
on the man page, it seems that the with msync() you can effectively
guaranteed flushing of certain pages within an mmap()'d region to disk.
fsync() would flush **all** buffers/internal pages to be flushed to
disk.
One would need to look at the code to mongodb to find out what it's
actually doing with msync(). That is to say, if it's doing something
like this (I probably have the semantics wrong -- I've never spent much
time with mmap()):
fd = open("/some/file", O_RDWR);
ptr = mmap(NULL, 65536, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
ret = msync(ptr, 65536, MS_SYNC);
/* or alternatively, this:
ret = msync(ptr, NULL, MS_SYNC);
*/
Then this, to me, would be mostly the equivalent to:
fd = fopen("/some/file", "r+");
ret = fsync(fd);
Otherwise, if it's calling msync() only on an address/location within
the region ptr points to, then that may be more efficient (less pages to
flush).
They call msync() for the whole file. So, there will not be any difference.
The mmap() arguments -- specifically flags (see man page) -- also play
a role here. The one that catches my attention is MAP_NOSYNC. So you
may need to look at the mongodb code to figure out what it's mmap()
call is.
One might wonder why they don't just use open() with the O_SYNC. I
imagine that has to do with, again, performance; possibly the don't want
all I/O synchronous, and would rather flush certain pages in the mmap'd
region to disk as needed. I see the legitimacy in that approach (vs.
just using O_SYNC).
There's really no easy way for me to tell you which is more efficient,
better, blah blah without spending a lot of time with a benchmarking
program that tests all of this, *plus* an entire system (world) built
with profiling.
I ran for two hours mongodb with fsync() and got the following:
STARTED INBLK OUBLK MAJFLT MINFLT
Thu Dec 15 10:34:52 2011 3 192744314 3080182
This is output of `ps -o lstart,inblock,oublock,majflt,minflt -U mongodb'.
Then I ran it with default msync():
STARTED INBLK OUBLK MAJFLT MINFLT
Thu Dec 15 12:34:53 2011 0 7241555 79 5401945
There are also two graphics of disk business [1] [2].
The difference is significant, in 37 times! That what I expected to get.
In commentaries for vm_object_page_clean() I found this:
* When stuffing pages asynchronously, allow clustering. XXX we need a
* synchronous clustering mode implementation.
It means for me that msync(MS_SYNC) flush every page on disk in single IO
transaction. If we multiply 4K and 37 we get 150K. This number is size of
the single transaction in my experience.
+alc@, kib@
Am I right? Is there any plan to implement this?
Current buffer clustering code can only do only async writes. In fact, I
am not quite sure what would consitute the sync clustering, because the
ability to delay the write is important to be able to cluster at all.
Also, I am not sure that lack of clustering is the biggest problem.
IMO, the fact that each write is sync is the first problem there. It
would be quite a work to add the tracking of the issued writes to the
vm_object_page_clean() and down the stack. Esp. due to custom page
write vops in several fses.
The only guarantee that POSIX requires from msync(MS_SYNC) is that
the writes are finished when
"required by"?
Hello guys! I got a question concerning dependencies.. Is there a method to check what depends on a given port? What do I have to do to check what depends on - say - gconf? I know that there's a way to check what gconf depends on (via checking freshports.org for example), but what about the other way around? Thanks in advance, greetings from Cologne, 1126! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: "required by"?
On 12/21/2011 1:30 PM, 1126 wrote: > Hello guys! > > I got a question concerning dependencies.. Is there a method to check > what depends on a given port? What do I have to do to check what depends > on - say - gconf? I know that there's a way to check what gconf depends > on (via checking freshports.org for example), but what about the other > way around? Try pkg_info -r and -R eg pkg_info -R m4-1.4.16,1 Information for m4-1.4.16,1: Required by: autoconf-2.68 automake-1.11.1 bison-2.4.3,1 # pkg_info -r automake-1.11.1 Information for automake-1.11.1: Depends on: Dependency: perl-threaded-5.14.1_3 Dependency: m4-1.4.16,1 Dependency: automake-wrapper-20101119 Dependency: autoconf-wrapper-20101119 Dependency: autoconf-2.68 Another way is described at http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports-finding-applications.html ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
Hi, while the discussion continued here, some work started at some other place. Now... in case someone here is willing to help instead of talking, feel free to go to http://wiki.freebsd.org/BenchmarkAdvice and have a look what can be improved. The page is far from perfect and needs some additional people which are willing to improve it. This is only part of the problem. A tuning page in the wiki - which could be referenced from the benchmark page - would be great too. Any volunteers? A first step would be to take he tuning-man-page and wikify it. Other tuning sources are welcome too. Every FreeBSD dev with a wiki account can hand out write access to the wiki. The benchmark page gives contributor-access. If someone wants write access create a FirstnameLastname account and ask here for contributor-access. Don't worry if you think your english is not good enough, even some one-word notes can help (and _my_ english got already corrected by other people on the benchmark page). Bye, Alexander. -- Send via an Android device, please forgive brevity and typographic and spelling errors. "O. Hartmann" hat geschrieben:On 12/20/11 21:20, Igor Mozolevsky wrote: > Interestingly, while people seem to be (arguably rightly) focused on > criticising Phoronix's benchmarking, nobody has offered an alternative > benchmark; and while (again, arguably rightly) it is important to > benchmark real world performance, equally, nobody has offered any > numbers in relation to, for example, HTTP or SMTP, or any other "real > world"-application torture tests done on the aforementioned two > platforms... IMO, this just goes to show that "doing is hard" and > "criticising is much easier" (yes, I am aware of the irony involved in > making this statement, but someone has to!) > > > Cheers, > Igor M :-) Unfortunately, M. Larabel is the only one who's performing benchmarks on FreeBSD, comparing its performance to the Linux-opponents. Adn indeed, there is a lot of criticism, but no alternative. I said unfortunately - not offensive - since Larabel and Phoronix are sadly the only ones who do actually such bechmarking. It would be much more nicer and kind to support those people. Well, in January/February we get new hardware. One box is supposed to do number crunching via 12 cores and a TESLA GPU. My colleague is developing a high parallelized peice of software for satellite data transformation. The software package is CPU bound, partially GPU, but massively memory hungry (96 to 128 GB RAM is needed). What I can offer is, since I will also work on that machine and I've free hand to administer, in the spare time of doing my PhD, installing FreeBSD 9.0/10.0 besides SuSe Linux and looking forward having one ZFS data storage drive for homes, so both systems can perform on a most recent ZFS. I'm new to Linux, not a BSD guru, nor I'm a professional programmer/developer. My skills are sufficient for the daily scientific work. So, without pressure, I'm willing to perform some HPC benchmarks under advice if the day comes and those interested in bare numbers of FreeBSD vs. Linux performance with a real-world-scientific application. I would appreciate to see some of the developers and/or FreeBSD hackers to help Phoronix setting up a proper testenvironment instead of bashing M. Larabel and his fellows. Regards, Oliver ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: "required by"?
Once you have a port installed, "pkg_info -R gconf\*" will tell you. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 9 RC3 and VirtualBox
On Wed, Dec 21, 2011 at 2:22 PM, Joshua Boyd wrote: > Thanks. > Nevermind. This "new" work computer is 64 bit but doesn't have the right chipset features to support 64bit guests. Lame. Sorry for the noise. -- Joshua Boyd E-mail: boy...@jbip.net http://www.jbip.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
FreeBSD 9 RC3 and VirtualBox
I'm unable to install RC3 on VirtualBox, I receive the following error: CPU doesn't support long mode > > Consoles: internal video/keyboard > BIOS drive C: is disk0 > BIOS 639kB/1047552kB available memory > > FreeBSD/x86 bootstrap loader, Revision 1.1 > (r...@farrell.cse.buffalo.edu, Sun Dec 4 07:50:52 UTC 2011) > Can't work out which disk we are booting from. > Guess BIOS device 0x not found by probes, defaulting to disk0: > FATAL: int13_harddisk: function 42. Can't use 64bits lba > I've tried a few different controller combinations (SAS/SATA/IDE), but none seem to fix the problem. Any help would be cool. Thanks. -- Joshua Boyd E-mail: boy...@jbip.net http://www.jbip.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 9 RC3 and VirtualBox
Joshua Boyd schreef: On Wed, Dec 21, 2011 at 2:22 PM, Joshua Boyd wrote: Thanks. Nevermind. This "new" work computer is 64 bit but doesn't have the right chipset features to support 64bit guests. Lame. Sorry for the noise. Sometimes a new BIOS version get the needed 64bits virtual support! regards, Johan Hendriks ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 9 RC3 and VirtualBox
On 12/21/2011 2:22 PM, Joshua Boyd wrote: > I'm unable to install RC3 on VirtualBox, I receive the following error: > > CPU doesn't support long mode >> >> Consoles: internal video/keyboard >> BIOS drive C: is disk0 >> BIOS 639kB/1047552kB available memory >> >> FreeBSD/x86 bootstrap loader, Revision 1.1 >> (r...@farrell.cse.buffalo.edu, Sun Dec 4 07:50:52 UTC 2011) >> Can't work out which disk we are booting from. >> Guess BIOS device 0x not found by probes, defaulting to disk0: >> FATAL: int13_harddisk: function 42. Can't use 64bits lba >> > > I've tried a few different controller combinations (SAS/SATA/IDE), but none > seem to fix the problem. > > Any help would be cool. Actually, I got the same thing with RC3 the other day. But I went to try again just now and it worked. I used FreeBSD-9.0-RC3-amd64-bootonly.iso and it worked just fine. Since the first time I did install the latest version of Virtual box so not sure what changed in there, or it was something else. But the machine its on is running Windows 2008, so it did support amd64 when I had the failure. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: SCHED_ULE should not be the default
On Fri, Dec 16, 2011 at 12:14:24PM +0100, Attilio Rao wrote: > 2011/12/15 Steve Kargl : > > On Thu, Dec 15, 2011 at 05:25:51PM +0100, Attilio Rao wrote: > >> > >> I basically went through all the e-mail you just sent and identified 4 > >> real report on which we could work on and summarizied in the attached > >> Excel file. > >> I'd like that George, Steve, Doug, Andrey and Mike possibly review the > >> few datas there and add more, if they want, or make more important > >> clarifications in particular about the Xorg presence (or rather not) > >> in their workload. > > > > Your summary of my observations appears correct. > > > > I have grabbed an up-to-date /usr/src, built and > > installed world, and built and installed a new > > kernel on one of the nodes in my cluster. ??It > > has > > > > It seems a perfect environment, just please make sure you made a > debug-free userland (setting MALLOC_PRODUCTION in jemalloc basically). > > The first thing is, can you try reproducing your case? As far as I got > it, for you it was enough to run N + small_amount of CPU-bound threads > to show performance penalty, so I'd ask you to start with using dnetc > or just your preferred cpu-bound workload and verify you can reproduce > the issue. > As it happens, please monitor the threads bouncing and CPU utilization > via 'top' (you don't need to be 100% precise, jut to get an idea, and > keep an eye on things like excessive threads migration, thread binding > obsessity, low throughput on CPU). > One note: if your workloads need to do I/O please use a tempfs or > memory storage to do so, in order to reduce I/O effects at all. > Also, verify this doesn't happen with 4BSD scheduler, just in case. > > Finally, if the problem is still in place, please recompile your > kernel by adding: > options KTR > options KTR_ENTRIES=262144 > options KTR_COMPILE=(KTR_SCHED) > options KTR_MASK=(KTR_SCHED) > > And reproduce the issue. > When you are in the middle of the scheduling issue go with: > # ktrdump -ctf > ktr-ule-problem-YOURNAME.out > > and send to the mailing list along with your dmesg and the > informations on the CPU utilization you gathered by top(1). > > That should cover it all, but if you have further questions, please > just go ahead. Attilio, I have placed several files at http://troutmask.apl.washington.edu/~kargl/freebsd dmesg.txt --> dmesg for ULE kernel summary--> A summary that includes top(1) output of all runs. sysctl.ule.txt --> sysctl -a for the ULE kernel ktr-ule-problem-kargl.out.gz I performed a series of tests with both 4BSD and ULE kernels. The 4BSD and ULE kernels are identical except of course for the scheduler. Both witness and invariants are disabled, and malloc has been compiled without debugging. Here's what I did. On the master node in my cluster, I ran an OpenMPI code that sends N jobs off to the node with the kernel of interest. There is communication between the master and slaves to generate 16 independent chunks of data. Note, there is no disk IO. So, for example, N=4 will start 4 essentially identical numerically intensity jobs. At the start of a run, the master node instructs each slave job to create a chunk of data. After the data is created, the slave sends it back to the master and the master sends instructions to create the next chunk of data. This communication continues until the 16 chunks have been assigned, computed, and returned to the master. Here is a rough measurement of the problem with ULE and numerical intensity loads. This command is executed on the master time mpiexec -machinefile mf3 -np N sasmp sas.in Since time is executed on the master, only the 'real' time is of interest (the summary file includes user and sys times). This command is run at 5 times for each N value and up to 10 time for some N values with the ULE kernel. The following table records the average 'real' time and the number in (...) is the mean absolute deviations. # N ULE 4BSD # - # 4223.27 (0.502) 221.76 (0.551) # 5404.35 (73.82) 270.68 (0.866) # 6627.56 (173.0) 247.23 (1.442) # 7475.53 (84.07) 285.78 (1.421) # 8429.45 (134.9) 223.64 (1.316) These numbers to me demonstrate that ULE is not a good choice for a HPC workload. If you need more information, feel free to ask. If you would like access to the node, I can probably arrange that. But, we can discuss that off-line. -- Steve ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 9 RC3 and VirtualBox
Joshua Boyd wrote: > This "new" work computer is 64 bit but doesn't have the right > chipset features to support 64bit guests. > > Lame. Perhaps that sort of machine should be referred to as 63-bit, since it is a bit short of full 64-bit capability :) [ducks & runs] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 9 RC3 and VirtualBox
On Wed, Dec 21, 2011 at 1:30 PM, Joshua Boyd wrote: > On Wed, Dec 21, 2011 at 2:22 PM, Joshua Boyd wrote: > > > Thanks. > > > > Nevermind. This "new" work computer is 64 bit but doesn't have the right > chipset features to support 64bit guests. > > Lame. > > Sorry for the noise. > VT-x(or the AMD equiv) is a CPU feature and is necessary to run 64-bit guests. VT-d(or the AMD equiv)/IOMMU is the what is done in the chipset however it isn't necessary to run 64-bit guests. Both of these features are only found on CPU's supporting long mode. -- Adam Vande More ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
