I've been thinking about how the work servers are fed - and thought I'd crunch some real numbers from the logs. See the graph I created from almost a month's worth of every-35 minute data.bruce wrote:The Demand part is directly related to keeping the servers balanced.
If the active science projects require 10000 trajectories for bigadv and 80000 trajectories for smp and 50000 trajectories for GPU and 60000 trajectories for uniprocessors, servers are configured based on those numbers. Now if 50000 donors want to run bigadv, there will be 40000 clients who can't get their choice of assignments. Demand exceeds Supply in that category. Having them continually banging on the servers that have run out of bigadv projects does not contribute anything to science and it certainly contributes to the frustration level of a lot of donors.
(I invented all those numbers -- they probably are totally unrealistic, but that doesn't matter -- there's still a fixed number of trajectories on each server which are either checked out to a client who is processing it or waiting for someone to request that assignment. Those fixed numbers do change when new projects are started or when projects end. The number of donors seeking work in each classification changes, too, for a number of obvious reasons but there has to be a reasonable balance between the two.)
Format of the graph: the blue line is the WU Available in each interval - against the scale on the left side. The red line is the WUs received in each reporting interval against the scale on the right side.
I don't know what the real back end processing is, but it appears that there's an almost steady-state replenishment of the WU avail for the bigadv and bigbeta folders (the logs don't break out finer granularity of how many bigadv and how many bigbeta). I don't think that this real-time replenishment is due to new work being created by the FAH scientists - it appears that it represents creation of the next-generation WUs along a trajectory based on just-returned WUs.
There has been considerable discussion in the forum about running out of work for the bigadv and/or bigbeta clients. It would be helpful (not the first time I've made this suggestion) if the proj leads could share the design of the projects. For instance, how many more gens are anticipated to get the scope along the timeline? Is the back end processing able to keep up with all of the newly-folded WUs? Are there any real serialization issues, or are there enough projects in the hopper to tolerate a large volume of two-day returns? Are some of the problems in the 2684/6900/etc projects reaching the end of their simulation period, and almost ready for final back end crunching to generate scientific conclusions and generate papers?