The server will be down for scheduled maintenance on Friday while we update the server and client to allow for work unit bundling. The code for this update is written and currently undergoing testing. This should allow for longer work unit times while maintaining fast crunching for single likelihood values. The result should be lower traffic on the database providing for more stability on the server while providing more work units for everyone.

I apologize for the issues we have been having recently with work unit availability and server stability. Hopefully this will be a permanent solution. If you have any questions please let me know.

This will not effect the way points are allocated by the project. I am using a simple formula for calculating credits and that is (Number of credits per work unit) * (Number of work units crunched in a bundle) = (awarded credit). Seems like a pretty reasonable way of doing things to me and might actually improve your credit generation since the overhead should be reduced slightly.

As for increasing work unit stashes in the mean time while the server is down, this is not possible. The whole reason for the maintenance and server/client update is to improve our throughput on workunits while decreasing load on the server/database. If I could give you a stash of work units before the server went down, I wouldn't need to do the maintenance. My goal is for the maintenance to be quick (<1 hour) however as we all know, big updates never go as planned. I am allocating myself the entire day (8hours) to debug and issues that might arise due to this update and of course I will check in over the weekend as well.

The plan for the beginning is to start conservatively with 10 work units per bundle. Depending on how the CPU only crunchers handle this (about 5-10 hours of work per bundle) we can then decide to increase it. The current code is written to allow for an arbitrary number of work units to be bundled together so I can change it rather easily.

It is also possible I may put up different runs using different numbers of bundled work units so one bundle may have 10 and the other may have 100. There are a lot of cool things I can do once I get this running.

The plan for the beginning is to start conservatively with 10 work units per bundle.

Does this mean we will be crunching 10 work units together (or whatever is in the bundle) at once? Right now I use an app_config to run six at a time, I intend to remove that before the new app is released but I would not like to try running 60 at a time.
____________Team USA forumTeam USA page

My GPU spends nearly half the day doing other work besides MW due to lack of units so 1 hour is no biggy.

Jake,

Thanks for your efforts.

The plan for the beginning is to start conservatively with 10 work units per bundle.

Does this mean we will be crunching 10 work units together (or whatever is in the bundle) at once? Right now I use an app_config to run six at a time, I intend to remove that before the new app is released but I would not like to try running 60 at a time.

Haha I think you'll still do 6, but the 6 will take 10x as long. So you probably won't need to have it set to 6 to keep a GPU busy.

The plan for the beginning is to start conservatively with 10 work units per bundle. Depending on how the CPU only crunchers handle this (about 5-10 hours of work per bundle) we can then decide to increase it. The current code is written to allow for an arbitrary number of work units to be bundled together so I can change it rather easily.

Just to clear this up, essentially what will happen here is it will run X number of work units in series (not parallel) from a single WU request (what I now refer to as a bundle). This means if you need to run more than 1 current WU to fully utilize your GPU, you will still need to do this after the update. However, it should take X times longer to complete these runs.

At the beginning, I will set X to 10 so expect a 10 times longer run time for a single WU bundle. After I see how that seems to be effecting things, I may increase that number to 50 or even 100.

Just a quick update on how things are going with testing, I currently have all of the server side stuff running on a test server I set up. Seems like there aren't any obvious errors. Still trying to get it to serve test work units to a test computer. Hopefully, that will be working by the end of the day just to make sure the validator is working as expected.

So there will still be the data crunch on the CPU in the middle of each bundle? The part that was at the end will now be spread out across the unit or will that all occur at the end for all 10 tasks? This is really why I run multiple tasks at once as there is some time where the GPU is idle between tasks.

I am fixing one small issue with the progress bars in the client (basically every work unit in a bundle it would reset the progress bar back to 0% complete). After that, I have to recompile all of the clients. Then, I have to move all of the code from the test server to the production server. I am going to do a recompile on the production server for the server binaries, run an update, and do a restart. After that, I will monitor everything for any issues that might arise.

I have also run into some technical issues when trying to bundle 10 WUs. I am going to limit to 5 (which I know works through testing), until I can figure out another way to pass parameters to the client.