Oh yeah, right. SSE optimization was mentioned there already... I must be getting old and forgetful ;-) Thanks for pointing it out. Well, I hope the Linux app stops giving trouble, I guess that would be a big step towards getting optimization soon.
Nice that the optimized apps will bring a performance plus all the way down to P3, so all the vintage boxes will benefit as well. That should really help quite a bit with deadline problems.
Nice that the optimized apps will bring a performance plus all the way down to P3, so all the vintage boxes will benefit as well. That should really help quite a bit with deadline problems.
Yes, it should. We know from past experience that Bruce will lower the credits when the runtimes improve. Hopefully the deadlines will remain at 2 weeks.
Not that I care overly much about credits (otherwise I wouln't risk all those CPU secs beta testing ;-) ), but I sometimes look at them as a benchmark, and atm I have the impression that Einstein doesn't give very much credit compared to other projects, so there might be some room for optimization without lowering credit. However, that is a totally subjective impression. I'm sure the project devs will get it right.
But I agree with you, making deadlines shorter wouln't be so great. I think quite a few people with slow boxes and/or low res shares will be relieved if they have the sime kind of deadline and shorter computation times.
Not that I care overly much about credits (otherwise I wouln't risk all those CPU secs beta testing ;-) ), but I sometimes look at them as a benchmark, and atm I have the impression that Einstein doesn't give very much credit compared to other projects, so there might be some room for optimization without lowering credit. However, that is a totally subjective impression. I'm sure the project devs will get it right.
If you look at that chart, it currently appears that SETI and Einstein are roughly equivalent. Other projects, like RieselSieve, QMC, or Cosmology, all pay out significantly more. IMO, that's why you see several competition-oriented people spending large amounts of time with those projects right now, since they have work atm...
We currently don't have any plans to change the deadlines, neither with current, nor with future Apps.
With the switch to S5R3 we got a variation in runtime that we didn't expect. We are working on the workunit generator to adjust the credits given accordingly, it might be a good idea to dynamically extend the deadline a few days for longer running results, too. But it will stay in the same order (two to three weeks).
One reason for testing the SSE(2) code on MacOS is that all Intel Macs have CPUs with the same features (SSE, SSE2 etc.). I have various issues with this code on other platforms that are not solved yet, some depend on the compiler used, some require certain CPU features, requiring feature detection, maintenance of different code paths etc. It's actually all a lot easier on Intel Macs. And yes, the stability issues of the other platforms are the bigger concern for us.
A cross-project credit comparison can be seen here. According to this Einstein@Home is currently granting more credits per CPU hour than most other projects (the numbers in the Einstein@Home row are mostly >= 1.0), though a bit less than SETI.
After developing software for many years, I prefer to set deadlines that I can actually keep without scrambling around at the end like EDF does.
You may not react favorably to this at first, but I'm just going to be honest with you...
It's actually your own setting that is causing EDF. That said, it's not exactly entirely your fault. S4 and S5R1 were much faster, so what you have worked fine up until S5R2. To completely avoid EDF, either your allocation needed to increase or the deadlines needed to increase, or perhaps both things needed to happen.
Also, it is only a "problem" if viewed over a short span of time. If you look at it over months of time, the overall percentages that you specify are maintained.
As Ned pointed out, people just don't like it. It's a perception thing...
Against my better judgement and to avoid getting back to work, I'll belabor the point (although sometimes that seems to be the point in message boards ;-) ...
First, no offense taken and none intended towards you or the E@H authors.
Second, I get the fact things are supposed to even out over time. But I don't buy your argument it's partly the result of my settings. If I may paraphase, what you are saying is the settings are okay for some data sets but not others. This then implies that I (and hundreds of thousand other Boinc/E@H users) need to monitor the data set sent to our computers and adjust our individual settings on a regular basis because the deadline may be wrong for that particular dataset. Sorry, I'm not going to do that. It's a bug. Either adjust the deadline at the E@H end for each dataset or set it high enough so this isn't a problem. Rosetta, for instance, seems to operate without EDF at a 10% allocation on the same machines. I know, different problem, different data, but it's a counterpoint.
Third, yeah, it's perception, but perception is valid. In the real world it can keep a customer from buying your product. Just because the scheduler is supposed to recover doesn't mean it does and that EDF (aka "panic-mode") is benign. I'm glad the BOINC scheduler has this feature, but that doesn't mean it should be exercised on a regular basis because E@H has the deadline wrong.
We currently don't have any plans to change the deadline, neither with current, nor with future Apps.
I didn't figure that you wanted to change deadlines. It has been 2 weeks for quite a long time, with the exception of S5R2 @ 3 weeks.
Quote:
According to this Einstein@Home is currently granting more credits per CPU hour than most other projects (the numbers in the Einstein@Home row are mostly >= 1.0), though a bit less than SETI.
So when you all consider the next round of credit lowering, please keep in mind that users are not flocking in droves to Einstein to chase credits. The "credit inflation" monster seems largely a myth. Sure, there will be a few credit-chasers, but it seems like most people join projects based on the perceived merit or their own personal interest. Because of this, keeping in line with SETI should probably be what you all shoot for.
Looking through BOINCStats project statistics:
Einstein is averaging 65-75 new users/day, 210-270 new hosts/day.
SETI: 360-420, 1000-1150.
CPDN: 95-105, 190-200.
Rosetta: 178-185, 590-640.
World Commmunity Grid: 230-260, 630-830.
The big payout project compared to Einstein, RieselSieve: 9-10, 37-42.
Second, I get the fact things are supposed to even out over time. But I don't buy your argument it's partly the result of my settings. If I may paraphase, what you are saying is the settings are okay for some data sets but not others.
That's exactly what I'm saying. A 10% allocation across 14 days is a maximum of 33.6 hours of work with 100% utilization. It is actually lower than that, but that's getting very technical. There was a HUGE difference in the runtime of S4/S5R1 vs. S5R2/S5R3. You could probably get 4-8 S4/S5R1 results to work on at that low of an allocation and still complete them without entering EDF. However, since you cannot download just part of a result here, the one result is estimating 61 hours, which at 10% simply cannot be done (61 > 33.6).
This was all covered in the complaining about S5R2. With your relatively low credit and RAC, I'm going to guess you missed most/all of S5R2. I was a loud complainer back then. I felt that S5R2 was a public beta test of alpha-level code. IMO, the project is just now getting things back under control.
As I said, IMO the project messed up in not increasing S5R2 deadlines to 4 or even 6 weeks. They also messed up by cutting deadlines back to 2 weeks without seeing that the runtimes were actually not 1/3 of the S5R2 runtimes.
Quote:
Just because the scheduler is supposed to recover doesn't mean it does and that EDF (aka "panic-mode") is benign. I'm glad the BOINC scheduler has this feature, but that doesn't mean it should be exercised on a regular basis because E@H has the deadline wrong.
It does handle it just fine. I don't mean to be offensive, but again I'm just going to be honest. You're a "doubting Thomas" (although your name is Bob, I guess). :sigh:
What will happen, provided you do not tinker with BOINC, is that Rosetta and SETI will each get some extra time now. I've witnessed this event happen on my own machine, where Einstein would run longer than 1 hour at a time. My shares are 66/33/1 (SETI/Einstein/LHC). SETI should run for about 2 hours, then Einstein for about 1 hour. At the time, I didn't have LHC work to do...
RE: So the Mac users have
)
I poked Bernd about it. His response is here, which is what you responded to with the "two false friends in a single sentence" comment...
Oh yeah, right. SSE
)
Oh yeah, right. SSE optimization was mentioned there already... I must be getting old and forgetful ;-) Thanks for pointing it out. Well, I hope the Linux app stops giving trouble, I guess that would be a big step towards getting optimization soon.
Nice that the optimized apps will bring a performance plus all the way down to P3, so all the vintage boxes will benefit as well. That should really help quite a bit with deadline problems.
RE: Nice that the
)
Yes, it should. We know from past experience that Bruce will lower the credits when the runtimes improve. Hopefully the deadlines will remain at 2 weeks.
Brian
Not that I care overly much
)
Not that I care overly much about credits (otherwise I wouln't risk all those CPU secs beta testing ;-) ), but I sometimes look at them as a benchmark, and atm I have the impression that Einstein doesn't give very much credit compared to other projects, so there might be some room for optimization without lowering credit. However, that is a totally subjective impression. I'm sure the project devs will get it right.
But I agree with you, making deadlines shorter wouln't be so great. I think quite a few people with slow boxes and/or low res shares will be relieved if they have the sime kind of deadline and shorter computation times.
RE: Not that I care overly
)
What Bruce seems to look at heavily is the cross-project statistics at BOINC Combined Statistics.
If you look at that chart, it currently appears that SETI and Einstein are roughly equivalent. Other projects, like RieselSieve, QMC, or Cosmology, all pay out significantly more. IMO, that's why you see several competition-oriented people spending large amounts of time with those projects right now, since they have work atm...
We currently don't have any
)
We currently don't have any plans to change the deadlines, neither with current, nor with future Apps.
With the switch to S5R3 we got a variation in runtime that we didn't expect. We are working on the workunit generator to adjust the credits given accordingly, it might be a good idea to dynamically extend the deadline a few days for longer running results, too. But it will stay in the same order (two to three weeks).
One reason for testing the SSE(2) code on MacOS is that all Intel Macs have CPUs with the same features (SSE, SSE2 etc.). I have various issues with this code on other platforms that are not solved yet, some depend on the compiler used, some require certain CPU features, requiring feature detection, maintenance of different code paths etc. It's actually all a lot easier on Intel Macs. And yes, the stability issues of the other platforms are the bigger concern for us.
A cross-project credit comparison can be seen here. According to this Einstein@Home is currently granting more credits per CPU hour than most other projects (the numbers in the Einstein@Home row are mostly >= 1.0), though a bit less than SETI.
BM
BM
RE: RE: After developing
)
Against my better judgement and to avoid getting back to work, I'll belabor the point (although sometimes that seems to be the point in message boards ;-) ...
First, no offense taken and none intended towards you or the E@H authors.
Second, I get the fact things are supposed to even out over time. But I don't buy your argument it's partly the result of my settings. If I may paraphase, what you are saying is the settings are okay for some data sets but not others. This then implies that I (and hundreds of thousand other Boinc/E@H users) need to monitor the data set sent to our computers and adjust our individual settings on a regular basis because the deadline may be wrong for that particular dataset. Sorry, I'm not going to do that. It's a bug. Either adjust the deadline at the E@H end for each dataset or set it high enough so this isn't a problem. Rosetta, for instance, seems to operate without EDF at a 10% allocation on the same machines. I know, different problem, different data, but it's a counterpoint.
Third, yeah, it's perception, but perception is valid. In the real world it can keep a customer from buying your product. Just because the scheduler is supposed to recover doesn't mean it does and that EDF (aka "panic-mode") is benign. I'm glad the BOINC scheduler has this feature, but that doesn't mean it should be exercised on a regular basis because E@H has the deadline wrong.
Bob
RE: We currently don't have
)
I didn't figure that you wanted to change deadlines. It has been 2 weeks for quite a long time, with the exception of S5R2 @ 3 weeks.
So when you all consider the next round of credit lowering, please keep in mind that users are not flocking in droves to Einstein to chase credits. The "credit inflation" monster seems largely a myth. Sure, there will be a few credit-chasers, but it seems like most people join projects based on the perceived merit or their own personal interest. Because of this, keeping in line with SETI should probably be what you all shoot for.
Looking through BOINCStats project statistics:
Einstein is averaging 65-75 new users/day, 210-270 new hosts/day.
SETI: 360-420, 1000-1150.
CPDN: 95-105, 190-200.
Rosetta: 178-185, 590-640.
World Commmunity Grid: 230-260, 630-830.
The big payout project compared to Einstein, RieselSieve: 9-10, 37-42.
So basically if i understand
)
So basically if i understand the OP. This is my analogy
Einstein set @ 1% share
SETI @ 99% share
A standard pentium 4 @ 3ghz wont finish an einstein unit at 1% within 2 weeks. Therfore it is taking advantage of the EDF system.
RE: Second, I get the fact
)
That's exactly what I'm saying. A 10% allocation across 14 days is a maximum of 33.6 hours of work with 100% utilization. It is actually lower than that, but that's getting very technical. There was a HUGE difference in the runtime of S4/S5R1 vs. S5R2/S5R3. You could probably get 4-8 S4/S5R1 results to work on at that low of an allocation and still complete them without entering EDF. However, since you cannot download just part of a result here, the one result is estimating 61 hours, which at 10% simply cannot be done (61 > 33.6).
This was all covered in the complaining about S5R2. With your relatively low credit and RAC, I'm going to guess you missed most/all of S5R2. I was a loud complainer back then. I felt that S5R2 was a public beta test of alpha-level code. IMO, the project is just now getting things back under control.
As I said, IMO the project messed up in not increasing S5R2 deadlines to 4 or even 6 weeks. They also messed up by cutting deadlines back to 2 weeks without seeing that the runtimes were actually not 1/3 of the S5R2 runtimes.
It does handle it just fine. I don't mean to be offensive, but again I'm just going to be honest. You're a "doubting Thomas" (although your name is Bob, I guess). :sigh:
What will happen, provided you do not tinker with BOINC, is that Rosetta and SETI will each get some extra time now. I've witnessed this event happen on my own machine, where Einstein would run longer than 1 hour at a time. My shares are 66/33/1 (SETI/Einstein/LHC). SETI should run for about 2 hours, then Einstein for about 1 hour. At the time, I didn't have LHC work to do...