SMP-64 to FreeBSD?

[bruce]

I have not used FreeBSD, but for other flavors of Linux, it has always been possible to load the libraries to allow 32-bit code to be run as well as 64-. It doesn't run in emulation mode -- the hardware is capable of processing 32-bit instructions as long as the library calls are supported. It's not too likely that they will create a special client, since all the client does is communicate with the internet, the user, and set up the FahCore with the data it can process. Converting that code to 64- will not improve it's speed/efficiency. (The work being done by the FahCore, itself, may or may not show some small improvements.)

Every time another version is created, it must receive testing, updates, and support "forever" and that makes the simple task of creating that version into an expensive and time-consuming process, especially whenever the next upgrade is prepared for distribution.

[bgalakazam]

Bumping this unsolved issue. Looks like 64bit Linux emulation won't be added anytime soon. The only alternative to running SMP in through a special 64bit package of Wine and then using the Windows client. This, of course, degrades performance.

Please, please, please, add a SMP FreeBSD native client! FreeBSD users are not contributing due to the fact of no native client. You support esoteric hardware like the PS3 and PPC, but you don't support a widely used OS??? FreeBSD even has CUDA in NVIDIA drivers now, you could do something with that as well.

A lot of servers run FreeBSD, it's a shame they can't use a native SMP client.

[pcfxer]

truth++;

[Zagen30]

I was trying to find some absolute figures about FreeBSD but could only find percentages that didn't tell me much. What's the estimated absolute usage of FreeBSD? The Pande Group has limited resources, and creating a new client takes a lot of time. They're not going to embark on a new client unless there's a major contribution gain to be had.

I'd hardly call the PS3 esoteric- while there weren't too many available when the PS3 client launched, the Pande Group could comfortably assume that there'd be tens of millions of them out there within a few years. A major factor in the PS3 client's creation was that Sony did a lot of the development, lifting a lot of the usual new client burden off of the Pande Group's shoulders, and at the time the PS3 was significantly more powerful than most traditional desktop setups out there.

PPC is certainly not widely used anymore, but the PPC client was created several years ago when Apple still used PPC processors, and even then there were a lot of Macs out there. At this point the PPC client is deprecated and will never be updated again; it doesn't cost the Pande Group anything to keep it going (maybe a bit of time to keep the work server up, but not much more), so they've left it running.

I'm not against FreeBSD or anything; it's just that PG has repeatedly stated that they have to prioritize what's supported based on what will provide the most benefit to the project.

[pcfxer]

http://bsdstats.org/

[Zagen30]

That's a sample; it says on the front page it's not representative of the total population. Are there ten thousand active FreeBSD installations out there? A hundred thousand? A million?

The total population of all BSD versions is actually probably more important than just FreeBSD, as I imagine one client would be made to run on all of them.

[pcfxer]

I'm not too sure, but I also don't know how many PS3s there are (some never connect to PSN), or how many Windows machines there are....or how many Linux machines there are.

Not too sure why Windows, Linux, etc. don't need FACTS yet FreeBSD is expected to have exact numbers...

[Zagen30]

No one's looking for exact numbers, but the Pande Group would look at the ballpark figure before delving into any client development. An OS that has roughly 50 thousand total copies in use is almost certainly not going to be targeted because the user base is much too small for the tiny fraction that would participate to be statistically significant. A userbase of 50 million is a lot more attractive because even a tiny percentage of that is still a decent number of contributors.

Sales figures of Windows and OSX aren't that hard to come by; Win7 shipped 240 million copies its first year, and Apple seems to ship around 3-3.5 million Macs a quarter, for somewhere around 12-14 million a year. Granted, a lot of those early Win7 sales were upgrades, but we're still talking hundreds of millions of new machines worldwide every year. Linux is harder to pin down since most of the installations weren't sales, but Ubuntu was supposedly on at least 12 million active PCs as of last year, and I've seen estimates of the total Linux userbase as being roughly 20 to 40 million. Worldwide PS3 sales are somewhere around 50 million.

[pcfxer]

There have been 20, 465 downloads of the Folding@Home PBI.

http://pbidir.com/bt/pbi/119?PDirSID=3f ... 6f43550a15

[Hyperlife]

PBIs before v9 only work with PC-BSD, not FreeBSD, AFAIK. I don't know of any current examples of FreeBSD users running PBIs instead of using the standard ports tree.

For what it's worth, I'm running two 32-bit FreeBSD servers with Wine and the Windows client without any noticeable performance degradation. I have to use the idprio command to set the priority of all Wine processes to 31 in order to keep the system from becoming sluggish, but it does work.

I'll be upgrading one of my servers to 64-bit FreeBSD soon, and I agree that using 32-bit Wine under 64-bit FreeBSD makes a kludgy workaround even kludgier.

I've already voiced my concern about the lack of attention given to v7 Ticket #584 elsewhere, as right now you can't even run the Linux version of v7 for uniprocessor folding on FreeBSD, but that's another issue entirely.

I'm curious as to whether the reason for not developing 32-bit Linux SMP cores still exists -- wasn't the issue poor MPI performance? But the current Windows client & cores no longer use MPI anymore, right?

[7im]

