Apropos, why are the auto-format buttons like [url] so far off-screen to the right here? I'm using Chrome on Windows XP.

It's the same on IE 10 on Win 7

Claggy

Hi!

There will be a mojor overhaul of the Web presence in the near future, so forgive us for not investing any significant time in fixing stuff in the legacy web front-end now.

Cheers
HB

---

First result validated, nice!

Link to workunit #371351

At a first glance on my machine the new run takes about 11000s or 3 hours longer per task to run than the LineVeto search over at Einstein but got the same amount paid. I suspect that this is going to be adjusted before we go live on Einstein, right?

Testing here is also used to adjust the credits for Einstein. The variations in run time of different "kinds" of tasks (frequency, etc) is much more pronounced in this run, e.g. older Core2 CPUs show a greater "run time scatter" than modern Sandy Bridge or Ivy Bridge CPUs. We need to understand these variations first and then find a compromise credit policy that is more or less fair to everyone.

Cheers
HB

---

Hello,

I have had four of the new GW search tasks validate so far. Runtime ranges from 7908 seconds average on one host to 8886 seconds average on another host. Currently memory usage per task in Linux is approximately 100 MB. The memory usage was at approximately 130 MB yesterday evening when I first started running the new tasks.

Jeroen

---

Apropos, why are the auto-format buttons like [url] so far off-screen to the right here? I'm using Chrome on Windows XP.

It's the same on IE 10 on Win 7

Claggy

Hi!

There will be a mojor overhaul of the Web presence in the near future, so forgive us for not investing any significant time in fixing stuff in the legacy web front-end now.

Cheers
HB

Hopefully it will include the latest BOINC message board stuff as the message pagination is quite useful, especially when on a mobile device.

I noticed that the h1_0996 tasks are taking 3-4 times longer than the h1_005x tasks. On one of my systems that is also running Einstein BRP tasks doubled in time also even with one core reserved for the GPU.

I noticed that the h1_0996 tasks are taking 3-4 times longer than the h1_005x tasks. On one of my systems that is also running Einstein BRP tasks doubled in time also even with one core reserved for the GPU.

Is this why people are aborting them? I got three aborts on a single unit, still not validated, and all of them were on CPUs faster than my Opteron 1210.
Tullio

---

Hi!

I haven't checked your tasks specifically but sometimes tasks are aborted by us on the server side as well (whenever we make some tweeks and we need to get the results from the tweaked stuff rather than wasting resources on completing the un-tweaked stuff, so to say).

Cheers
HB

---

I noticed that the h1_0996 tasks are taking 3-4 times longer than the h1_005x tasks. On one of my systems that is also running Einstein BRP tasks doubled in time also even with one core reserved for the GPU.

I see you have some Intel and AMD hosts, so this is valuable info. I wonder whether anything can be said about whether the spread of runtimes is especially bad on certain CPUs. We did some tests on a Sandy Bridge Inte CPU and the relative difference in runtime wasn't that big.

Anyway, thanks for the feedback, it's exactly this kind of results we are looking for from the testers who have a lager variety of systems in use than we have at our disposal.


Cheers
HB

---

I've seen variance in runtime up to about 3 hours on my overclocked i7 3770K @ 4.2GHz.

Task name                                     Run time     CPU time
h1_0997.05_S6Direct__S6CasAc_997.25Hz_721_1   24,107.54    24,081.17  
h1_0997.05_S6Direct__S6CasAc_997.25Hz_722_1   24,220.83    24,167.88
h1_0997.05_S6Direct__S6CasAc_997.25Hz_723_1   34,223.87    33,765.29 
h1_0997.05_S6Direct__S6CasAc_997.25Hz_724_1   34,273.24    33,806.84

Unfortunately I can't say anything about what was run at the same time as I've been mixing these tasks with Einstein work (FGRP, GW Line Veto & BRP5 on the GPU) and a few tasks from other projects.

---

I've started getting "Validate errors" on my S6 CasA tasks with version 1.05.

I can't see anything suspicious in Boinc's event log or in the task stderr, but as soon as a validation is tried both tasks get the status of Validate error and to new task are created.

Has something in the tasks changed that the validator can't cope with or is there some problem with the result files?

Link to my S6 Directed Search (CasA) task.

---

Same here on my Linux box. But I see Windows users getting the same error.
Tullio

---

Thanks for the feedback.

There was a problem in the validator that should now be fixed.

Later today I'll see what I can do about the older "validate error" results.

BM

Edit: I issued all "validate error" tasks that were still in the DB for "re-validation" by the new validator

Thanks, it looks a lot better now as all recent tasks have the status valid instead of validate error!

Hope we can get this sufficiently tested and released on Einstein soon.

---

Will take another week. The scientist that have the final word on it are away for another conference.

But technically it looks good so far.

BM

I have 4 units done and waiting for validation since December and January. But their wingmen are absent (unsent units). Why?
Tullio

---