LHC@home

Igor wrote:

Right now the limits are as follows:

<daily_result_quota> 80 </daily_result_quota>
<one_result_per_user_per_wu> 1 </one_result_per_user_per_wu>
<max_wus_to_send> 2 </max_wus_to_send>
<max_wus_in_progress> 1 </max_wus_in_progress>

Please, monitor and see how this works.

I've commented from the boinc documentation what each of these do, so everyone understands all choices.

<one_result_per_user_per_wu/>
If set, send at most one instance of a given job to a given user. This increases the effectiveness of replication-based validation by making it more difficult for hackers to get all the instances of a given job.

<max_wus_in_progress> N </max_wus_in_progress>
Limit the number of jobs in progress on a given host (and thus limit average turnaround time), in this case, the max CPU jobs in progress is N*NCPUS

<max_wus_to_send> N </max_wus_to_send>
Maximum jobs returned per scheduler RPC is N*NCPUS

<daily_result_quota> N </daily_result_quota>
Each host has a field MRD in the interval [1 .. daily_result_quota]; it's initially daily_result_quota, and is adjusted as the host sends good or bad results. The maximum number of jobs sent to a given host in a 24-hour period is MRD*NCPUS. You can use this to limit the impact of faulty hosts.

@T.J, the option you mention is built in and the above option, it is already in effect.

So I think based on Igor's previous selection and user comments here, we should try this:

<daily_result_quota> 80 </daily_result_quota>
<one_result_per_user_per_wu/>
<max_wus_to_send> 2 </max_wus_to_send>
<max_wus_in_progress> 3 </max_wus_in_progress>

Additional note to Igor:
There is a section in the documentation called "Accelerating retries"
I think you should read this section and use this method also. Basically what it does, if a host returns bad results that host is marked unrelaible. Hosts that return good results are marked relaible. A bad host can become relaiable after if it stops turning in bad work and keeps on returning good work. When a result is returned bad, it's priority gets increased. This option resends those higher priority results to know reliable hosts. It does two things, rewards relaible hosts with more avaialble work chance and reduces turn around by not constanlty sending results to other bad hosts. It only affect work needining resend, ie a third, forth or more tyr after the initial 2 have a go at it. You can also mark work in advance as a higher priority and it gets sent only to these relaible hosts, like if you had some small study you need quick turnaround on.

This is not a hard limitation.

Which limitation is hard then? Zero tasks in progress? :-)

haha, funny joke which proves nothing

It will not slow down this project. It will not affect how many Sixtrack tasks you run over the long term. That is determined by your resource shares.

This time, Your conclusion is too fast and without enough arguments, sorry.

My conclusion is fast because it is easy to reach if you understand how project shares, scheduling and project debts work. You don't understand any of that so it seems like a huge difficult problem to you. It is not.

I don't need more than 1 argument because the solution is simple. Again, you don't understand BOINC scheduling so you cannot understand even the simplest argument about it.

Also, resource share is not a panacea. It newer worked properly and especially - it is working absolutely crazy in the newest BOINC versions (later than 6.2.19). I will try too explain this later (on examples).

Don't waste your time with examples because I'll just prove them all to be examples of proper scheduling.

You will see that even with a limit of 2, the CPU will not always be given to the waiting Sixtrack task after a Sixtrack task finishes. It has to work that way. If it didn't, your other projects would never get any CPU time. Like I said earlier... get the CPU now or get the CPU later.... it doesn't matter!! Your other projects are going to get the CPU eventually anyway. If you can't understand that then you know nothing about how BOINC schedules tasks. So deal with that. Prove it wrong. You can't because it is the fundamental way the scheduler MUST work to do its job properly. That part of the scheduler has ALWAYS worked.

haha, funny joke which proves nothing

I am not PROVING something, I am ASKING - if 1 task in progress is not hard (syn. last, extremely etc.) limitation, which limitation is hard then?

Again, you don't understand BOINC scheduling so you cannot understand even the simplest argument about it.

Yeees!!! I don't understand or I stopped to understand, how BOINC scheduling works, especially which kind arithmetic is now used for that. Reality shows - not this arithmetic where 1+1=2 or 2x2=4.

Don't waste your time with examples because I'll just prove them all to be examples of proper scheduling.

Ok, if absolute truth belongs to You, it will belong to You. Amen!

---

Please keep the discussion friendly.
=
Read the forum posting rules (to the left) before posting.

Again, you don't understand BOINC scheduling so you cannot understand even the simplest argument about it.

Yeees!!! I don't understand or I stopped to understand, how BOINC scheduling works, especially which kind arithmetic is now used for that. Reality shows - not this arithmetic where 1+1=2 or 2x2=4.

Look, my argument is simple. I say that your objection to a limit of 1 per CPU because other projects will grab the CPU when the Sixtrack task uploads isn't sensible because other projects will get the CPU eventually anyway. That is a fact. All you've done is say my argument is too hasty and not enough arguments. You haven't said anything substantive about whymy argument is incorrect. Defend your argument with some facts about the scheduler or give it up.

Don't waste your time with examples because I'll just prove them all to be examples of proper scheduling.

Ok, if absolute truth belongs to You, it will belong to You. Amen!

If you're going to give up that easy then all I can say is Amen too.

Hi

I am re-opening this thread as today my computer (dual core) reach the limit of 80/day/core since there were a lot of very short WUs.

This limit has nothing to do with invalid results and it was set because of certain users nagging in the past that they can not get any WUs as others process them so fast. If I recall corectly limit then was 10 or 20/day.

Since on one computer can only be one WU per core at the same time this limit of WU/day can be lifted and set the limit for invalid results (if it's not already in place) for faster project processing.
Otherwise some computers will be idle or work for backup project (like mine for the next 14+ hrs) because of this unnecessary limit, while there will still be WU available.
( ATM there are no WUs, except resends )