Well, seriously, you're absolutely right, running a high performance GPU project requires much more than "just" writing an efficient app, all the infrastructure has to cope with it as well, a lesson learned the hard way by most GPU projects. The admins at AEI Hannover and the UWM keep upgrading the system to meet future requirements.
In case a new version of the server status page can't be built within the apache PHP timeout (180s IIRC) e.g. because of a slow DB response, the server will show the old page from the cache. It's not that someone manually turns the update on or off.
We know that our infrastructure has trouble handling tasks that spend less than an hour on the clients. That's why we 'bundled' four 'traditional' tasks into each current ABP2 task - for each such task the client downloads four data files. processes them one after the other, and then uploads four result files. If a faster App would put the main project server (scheduler, DB) in trouble, we'd simply increase the task size. The only piece of machinery that's close to its limits is the ABP download server in Hannover, and yes, we're working on an upgrade.
Server Status Page not updated
)
I suspect refreshing it was turned off temporarily to reduce server load.
CU
HB
Hallo Bikemann ! What will
)
Hallo Bikemann !
What will happen to your servers, if you start to send out realy effectively working GPU crunching workunits?
Kind regards
Martin
Hi! It will be like in
)
Hi!
It will be like in "Jaws"
"We'll need a bigger boat"
:-)
Well, seriously, you're absolutely right, running a high performance GPU project requires much more than "just" writing an efficient app, all the infrastructure has to cope with it as well, a lesson learned the hard way by most GPU projects. The admins at AEI Hannover and the UWM keep upgrading the system to meet future requirements.
HB
In case a new version of the
)
In case a new version of the server status page can't be built within the apache PHP timeout (180s IIRC) e.g. because of a slow DB response, the server will show the old page from the cache. It's not that someone manually turns the update on or off.
We know that our infrastructure has trouble handling tasks that spend less than an hour on the clients. That's why we 'bundled' four 'traditional' tasks into each current ABP2 task - for each such task the client downloads four data files. processes them one after the other, and then uploads four result files. If a faster App would put the main project server (scheduler, DB) in trouble, we'd simply increase the task size. The only piece of machinery that's close to its limits is the ABP download server in Hannover, and yes, we're working on an upgrade.
BM
BM