I can't get VM to work at idle priority

[HighYield]

I could use a little help getting my VM to only run at idle priority. I am using VM player 3.0.0 on a Win 7 X64 box with 12 gig of ram and it is running BigAdv - But I can't figure out how to lower it's priority. I'm using the EVGA Linux64_FAH image. I thought to change priority I needed to add the lines
priority.grabbed = "idle"
priority.ungrabbed = "idle"
to the Linux64_FAH.vmxf file (below). When I do this and try to restart folding there is a file access error. Then if I remove the above lines the vm will start up and fold like normal with no error. Any ideas how to fix this? Am I changing the wrong file?

Linux64_FAH.vmxf

<?xml version="1.0"?>
<Foundry>
<VM>
<VMId type="string">52 89 b6 a1 26 8f c2 c1-70 ef 09 dc 64 4e 01 59</VMId>
<ClientMetaData>
<clientMetaDataAttributes/>
<HistoryEventList/></ClientMetaData>
<vmxPathName type="string">Linux64_FAH.vmx</vmxPathName></VM></Foundry>

 

[musky]

I think you want the .vmx file, not the .vmxf. Open it with notepad of some other text editor.

 

[APOLLO]

Musky is right, it's the *.vmx file that needs editing. You should be good after that.

 

[HighYield]

Thanks. That did it. What would I do without you guys...

Now that I have my bigadv folding rig setup, I hear bigadv is going away. What will be the best thing to do to keep maximum ppd? Keep folding in a VM or go back to Win SMP?

 

[APOLLO]

Now that I have my bigadv folding rig setup, I hear bigadv is going away. What will be the best thing to do to keep maximum ppd? Keep folding in a VM or go back to Win SMP?

-bigadv will be available for the Windows A3 core. When that will happen is not known but most believe it will be sometime this summer. You can still fold these WUs in a VM or switch to the Windows SMP2 client. For the time being, sticking to the VM will probably net you a higher PPD, especially since the Linux client is still receiving the older A2 -bigadv WUs which produce higher PPD.

 

[HighYield]

50 k is very nice for a work unit. I still question the appropriateness of doubling someone's points for getting the work in a few days earlier. I think you should get "paid" by the job not the schedule, because frankly 2 or 3 days won't make any difference in the great scheme of things. The huge bonus give outs also undermine the folks that could readily turn in the unit within the full time frame but using less OC'd or older hardware. That's it for my points rant.

With the one computer I am running now ([email protected] GHz & GTX260) it pretty much produces the same as 3 of my older computers with a huge power/heat savings.

 

[APOLLO]

50 k is very nice for a work unit. I still question the appropriateness of doubling someone's points for getting the work in a few days earlier. I think you should get "paid" by the job not the schedule, because frankly 2 or 3 days won't make any difference in the great scheme of things. The huge bonus give outs also undermine the folks that could readily turn in the unit within the full time frame but using less OC'd or older hardware. That's it for my points rant.

Believe it or not, I largely agree with you. I never was a huge proponent of the bonus points system and take issue with its future application in GPU seeing how frequently server outages happen, not to mention EUE strings.

The rationale behind the bonus scheme is to provide incentive for faster turn arounds. Stanford highly values fast WU completion because of the nature of its research. Apparently it is better to have a faster WU turnaround as opposed to a larger volume of WUs completed. Exactly why this is so is not understood by me, but I never delved deeply into the topic like some others have. Suffice to say that if Stanford devised a points system to increase incentive for faster completion times, there must be a reason.

 

[arentol]

Apparently it is better to have a faster WU turnaround as opposed to a larger volume of WUs completed. Exactly why this is so is not understood by me, but I never delved deeply into the topic like some others have. Suffice to say that if Stanford devised a points system to increase incentive for faster completion times, there must be a reason.

There are lots of good reasons why speed > volume:

1) Speed is volume.
2) The faster a WU is completed the lower the chance of it being lost due to PC failure. So encouraging speed probably improves the overall completion ratio.
3) Speed is volume.
4) Once they send a WU out it is in limbo until completed or the same machine requests a new unit for some reason. Therefore short deadlines are really important so they can release the unit to someone else as soon as possible if it doesn't come back.
5) Speed is volume.
6) Rewarding people with bonus points to complete jobs faster encourages people to only attempt that which they can complete fairly quickly. This helps to greatly decrease the number of people barely making the time deadline, and decreases lost units or units that end up not completing in time due to some minor delay, like a couple hours of accidental downtime.
7) Oh, and lets not forget, speed is volume.

Combine all these things and it is fairly obvious how they benefit from encouraging speed... Raw volume is simply not an option for the bigger units, they can't have units sitting out there for a month only to never be turned in. Therefore they must rely on speed to give them volume for those units.

 

[APOLLO]

^ True, however there are technical reasons in specific regards to this kind of research that warrants increasing incentives for faster turnarounds. Let's just assume that the 'speed is volume' mantra was not valid, Stanford would still desire a faster completion time even if the volume of results was lower. So, I think your point #4 above has a lot if not most to do with the bonus scheme. There could exist other reasons and believe there indeed are, but again, I'm not savvy on the biomedical end of the project.

To comment on point #6, the big downside to rewarding faster and faster completion times with disproportionately favorable bonus credit, creates a situation where more expensive hardware/setups gain more and more advantage than ever before, benefiting those with resources more than ever. I know I'm going to receive some arguments about this, but keep in mind this is JMPO, and nothing more...