I just noticed these. They have a 900+ day crunching time estimate. Any ideas?

Tom

Application
Local: setiathome_v8 8.00 
Name
25mr13ab.8426.484291.8.35.198
State
Running
Received
Fri 17 Jan 2020 12:25:35 AM CST
Report deadline
Thu 06 Feb 2020 11:35:16 AM CST
Estimated computation size
5,875 GFLOPs
CPU time
00:27:34
CPU time since checkpoint
00:03:31
Elapsed time
00:27:42
Estimated time remaining
954d 11:09:47
Fraction done
0.002%
Virtual memory size
44.89 MB
Working set size
32.90 MB
Directory
slots/7
Process ID
17546
Executable
MBv8_8.22r4008_avx2_intel_x86_64-pc-linux-gnu

Application
Local: setiathome_v8 8.00 
Name
25mr13ab.8426.484291.8.35.208
State
Running
Received
Fri 17 Jan 2020 12:25:35 AM CST
Report deadline
Thu 06 Feb 2020 11:35:16 AM CST
Estimated computation size
5,875 GFLOPs
CPU time
00:27:30
CPU time since checkpoint
00:03:24
Elapsed time
00:27:36
Estimated time remaining
950d 13:46:57
Fraction done
0.002%
Virtual memory size
44.89 MB
Working set size
32.91 MB
Directory
slots/14
Process ID
17840
Executable
MBv8_8.22r4008_avx2_intel_x86_64-pc-linux-gnu

---

A proud member of the OFA (Old Farts Association).

Which of your computers?
Which processor on that computer?
Anything else running?
Without that information everyone is shooting in the dark

---

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

I just noticed these. They have a 900+ day crunching time estimate. Any ideas?
Tom

. . I would suggest you suspend them both, let 2 more tasks begin and get well established then resume them. They should go waiting then restart on the next 2 CPU cores that become available. Monitor to see that they do not repeat the behaviour and they should run normally. If they do repeat the behaviour then 86 them :)

Stephen

. .

my 2c worth.

Looks like a computer problem, not a data problem. MBv8_8.22r4008_avx2_intel_x86_64-pc-linux-gnu looks like a homebrew / Anonymous Platform application, not one of Eric's. Can we move this query to another thread, please? I suggest he takes it up with the author of that app.

Which of your computers?
Which processor on that computer?
Anything else running?
Without that information everyone is shooting in the dark

https://setiathome.berkeley.edu/show_host_detail.php?hostid=8853145

These are/were cpu tasks running on an Amd 3950x under Linux. The total threads I run are 28-29. Task manager claims ~90% cpu load. I am running 100% Seti@Home at the moment.

I had to reboot the computer because a lower cpu voltage experiment had made rendered it unresponsive after 15 odd minutes. Now, none of the tasks are showing extreme, long time estimates.

Have to run off to work in the midst of freezing rain. Will see if I can "find" these tasks after work.
Tom

---

A proud member of the OFA (Old Farts Association).

If a task has done 0.002% in 27 minutes 34 seconds, then linear extrapolation suggests that the whole task will take 83,100,000 seconds - or about 961.8 days. I reckon BOINC's estimate of 954 days 11 hours was pretty close, if a little low.

Alternatively: without volts, CPUs don't run very fast. Maybe your computer would have responded if you'd waited about 3 years?

Name
25mr13ab.8426.484291.8.35.198

Is this an Arecibo Shorty (VHAR)?
From the README_x41p_V0.98.txt included in the package;

8) The CPU Progress bar may stall with High AR Work Units, the task will finish normally, it's just the Progress Bar that's stalled.

If you aren't showing any Errors on those tasks I suggest you let them run and see how long it takes them to finish as per the ReadMe. It's Not just the Windows SoG App that doesn't like Arecibo (VHAR) Shorties, there are a number a Apps built from Raistmer's Code that don't respond well to Shorties.

Name
25mr13ab.8426.484291.8.35.198

Is this an Arecibo Shorty (VHAR)?
From the README_x41p_V0.98.txt included in the package;

8) The CPU Progress bar may stall with High AR Work Units, the task will finish normally, it's just the Progress Bar that's stalled.

