V8 has been successfully rolled out and Lunatics has released their new version...

---

... so there's nothing to panic about at all!

(ducks)

Dang, locked out the old thread while I was composing a reply! ;^)

Okay, reply to Message 1758837:

Both the GTX cards are running on Haswell rigs with the Intel GPU also running 3 jobs and the CPU running 7 jobs. The Xeon machine is running 3 CPU jobs. The Intel Haswell GPU rigs are averageing 2.5 to 2.79 turnaround days.

Turn around days are like Credits, they are a lagging indicator & it will take several days for the numbers to reflect reality.
That's why I prefer to use actual run times.

It also seems to me that "Average turnaround time" can be affected by numerous factors unrelated to what you're trying to observe. Such as the size of your work buffer (especially if you happen to change it), whether you run less than 24/7, other BOINC projects that may use GPU time, or the normally changing mix of angle ranges for the tasks you receive (with "normal" ARs taking longer to turn around than the "shortie" higher ARs that you often see mentioned here).

I agree with Grant that manually recording actual run times (spreadsheet, database, scratch pad, napkin, or whatever) gives you the best picture of performance. Just pick two or three common Angle ranges (I like tasks around 0.41nnnn for a normal AR and perhaps 2.72nnnn for higher ones), check your recent tasks for Stderrs with those ARs which don't show an overflow condition, and record them. You should find that the run times and CPU times for any given AR will stay pretty consistent, with only an occasional one that's abnormally high.

---

The underlying problem with 'averages', is not a new or mysterious thing. They are susceptible to various kinds of noise, and don't respond to change well (promptly without overshoot). Distilling things down as much as I could on a Sunday morning.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

One way to get a good look at your runtimes is to simply disable you network activity for awhile, then you can get a good look at what is in your upload queue.

One way to get a good look at your runtimes is to simply disable you network activity for awhile, then you can get a good look at what is in your upload queue.

But that won't tell you what the AR is for each task, which is the only way you can be sure you're comparing apples to apples. You still have to dig for that info.

EDIT: You also have to know whether a task was a -9 overflow or not.

---

Inconclusives are certainly a lot less than before.

So far most of the ones I've got are against x86_64-apple-darwin systems, and one Windows system.

2038109353
2038051505
2038004355
2037962132
2037732068
2037292502

---

Grant
Darwin NT

By design, Eric amped up the precision, and we follow suit as the manpower and technology allows,

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Inconclusives are certainly a lot less than before.

So far most of the ones I've got are against x86_64-apple-darwin systems, and one Windows system.

+1

---

Kevin

Matt talked about MB tasks getting 4 time bigger than now.

Does the Tasks recorded at Green Bank with the new recorder, will be bigger?(And minimize the overlap?)

---

As far as I'm aware the GBT data sets will be bigger, the band width of the receivers is bigger, overlap will be a similar proportion of the sample.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

