First batch on each rig were at ~96% for me on linux. Mid running I changed setting <no_priority_change> to 1 in cc config and it improves cpu%

Came home from work to find everything running in the high 98% or low 99%

Thinking of limiting write to disk some to see if that helps too because even my rig running @ 3.1 is getting low points compared to claim suggesting that over 90% of the results so far are from much faster beasts so in this respect every little helps

Not sure on the linux/windows question, although there will be some variation between work units which will be especially true between batches. As for the beta vs. production question, there are a few key difference between what was run in beta vs. what's currently being run in production. During beta, we ran a sampling of all work units for the entire project (or at least what the researchers have provided so far). The researchers also requested that we run some reference seqeuences through first. Early indications are that these are reference sequences are generating larger output files (and more IO) than the average for what we saw in beta (which should be more in line with the whole for the project). Starting with batch 45, non-reference sequences will be worked into the mix and we may see the IO being generated (on average) start to drop.

Also, with the exception of a subset of the last beta run, the sequences were grouped from similar sources. This resulted in few work units generating very large output files but most generating smaller than the average output files and less IO. In production, the order of the sequences in the sequence files is randomized so we don't see such wide variations in the size of the output files generated. Each work unit's sequence file is still only from a single source though, so there is likely to still be variations between batches in the size of the results files.

Seippel

Well let me retry:

1) On same device, after suspending ugm on all cores running in the 92-93 percent efficiency range for batches 17, 18, 33. Switched all cores to mcm as to ascertain if something was awry. After 1:43 hours all of batch 8304, started simultaneous, remained at 99 percent and better.

2) Booted to linux, and get 99.8 percent running all cores ugm.

Now increased write to disk under windows from 120 seconds to 300 seconds and restarted the ugm with laim off, so they pick up the new interval write setting i.e. at least checkpointing no sooner than 5 minutes have passed. Just to see if efficiency climbs back up again.

So when suspending all the ready to start of ugm and let mcm take over gradually, boinctasks logged ever increasing efficiency as fewer ugm were running concurrent, the last one up to 95.78 percent. The 600 second write interval did add a percent to ugm performance, not much.

Now testing 1 ugm next to only mcm for the duration. Ugm needs about 3:35 hours on this node.