If you aren't showing any Errors on those tasks I suggest you let them run and see how long it takes them to finish as per the ReadMe. It's Not just the Windows SoG App that doesn't like Arecibo (VHAR) Shorties, there are a number a Apps built from Raistmer's Code that don't respond well to Shorties.

Let's call them properly VHAR tasks with high angle range. The task in question has: WU true angle range is : 48.172349

An Arecibo "shorty" could just as well of been an early or late overflow with low crunch times.

I've been seeing lots of these "stalled" tasks lately from all the old Arecibo data we have been reprocessing. Other than the task getting shifted into high priority mode, they finish fine in the expected length for easy tasks. Just ignore the progress bar and the estimation.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

Looks like a computer problem, not a data problem. MBv8_8.22r4008_avx2_intel_x86_64-pc-linux-gnu looks like a homebrew / Anonymous Platform application, not one of Eric's. Can we move this query to another thread, please? I suggest he takes it up with the author of that app.

I'm not sure what other thread is more appropriate. The thread is specifically about the latest alternative optimized cpu app that is provided in TBar's latest AIO. Just another in the line of AVX2 enabled cpu applications he has provided over the years.

Anybody run the new app through the benchmarks yet with a comparison run against the default r3711 SSE41 cpu app? Tom did you?

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

The post from Richard was the one that triggered the question's move from its initial location to a thread all of its own.

---

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

The post from Richard was the one that triggered the question's move from its initial location to a thread all of its own.

Oh. Wasn't aware the thread started elsewhere. Nevermind.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

Anybody run the new app through the benchmarks yet with a comparison run against the default r3711 SSE41 cpu app?

After spending DAYS trying to get the AKv8 OpenCL App to compile in the newer Linux systems it has come to my attention a large number of Optimizations were left out of the CPU Apps. It May be possible to build a New CPU App with better speed using those said Optimizations. Right now I'm trying to find the System calls named by Eric & RueiKe that should be left out of the OpenCL App. Not having much luck. Anyone know just WHERE in the code "funsafe-math-optimizations" & "unsafe-fp-opt" are lurking? The New OpenCL App is a little faster than r3584, I suspect a Newer CPU App can be faster than r3711 as well.

Can we stick to the problem about the AVX2 app, which is a CPU app, not a GPU app.

---

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

It should be in the configure file for the app. Either on the CPPFLAGS= line or CFLAGS= line or on the configure line itself. At least that is where I found and modified the math optimizations for my aarch_64 zi3v app.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

Not and have any input from Me.

Can we stick to the problem about the AVX2 app, which is a CPU app, not a GPU app.

Don't think there is any problem with the AVX2 app. Simply Tom not understanding that like all the cpu apps, it does not move the progress bar normally with VHAR tasks.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

those appear to be compiler options. not in the code itself.

---

Seti@Home classic workunits: 29,492 CPU time: 134,419 hours

Then why has it taken so many posts for you to explain that to him (in public).

---

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

those appear to be compiler options. not in the code itself.

I've searched a couple versions of the sah_v7_opt folder and can't find those lines anywhere in the files. I even moved the current r4101 sah_v7_opt to my Mac, which has a Much better search routine, and still can't find unsafe-fp-opt or funsafe-math-optimizations anywhere in the folder. On a Mac, if those lines were in the sah_v7_opt folder, it would find them.

For instance, if I search for CalcChirpData_kernel_df64_cl in the sah_v7_opt folder , the two files analyzeFuncs.cpp & MultiBeam_Kernels.cl instantly pop up, meaning those two files contain the line CalcChirpData_kernel_df64_cl in them. Searching for unsafe-fp-opt & funsafe-math-optimizations finds nothing...

Perhaps these were compiler options that Eric was adding himself, but not in the default configuration. So there may not be anything for you to remove.

“unsafe-fp-opt” doesn’t appear to be a valid compiler option. Google returns 0 results when trying for an exact match. Whatever option you’re looking for, it’s likely called something else.

---

Seti@Home classic workunits: 29,492 CPU time: 134,419 hours