The tasks i have processed so far at beta were only a few KB bigger but are merely VLAR`s.

I downloaded a few for testing and file size is 365xxx bytes.

---

With each crime and every kindness we birth our future.

Just looked at my active rig and it had 104 download errors, all on V8 CUDA tasks.

While I watched it successfully reported and downloaded new CPU tasks.

Is anyone else getting these download errors ?

EDIT: Running stock apps with no app_info file. It appears the V8 CUDA 4.2 app downloaded and installed ok. It's only the WU's that failed.

T.A.

This corner of the upper left coast is download error free.

---

None to report here....
All quiet on the kitty front.

---

"Time is simply the mechanism that keeps everything from happening all at once."

WOW! What was that all about?

---

Don't know. Everything went wonky.

---

Possibly a small glitch ... glitch .... glitch ... in the matrix. Probably nothing to worry about.

Possibly a small glitch ... glitch .... glitch ... in the matrix. Probably nothing to worry about.

Possibly a small glitch ... glitch .... glitch ... in the matrix. Probably nothing to worry about.

Bob

---

Sometimes I wonder, what happened to all the people I gave directions to?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SETI@home classic workunits 4,321
SETI@home classic CPU time 22,169 hours

Hmmm, what ever happened is still affecting the AP results out in the field reporting. Looks like it is not updating.

AP Tasks were available on 24 Jan 2016, at 20:50:04 UTC [Channels Total=42, Prog=5, Done=24, To Do=13] ROITF=101,300, RRLH=1,193
AP Tasks were available on 24 Jan 2016, at 21:00:04 UTC [Channels Total=42, Prog=5, Done=26, To Do=11] ROITF=101,619, RRLH=988
The  SSP Time Did Not Change as of 24 Jan 2016, 21:26
AP Tasks were available on  [Channels Total=, Prog=, Done=, To Do=] ROITF=, RRLH=
The  SSP Time Did Not Change as of 24 Jan 2016, 21:36
The  SSP Time Did Not Change as of 24 Jan 2016, 21:46
The  SSP Time Did Not Change as of 24 Jan 2016, 21:56
The  SSP Time Did Not Change as of 24 Jan 2016, 22:06
The  SSP Time Did Not Change as of 24 Jan 2016, 22:16
AP Tasks were available on 24 Jan 2016, at 22:10:04 UTC [Channels Total=42, Prog=5, Done=26, To Do=11] ROITF=102,035, RRLH=949
AP Tasks were available on 24 Jan 2016, at 22:30:03 UTC [Channels Total=42, Prog=5, Done=26, To Do=11] ROITF=102,035, RRLH=949
AP Tasks were available on 24 Jan 2016, at 22:40:03 UTC [Channels Total=42, Prog=5, Done=26, To Do=11] ROITF=102,035, RRLH=949
The 24 Jan 2016, 22:40:03 UTC SSP Time Did Not Change as of 24 Jan 2016, 22:52
AP Tasks were available on 24 Jan 2016, at 23:00:03 UTC [Channels Total=42, Prog=5, Done=26, To Do=11] ROITF=102,035, RRLH=949
AP Tasks were available on 24 Jan 2016, at 23:10:03 UTC [Channels Total=42, Prog=5, Done=26, To Do=11] ROITF=102,035, RRLH=949
AP Tasks were available on 24 Jan 2016, at 23:20:03 UTC [Channels Total=42, Prog=5, Done=26, To Do=11] ROITF=102,035, RRLH=949
The 24 Jan 2016, 23:20:03 UTC SSP Time Did Not Change as of 24 Jan 2016, 23:32
AP Tasks were available on 24 Jan 2016, at 23:40:03 UTC [Channels Total=42, Prog=5, Done=26, To Do=11] ROITF=102,035, RRLH=0
AP Tasks were available on 24 Jan 2016, at 23:50:06 UTC [Channels Total=42, Prog=4, Done=26, To Do=12] ROITF=102,035, RRLH=0
AP Tasks were available on 25 Jan 2016, at 0:00:05 UTC [Channels Total=42, Prog=4, Done=26, To Do=12] ROITF=102,035, RRLH=287
AP Tasks were available on 25 Jan 2016, at 0:10:05 UTC [Channels Total=42, Prog=4, Done=27, To Do=11] ROITF=102,035, RRLH=287
AP Tasks were available on 25 Jan 2016, at 0:20:06 UTC [Channels Total=28, Prog=4, Done=17, To Do=7] ROITF=102,035, RRLH=1,226
The 25 Jan 2016, 0:20:06 UTC SSP Time Did Not Change as of 25 Jan 2016,  0:32
AP Tasks were available on 25 Jan 2016, at 0:40:04 UTC [Channels Total=28, Prog=4, Done=17, To Do=7] ROITF=102,035, RRLH=2,149
AP Tasks were available on 25 Jan 2016, at 0:50:04 UTC [Channels Total=28, Prog=4, Done=17, To Do=7] ROITF=102,035, RRLH=2,289

Work requests are getting "no tasks available." SSP ready to send hasn't updated in 4 hours.

---

David
Sitting on my butt while others boldly go,
Waiting for a message from a small furry creature from Alpha Centauri.