Posts by Michael Goetz

1) Message boards : Projects : News on Project Outages (Message 56325)
Posted 30 Sep 2014 by Michael Goetz
Post:
Yeah, it's luck of the draw as to whether the other methods will work, but the definite way to get around waiting for the DNS change is to use the HOST file. That will always work -- but you have to remember to remove the entry in a day.
2) Message boards : Projects : News on Project Outages (Message 56315)
Posted 29 Sep 2014 by Michael Goetz
Post:
PrimeGrid is back up.

Please let us know on the PrimeGrid forums or in our chatroom if there's any problem. (I know the charts on the server status page aren't working yet. Everything else should be working.)

Please note that the IP address of the server changed. Although the new DNS entry should have propagated by now, some systems and programs don't see the new address. You may need to restart boinc or your web browser, reboot your computer, or run "ipconfig /flushdns" (or the equivalent) to access the new PrimeGrid server.
3) Message boards : Projects : News on Project Outages (Message 56306)
Posted 28 Sep 2014 by Michael Goetz
Post:
Update on PrimeGrid: We decided to take this opportunity to upgrade the main BOINC db and web server to newer hardware with SSDs instead of spinning magnetic museum pieces. We're also increasing the memory on the slave DB server. When we're done, all of the production hardware (including PRPNet) will be SSD. We're also upgrading the software, with newer versions of Linux, MySQL, etc. "Make lemonade out of lemons", so to speak.

If we were going to spend the time rebuilding one server, we might as well do all the upgrades we'd been thinking of doing "when we get around to it". (That's the nice thing about using cloud hosting: upgrading hardware takes a few clicks and a few minutes rather than weeks.)

Right now, we've got most of the software loaded and configured, but that last 10% always takes the most time. All the data is in place. Then we have to test everything and fix all the things we've inevitably forgotten.

Nothing, by the way, was lost. We're pretty good about backups and disaster recovery and stuff like that. Anything short of Armageddon we can handle. There may be some downtime while we rebuild servers, but the data is protected. We can survive losing a few data centers to nuclear bombs, as long as we don't lose ALL of them. :)
4) Message boards : Projects : News on Project Outages (Message 56294)
Posted 27 Sep 2014 by Michael Goetz
Post:
PrimeGrid seems to be down: from 11:00 UTC on 28 September until 24 hours later they were planning to go offline for maintenance. But already, their website is inaccessible, and BOINC event log states the feeder isn't running, so tasks can't be reported once complete. But uploading the tasks is completing successfully.


Yes, PrimeGrid is down.

We're not sure whether or not this outage is related to the planned maintenance scheduled for tomorrow. The BOINC server started having serious disk performance problems, and we haven't been able to correct them. At this point, we're rebuilding the server. This will take several hours, at least. During this time, the server will likely be completely down, including all the web pages and forums.

Our external chat page http://us14.chatzy.com/46334617429062 and can be used to communicate with us. I can also be reached via email at mgoetz {at} primegrid {dot} com.
5) Message boards : Questions and problems : Modern computers behave in wildly unpredictable ways ... (Message 31553)
Posted 12 Mar 2010 by Michael Goetz
Post:
I wouldn't worry about it.

Computers are no more (or no less) deterministic now than they were before.

I've been programming, designing, building, using, and playing with computers since the mid '70's. I've built computers out of everything from telephone relays (look up RODABS if you wish -- or not, it's so old even Google isn't finding it!), to modern LSIs with billions of transistors.

On the face of it, that article sounds so ludicrous that I was checking the date to make sure it wasn't April 1st.

Frankly, the article doesn't make it clear exactly what they claim the problem is. Simply having multiple threads or multiple processors (as every consumer computer utilizing at least hyperthreading has) introduces problems -- but these occur even in single thread processors due to the multi-threading abilities of the operating system. Every computer using any operating system more advanced than MS-DOS has had to deal with these issues, which fall under the category of what's called "concurrency problems".

This is a programming issue, not a hardware fault.

It's something that's been known to computer science for some 30 to 50 years, give or take, and there are, of course, ways to deal with it. Programs, especially those that take advantage of multithreading, need to be written in such a way as to prevent those problems from occurring. It doesn't make the computer unreliable unless the program doesn't account for the concurrency issues. That's a software bug, and the fault of the programmer; it's not due to an unreliable computer.

Unfortunately, the article doesn't really go into any detail at all, perhaps because they're not releasing any details until they do their presentation at the conference next week.

So, on the face of it, that article appears to be complete BS. If not an April 1st joke, it looks like something that would be published at "The Onion".

That being said, it's been my experience that when I think someone else is saying something utterly idiotic, it's usually because I either don't understand what they're saying or I don't have some vital information that they do. That might very well be the case here, since 1) it's not April 1st, 2) it's not published in "The Onion", 3) this is coming from people studying computer science, not agriculture (no offense intended to agriculture; I enjoy eating too.)

But the article itself doesn't really give us much to go on. Rather than speculating on what they're really talking about, if you're really worried, at least wait until they present the details next week.

But even without the details, if you accept the premise of their assertions verbatim, you should still realize that gazillions of WUs have been processed on multi-core computers without error. Even if there is some groundbreaking new truth to their work, this new 'fault' doesn't seem to be having much of an effect on BOINC processing.

So either way, I wouldn't worry about it.


6) Message boards : Projects : Separated stats for CPUs and GPUs (Message 24014)
Posted 30 Mar 2009 by Michael Goetz
Post:
I'm afraid that I'm going to have to disagree with you. Let me present the opposing viewpoint. Sure, optimized apps or (especially) GPU apps make non-GPU projects less appealing. But, in my opinion, they should.

Leaving aside people who see BOINC as some kind of contest, I assume that most of us are here to contribute to some sort of research. Credit is measure of how much work you're contributing. With optimized or GPU apps, the time/capacity/electricity/money you or I contribute is getting more bang for the buck.

If I give money to a charitable organization, I'd like to know that my money is being used efficiently and effectively. Same thing here -- I'd prefer that the computing hours I donate are being used effectively. Optimized apps and GPU apps don't just generate more credits; they do a lot more work. In the case of GPU apps, they do many times as much work as an equivalent CPU app. From what I'm seeing on various projects, GPU apps are doing about 10 to 100 times as much processing, depending on the CPU and GPU.

Here's an example. CPDN runs huge CPU workunits that can generate up to 25,000 credits per WU and take up to 100 days of CPU time even on a fast CPU. If another (fictitious) similar climate project appeared that was written to use GPUs instead, and could do the same work in 5 days, which project would be making better use of your equipment, assuming you could run the GPU application? The newer GPU project would be doing 20 times the work as CPDN. Why shouldn't it be serving up 20 times the credits? All other things being equal, it's a more worthy project to which to donate my resources.

Now, if you're saying that MW is serving up *excessive* credits for the work being done, that's different, and I would agree with you. But if your point is simply that projects that do more work due to smarter coding (optimized apps) or by utilizing super-computer-like hardware (GPUs), I have to disagree. More work is getting done in those circumstances, and credit is (theoretically) allocated based upon work being done. If a particular WU generates X credits, it should do so regardless of whether it takes a month to crunch on one machine or a minute to crunch on another machine.

Yes, I know there's a lot of grey area here, but this is my opinion. Which, of course, is worth no more nor no less than anyone else's opinion.

Mike



Copyright © 2024 University of California.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.