If MPI was the issue then, and it isn't an issue now, it's not the only consideration. fah is bumping up against the 4GB limit pretty hard with SMP bigadv, so 64 bit will be a hard requirement going forward. And PCs have supported 64 bit for a long time now (in PC years). This makes the duplicate development work to parallel the 64 bit fahcores with a 32 bit version even less attractive.

Also, if you look at the combined OS stats of other projects (all BOINC), FreeBSD comes in at ~5300 clients of a total ~6,000,000, or .08 percent. http://www.allprojectstats.com/top.php? ... t=0&type=8

When you consider the lowest client count by type for fah is Mac OSX, within 20x fewer total active clients than the above numbers, the Mac users still put up almost as many active systems as BSD does (~4600). If you scaled the 5300 number down accordindly, that's only 265 BSD systems, assuming BSD BOINC users would switch to fah in like numbers. 265 systems doesn't seem like a number that Pande Group would target for client development.

Even assuming the BSD users are only running BOINC because there is no alternative, and they can't stand BOINC and would flock to a new fah client in large numbers (very possible ), is 2x the usual client saturation enough (500 clients)? Even 4x the usual saturation (1000 clients) enough? No matter how hard fah has tried to be inclusive in the past, or continued to support OS's long past their life span, these kinds of questions have no easy answers.

Currently the focus is on getting V7 ready for public release to the 300,000+ active clients.

[Hyperlife]

If MPI was the issue then, and it isn't an issue now, it's not the only consideration. fah is bumping up against the 4GB limit pretty hard with SMP bigadv, so 64 bit will be a hard requirement going forward. And PCs have supported 64 bit for a long time now (in PC years). This makes the duplicate development work to parallel the 64 bit fahcores with a 32 bit version even less attractive.

Obviously 32-bit still matters on the Windows side of things, regardless of the 4GB limit, and probably will for quite some time. I'm a bit surprised that 32-bit Linux wasn't developed in tandem, but at this point, it's probably too late.

Also, if you look at the combined OS stats of other projects (all BOINC), FreeBSD comes in at ~5300 clients of a total ~6,000,000, or .08 percent. http://www.allprojectstats.com/top.php? ... t=0&type=8

I don't think using BOINC statistics to extrapolate FreeBSD folding numbers is a valid comparison, given that most BOINC projects won't run on FreeBSD or aren't officially supported (see http://boinc.berkeley.edu/projects.php and http://boinc.berkeley.edu/wiki/Project_list). BSD, on the other hand, is actually listed on the F@H client download page. Unfortunately, we'll never know the true number of FreeBSD folders due to the requirement of Wine or Linux emulation, which counts us as using another OS.

I'm not saying that there are as many BSD folders as OS X folders, but at the very least, v7 should continue F@H's longstanding support for FreeBSD, even if uniprocessor slots are all that we can do with Linux emulation.

Being a FreeBSD folder is probably a bit like being in a dysfunctional relationship -- even though we're not really welcome here anymore, we keep supporting it nonetheless.

[pcfxer]

"we keep supporting it"

After my own windows desktop with full SMP glory wouldn't pick up a WU because there was "no work" for an entire month...I decided to save my money and invest in my own charity and fundraising activities. Doing so actually multiplied my available time and money, allowing me to reach record highs for fundraising (over $2500 as compared to $500). I've seen far more come out of my charity work than F@H.

[7im]

I'm sorry you had an outdated or misconfigured client, but SMP has NEVER gone more than a day or two without work units when a server had hardware problems, or Stanford had a network outage.

In any case, good luck with your other endeavours.

[bruce]

Let's split this into distinct issues.
A) The expected client count for FreeBSD is a small number compared to other platforms.
B) The current Linux client can run if the Linux emulation libraries are loaded.
C) The current Linux client requires an OS with both 64-bit and 32-bit libraries.
D) The current Windows client can run under Wine emulation.
E) Installing on FreeBSD requires a different installation script than the ones that are provided for Linux/Windows/OSX, but the Linux code can be installed.
F) Emulation is assumed to be inefficient
G) (other?)

First of all, I contend that F is not true. FAH spends 99%+ of the time executing pure X86 or AMD64 computational code. That part of the code is independent of the OS. Rarely the computations are interrupted to do I/O, and that's the only time that emulation might cause a performance change. Since it's relatively rare, the overall effect must also be small.

Second, E can be overcome with the 3rd party script Finstall. I think we might be able to negotiate a way to include a script something like that one into V7. I'll open a ticket and see what development says.

Third, C is true for Linux, but not for Windows. Ticket #703 addresses a closely related issue: Allowing a 32-bit client to access either 32-bit cores ore 64-bit cores, depending on which OS is available. Presumably a 32-bit Linux client could be developed (if it hasn't already been developed) which would be smart enough to request WUs for which 64-bit cores exist or request WUs from the subset of projects for which 32-bit cores exist. NOTE: Some very important projects require a 64-bit core, and that's not going to change. As has already been stated, someday we may see times when there are no 32-bit WUs to be assigned.

OK, so what are you asking for?
1) A script that installs the 64-bit/32-bit Linux client on FreeBSD
2) A restricted 32-bit Linux client that can be installed with said script
3) Something else?

It should also be noted that Ticket #584 (accepted defect) points to some unresolved issues related to FreeBSD. That means that it has not been ruled out based on A but I can see how it would probably get a lower priority based on solving problems based on the number of clients affected by the issue.