We are updating the database currently. The server will be down.
As of 1:30 pm EST.

It would be nice if we could have the WU limit increased and maybe the deadline decreased a bit so when things like this happen we can keep crunching. I'm using a Volta based card and 80 WU are gone in a couple minutes.

Hey vseven,

We have to walk a fine line with the number of workunits we allow users to download and their deadlines. We have both CPUs and GPUs that we have to balance with vastly different work times. I think what we have now is a reasonable compromise, but I would be open to hearing your suggestions.

Jake

Just have to say I think it's a bad day having maintenance on a Tuesday since many SETI users have Milkyway as backup project, which also have maintenance on Tuesdays... (Also, maybe some Milkyway users have SETI as backup)

Hey JohnDK,

I had no idea their maintenance day was Tuesday. We just picked this day because its one of the two days that Jeff is in the office. This won't be too common of an occurrence and will consider switching to Thursdays. I just wanted to avoid being so close to the weekend when starting maintenance.

Jake

The database is still updating I am watching this through completion. I am expecting late tonight early tomorrow morning to have the feeder dishing out units.

It would be nice if we could have the WU limit increased and maybe the deadline decreased a bit so when things like this happen we can keep crunching. I'm using a Volta based card and 80 WU are gone in a couple minutes.

80 Workunits per Gpu are really too small.. if server is down in less then half hour (on 7970) you run out of work.. i understand that maybe with CPUs could be reasonable.. but "hardcore business" is made of GPUs

Any update on the expected time for the maintenance to end? I have a computer with 72 wu's on it that needs to be reformatted today.

IMHO, the database server seems to be the weakest link in your system. A DBMS is the most processor and storage intense application in a system like this. RPI really needs a server with enough cores and solid-state memory to handle the throughput required to manage a grid computing environment, especially if the DBMS is enforcing referential integrity. Intel might give RPI some hardware help if they ask.
Yes, I know you think "Yes, we already know that." However, do the people with the purse know that? If they are not listening, maybe forwarding this message might get their attention. Overloaded servers breakdown at the most inconvenient times. The cost and time of RPI's most talented people should be considered in the total cost of ownership.

---

Hey Everyone,

Our database maintenance is coming to a close. We should be done by the 5pm today. It has been several months since we were down for maintenance last so it is taking us a little while to clean everything up.

As far as future plans, it is actually within our budget to upgrade the server and we plan to do that within the next few months. Otherwise, we have a few maintenance periods planned in the upcoming weeks to help optimize the database. In the last few months, it has been running pretty smoothly, but we think we can continue to improve it.

Thank you all for your continued support.
Jake

Thanks for the update, Jake!

Thank you Jake.
But i expect a lot of problem when all will start again normally.
I think there will be million of WU who will be reported at the same time.
I hope it will not crash the server.
In fact, the limitation of 80WU is not a bad idea.
Already one day, all my WU are finished and unable to get any new
I understand, sometimes it is needed to make a big clean.
For sure for DB.
Thanks for update.

Jake wrote -

"We have to walk a fine line with the number of workunits we allow users to download and their deadlines. We have both CPUs and GPUs that we have to balance with vastly different work times. I think what we have now is a reasonable compromise, but I would be open to hearing your suggestions."

I understand you have to vary the number of workunits a user can download. But, the number should be based on the capabilities of the users' computer not some arbitrary number (80) that implies that one number fits all, whether it refers to CPU or GPU workunits.

Your scheduling (workunit dispersal) algorithm knows everything about a user's computer (average computational time, number of invalid returns, up-time, etc.).

It shouldn't be that hard for someone at a prestigious university like RPI to figure out a more equitable way of dispersing workunits. Fast computers get more, slow computers get less, "bad actors" get few.

If my computer is returning valid results, and each workunit (GPU) takes 3 minutes, what is the problem with giving me 480 units (1 day), or 960 units (2 days), or more?

The algorithm, if properly done, should work for CPU and GPU workunits.

Work units are coming back in and the feeder should be serving them out again. I am monitoring. There will be a few hours as the load balances let me know if you see anything on your side as that processes through.

I had 160 process through, but no more picked up. I'm sure it is being resolved.

I got 34 but nothing more since then, I assume the transitioner being offline must have something to do with it.

---

Milkyway@Home is working again but unfortunately I don't get any GPU workunits (no changes to settings).

I have workunits for my pc's but when I look at the workunits status I see that ALOT of them have NOT been sent out to a wingman yet!! They say "unsent", prior to this maintenance phase I had zero "unsent" tasks.

Yes, I can confirm this!

I currently have 304 "in progress" to my different computers, but none of them seems to have a "wing man".

The same goes for the ones that I've completed and reported, and that is now in "Validation inconclusive".

My heap of "Validation inconclusive" is constantly growing, and is already 267, while none of my reported tasks seems to be validated.
Credits totally stuck! :-(

What is happening???

//Gunnar

Yep, all of my WUs are _0 as well, so it looks like _1 are kept behind for now. What went wrong after the restart of the machines?

---

Grüße vom Sänger