Work-fetch policy in 6.6.x causes problems

Message boards : Questions and problems : Work-fetch policy in 6.6.x causes problems
Message board moderation

To post messages, you must log in.

AuthorMessage
Bunsen

Send message
Joined: 3 Mar 07
Posts: 15
Message 25214 - Posted: 5 Jun 2009, 13:32:29 UTC

The new work-fetch policy that was implemented in 6.6.20 seems to have some problems. I'm running Seti@Home and Einstein@Home; the former tends to have work units that take my machine about 4 days to process. If, at some point, my system needs about 1 day of work for each project, and Seti@Home is the first project to connect with its server and gets one of those big work units, Einstein@Home won't even try to get any more work for several days. The same thing happens the other way round: getting work for Einstein@Home suppresses Seti@Home from trying to get more work, even though it's got much less to work on than my "connect every [X] days" and "maintain an additional [X] buffer" settings indicate.

I don't see why the work-fetch processes for differing projects would be interrelated.
ID: 25214 · Report as offensive
Bunsen

Send message
Joined: 3 Mar 07
Posts: 15
Message 25219 - Posted: 5 Jun 2009, 17:42:32 UTC - in response to Message 25216.  

I used the described procedure to set the flag / clear the "debt" state. A couple of hours later, the manager requested roughly-equal workloads from both projects. But at the moment, the pending tasks are heavily weighted towards the Einstein@Home project.

Should I manually force the manager to grab more work units from Seti@Home until the pending tasks are about balanced, then clear the "debt" again? Simply leave the config file with that flag set, so the manager always clears the "debt" every time it restarts?
ID: 25219 · Report as offensive
Bunsen

Send message
Joined: 3 Mar 07
Posts: 15
Message 25360 - Posted: 12 Jun 2009, 2:41:32 UTC - in response to Message 25220.  

It really doesn't seem to help. Even after several days, the pending tasks are still heavily weighted towards Einstein@Home; in fact, it's getting worse, since the proportions in the work units coming in are even more heavily weighted towards Einstein@Home. At the moment, I've got about 13 hours of work for Seti, and about 91 hours for Einstein. Several times in the last couple of days, both projects have been asking for more work, but when Einstein connects first when my connection comes on-line, it gets more work, and then when Seti connects, it doesn't bother asking.

The short_term_debt and long_term_debt values stored in the client_state.xml file haven't changed more than a tiny bit in several days.
ID: 25360 · Report as offensive
Profile Gundolf Jahn

Send message
Joined: 20 Dec 07
Posts: 1069
Germany
Message 25361 - Posted: 12 Jun 2009, 6:22:40 UTC - in response to Message 25360.  

What are your resource shares?

Is this your account at Einstein? If so, and the resource shares for Einstein and SETI are equal, SETI should indeed ask for work, as the RAC is lower. But there are several tasks still pending, including an AstroPulse, which might give a wrong picture.

What are the debt values in client_state?

Gruß,
Gundolf
Computer sind nicht alles im Leben. (Kleiner Scherz)
ID: 25361 · Report as offensive
Bunsen

Send message
Joined: 3 Mar 07
Posts: 15
Message 25366 - Posted: 12 Jun 2009, 13:27:11 UTC - in response to Message 25361.  

What are your resource shares?


50% each.

Is this your account at Einstein? If so, and the resource shares for Einstein and SETI are equal, SETI should indeed ask for work, as the RAC is lower. But there are several tasks still pending, including an AstroPulse, which might give a wrong picture.


Yes, that's my account.

At the moment, I'm completely out of work for SETI. The manager did ask the SETI server a couple of times for more work, but it has none to provide... so it continued to ask for more work for Einstein.

What are the debt values in client_state?


Before it completed the download of a couple of AstroPulse units, the values were:

Einstein:
short_term_debt: 0.000000
long_term_debt: -555.031250
cuda_debt: 0.000000

SETI:
short_term_debt: 0.000000
long_term_debt: 0.000000
cuda_debt: 0.000000

After completing the download of the AstroPulse units, all of the debt values are 0.000000 .
ID: 25366 · Report as offensive
Profile Gundolf Jahn

Send message
Joined: 20 Dec 07
Posts: 1069
Germany
Message 25368 - Posted: 12 Jun 2009, 13:37:55 UTC - in response to Message 25366.  

At the moment, I'm completely out of work for SETI. The manager did ask the SETI server a couple of times for more work, but it has none to provide... so it continued to ask for more work for Einstein.

Okay, that's a problem as of now. I currently don't get new work from SETI either. So, we have to wait until there's work again. But I don't understand that you are out of work for SETI if you just completed AstroPulse downloads. They usually last for a couple dozen hours (300 on my box:-).

Gruß,
Gundolf
Computer sind nicht alles im Leben. (Kleiner Scherz)
ID: 25368 · Report as offensive
Bunsen

Send message
Joined: 3 Mar 07
Posts: 15
Message 25369 - Posted: 12 Jun 2009, 13:51:41 UTC - in response to Message 25368.  

I'm sorry; I used the wrong name. The units that were downloaded were Binary Pulsar Search units for Einstein, not AstroPulse units for SETI.
ID: 25369 · Report as offensive
Bunsen

Send message
Joined: 3 Mar 07
Posts: 15
Message 25375 - Posted: 12 Jun 2009, 15:59:16 UTC - in response to Message 25368.  

Okay, SETI was able to get some work from the server. The units downloaded come to about 49 hours of work, vs. an expected approximate 96 -- my current preferences for this machine are "connect every 2.50 days, additional buffer
1.50 days", 2 projects with equal priority, dual-core processor. (Are my expectations incorrect? Work needed = (connection period + buffer) * (# processors) / (# projects), if all projects have equal resource shares?)

Now the debt values in client_state.xml are:

Einstein:
short_term_debt: -94.109375
long_term_debt: -620.843750
cuda_debt: 0.000000

SETI:
short_term_debt: 94.109375
long_term_debt: 0.000000
cuda_debt: 0.000000
ID: 25375 · Report as offensive

Message boards : Questions and problems : Work-fetch policy in 6.6.x causes problems

Copyright © 2024 University of California.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.