I have seti and Eintein running with resource share set at 90% for seti and 10% for Einstein. MY connect time is set for 4 days.
For the past 4 days it was only runnng seti because of the last overcommitted cause by Einstein downloads. It has finally worked off the long term debt. All is OK to this point.

Now this morning the scheduler has seen that it will need to get Einstein work to do its 10% resource share.
The scheduler asks Einstein for 345600 seconds of work. This a total of 4 days work. It should have only asked for .4 days or 34560 seconds of work.
It has now downloaded two work units is over committed and is running earliest deadline first.

---

Red Bull Air Racing

Gas price by zip at Seti

This isn't a bug so much as a difference in interpretation. Each project requests your "connect every" amount of work, but what will happen is once you've crunched both of the units (quite likely consecutively) you will not request anything from Einstein for a good long time (this is what the LTD value determines).

I think the reason for d/ling the full 4 days worth of stuff is in case there is an extended outage on your other projects. By d/ling 4 days of work for each project, the program is able to maintain your "connect every" preference to a much greater degree.

---

This isn't a bug so much as a difference in interpretation. Each project requests your "connect every" amount of work, but what will happen is once you've crunched both of the units (quite likely consecutively) you will not request anything from Einstein for a good long time (this is what the LTD value determines).

I think the reason for d/ling the full 4 days worth of stuff is in case there is an extended outage on your other projects. By d/ling 4 days of work for each project, the program is able to maintain your "connect every" preference to a much greater degree.

The scheduler knows that it can not do 4 days work with only 10% resources. I understand that it should only ask the amount of work that it can do in the connect time which in my case is 0.4 days work.
Because I am now overcommitted it will work only on einstein and seti will fall behind.

---

Red Bull Air Racing

Gas price by zip at Seti

The scheduler knows that it can not do 4 days work with only 10% resources. I understand that it should only ask the amount of work that it can do in the connect time which in my case is 0.4 days work.
Because I am now overcommitted it will work only on einstein and seti will fall behind.

Morning, It enters EDF and will crunch ANY Einstein WU you download as long as your connect to is set to 4 days. EDF is activated by any WU within 24 hours of deadline or two times connect to, so in your case 2 x 4 is 8 days so any WU due in less than 8 days will enter EDF. Einsteins have a 7 day deadline and so if you download one it will go into EDF.

like already mentioned, the scheduler will keep track of the cpu time given to einstein (via ltd numbers) and not get you any more einsteins until it has an almost positive debt.

This isn't a bug

does this help?

tony

OH yeah, Overcommited doesn't mean it's in fear of missing a deadline. It means the scheduler has "Nearly overcommited" or "overcommited" your connect to request of the number of days worth of work.

tony

[edit] Had it only downloaded ONE einstein than it wouldn't have enough work to last for your 4 days worth of work request.

Now this morning the scheduler has seen that it will need to get Einstein work to do its 10% resource share.
The scheduler asks Einstein for 345600 seconds of work. This a total of 4 days work. It should have only asked for .4 days or 34560 seconds of work.
It has now downloaded two work units is over committed and is running earliest deadline first.

Actually, you don't see the full request the client is doing, it among other things also contains your resource_share in the project, and the scheduling-server uses all this info to give you correct amount of work.

Depending on expected cpu-time, you should get 1 or 2 Einstein@home-wu.

After rereading this I thought it important to add that the "Connect to" setting is a request for a "Total" amount of work from ALL projects, not from EACH project.

Now this morning the scheduler has seen that it will need to get Einstein work to do its 10% resource share.
The scheduler asks Einstein for 345600 seconds of work. This a total of 4 days work. It should have only asked for .4 days or 34560 seconds of work.
It has now downloaded two work units is over committed and is running earliest deadline first.

Actually, you don't see the full request the client is doing, it among other things also contains your resource_share in the project, and the scheduling-server uses all this info to give you correct amount of work.

Depending on expected cpu-time, you should get 1 or 2 Einstein@home-wu.

What I'm say is that it didn't use the resource share to calculate the requested wotk. It assumed it was running 100% on Einstein and asked for the full 4 day connect time for work.

---

Red Bull Air Racing

Gas price by zip at Seti

OH yeah, Overcommited doesn't mean it's in fear of missing a deadline. It means the scheduler has "Nearly overcommited" or "overcommited" your connect to request of the number of days worth of work.

tony

[edit] Had it only downloaded ONE einstein than it wouldn't have enough work to last for your 4 days worth of work request.

The log says using earliest deadline first scheduling because computer is overcommitted. The earliset deadline is Einstein because it is 7 days and the earliset seti is only 10. So it will crunch all of the Einstien work before it goes back to seti.

---

Red Bull Air Racing

Gas price by zip at Seti

Nice avatar Richard.

you're right, Resource share has nothing to do with the quantity of work requested (as far as I know). Resource share is used to determine WHAT to run and WHEN. The schedulers LTD numbers decides which project has run too much or not enough according to you're resource share. The resource share determines the offset of each LTD number. When the LTD for a given project is "nearly" positive it will request work. When it's negative it won't. As one project runs, it's LTD goes negative, while the rest of the projects get more positive.

If you watch your LTD numbers, Einstein will continue to get more negative until all the work downloaded is done. At some point Setis' LTD will become positive and start downloading work. Seti will then run (becoming more negative) and Einstein will slowly become more positive (rate depends on resource share) until it become positive and then einstein will download work. Then the cycle repeats.

This IS the way it's supposed to work.

keep an eye on it.

hope this helps

tony

The log says using earliest deadline first scheduling because computer is overcommitted. The earliset deadline is Einstein because it is 7 days and the earliset seti is only 10. So it will crunch all of the Einstien work before it goes back to seti.

Could you copy and paste your log? It's probably two seperate lines. one indicating you have enough work to satisfy your "Connect to" setting(nearly or overcommited), and the next saying that it's using EDF to crunch a WU which is within the 2X connect to deadline.

tony

What I'm say is that it didn't use the resource share to calculate the requested wotk. It assumed it was running 100% on Einstein and asked for the full 4 day connect time for work.

No, the info showing up in client-log is only 1st line of the request, it isn't the full request.

You only see something like "I want 4 days of work, and is returning 0 results".

You don't see the rest of the request:
"This project have resource_share 0.10, and have 0 seconds of cached work in this project.
This computer have online_frac 0.909 and active_frac 0.985
The computer-benchmark is xxxx flops and yyyy iops.
The computer have N cpu's.
The computer have x GB free space, and have y MB memory.
OS is... upload speed is... download speed is...
Oh, not to forget, my id is nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn, and hostid = 123456.
List of all results the client have for this project.
List of all deadlines and expected cpu-time left for all results."


The scheduling-server isn't using the 2 detailed lists of all results and projects results yet, this will be added later.
The rest of the info on the other hand is used by the scheduling-server when desiding how much work to assign to your computer.

The log says using earliest deadline first scheduling because computer is overcommitted. The earliset deadline is Einstein because it is 7 days and the earliset seti is only 10. So it will crunch all of the Einstien work before it goes back to seti.

Could you copy and paste your log? It's probably two seperate lines. one indicating you have enough work to satisfy your "Connect to" setting(nearly or overcommited), and the next saying that it's using EDF to crunch a WU which is within the 2X connect to deadline.

tony

It is all on one line.

6/24/2005 8:02:52 AM 11 Using earliest-deadline-first scheduling because computer is overcommitted.

---

Red Bull Air Racing

Gas price by zip at Seti

No, the info showing up in client-log is only 1st line of the request, it isn't the full request.

You only see something like "I want 4 days of work, and is returning 0 results".

You don't see the rest of the request:
"This project have resource_share 0.10, and have 0 seconds of cached work in this project.
This computer have online_frac 0.909 and active_frac 0.985
The computer-benchmark is xxxx flops and yyyy iops.
The computer have N cpu's.
The computer have x GB free space, and have y MB memory.
OS is... upload speed is... download speed is...
Oh, not to forget, my id is nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn, and hostid = 123456.
List of all results the client have for this project.
List of all deadlines and expected cpu-time left for all results."


The scheduling-server isn't using the 2 detailed lists of all results and projects results yet, this will be added later.
The rest of the info on the other hand is used by the scheduling-server when desiding how much work to assign to your computer.

After checking it did only download .4 days of continous work at 100% or 4 days work at 10%. What is missing from the request is that it can not complete this amount of work before the next connect time because it is already over half of the deadline time. The 4 days is over half of the Einstein deadline of 7 days. It should have only requested what it can complete in half of the deadline so it wouldn't be overcommitted.

Am I correct on this.

---

Red Bull Air Racing

Gas price by zip at Seti

6/24/2005 8:02:52 AM 11 Using earliest-deadline-first scheduling because computer is overcommitted.

It appears that I need JM7 to redefine "overcommitted" for me. I.E I need more education.

thanks

tony

Here ya go Tony. Straight from the Wiki:

Details - CPU queue overload

Sort the Work Units by Deadline, with the earliest Deadline first. If at any point in this list, the sum of the remaining processing time is greater than 0.8 * up_frac * time to deadline, the CPU queue is overloaded. This triggers both no work requests and the Work Scheduler into earliest deadline first.

Which is what it's doing. :)

Also better explained at this page.

---

After checking it did only download .4 days of continous work at 100% or 4 days work at 10%. What is missing from the request is that it can not complete this amount of work before the next connect time because it is already over half of the deadline time. The 4 days is over half of the Einstein deadline of 7 days. It should have only requested what it can complete in half of the deadline so it wouldn't be overcommitted.

Am I correct on this.

If you were connected to download the work and you told them that you'd be reconnecting in 4 days and it gave you 4 days work, then you'd have the work completed within the 7 day deadline, is that not so?

Richard, everyone knows there are small problems with this scheduler. If you subscribe to the Dev mail list you'll see the efforts being made to fix it.

I was only trying to show you that what you experienced wasn't a Bug. Now, if you see it not following what I said earlier, then you may have a bug. Noone would argue with the statement "this scheduler needs some tweaking", not even the Devs. If you have some helpful/creative suggestion on ways to improve it, the submit them. They WILL consider it.

I hope I have been of some help.

tony

Which is what it's doing. :)

Thanks Ageless, I used to know that, thanks again

tony

After checking it did only download .4 days of continous work at 100% or 4 days work at 10%. What is missing from the request is that it can not complete this amount of work before the next connect time because it is already over half of the deadline time. The 4 days is over half of the Einstein deadline of 7 days. It should have only requested what it can complete in half of the deadline so it wouldn't be overcommitted.

Am I correct on this.

I was only trying to show you that what you experienced wasn't a Bug. Now, if you see it not following what I said earlier, then you may have a bug. Noone would argue with the statement "this scheduler needs some tweaking", not even the Devs. If you have some helpful/creative suggestion on ways to improve it, the submit them. They WILL consider it.

I hope I have been of some help.

tony

It is a bug if it knows it can't finish within 80% of the deadline and it still downloads 100% of the deadline.

Another constraint is if it can't finish within half of the time leftover from deadline minus next connect time.

---

Red Bull Air Racing

Gas price by zip at Seti

The real problem is that newer versions of the server software only pass back work_request * resource_frac amount of work, while older servers pass back work_request amount of work. I know about the problem, and have been trying to figure out a method for the work request to incorporate the LTD as well.

---

BOINC WIKI