Wow, i just looked.. the entire cache on that machine is all VLARs right now. So that WON'T be representative. I'll still grab two at random though. And then run this again in a few days when there is something that ISN'T a VLAR.

. . 90% of work these days IS VLAR including work from Arecibo. It seems the new Arecibo management are conducting a different approach to observations than the previous one. Maybe 1/3 of work from Arecibo is other than VLAR and that includes noise bombs, halflings and normals.

Stephen

:)

Wow, i just looked.. the entire cache on that machine is all VLARs right now. So that WON'T be representative. I'll still grab two at random though. And then run this again in a few days when there is something that ISN'T a VLAR.

. . 90% of work these days IS VLAR including work from Arecibo.

Well then if it is that many VLARs these days, then that's probably what I should optimize the app choice for, eh? So far, it is looking pretty good for that r3714_avx app, but mbbench is still running. I'll know in another 2-3 hours what the results are.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

Alright, it is done.

MBbench210.cmd 
====================================== 
 2 testWU(s) found  
     (blc11_2bit_guppi_58406_26261_HIP20357_0101.25007.818.21.44.146.vlar.wu) 
     (blc12_2bit_guppi_58405_85309_GJ687_0026.13619.409.22.45.253.vlar.wu) 
 1 reference science app(s) found 
     (setiathome_8.05_windows_x86_64.exe -verb -nog) 
 4 science app(s) found 
     (MB8_win_x64_AVX_VS2010_r3330.exe) 
     (MB8_win_x64_AVX_VS2017_r3714_Vlock.exe) 
     (MB8_win_x64_SSE2_VS2008_r3330.exe) 
     (MB8_win_x64_SSE3_VS2008_r3330.exe) 
====================================== 
------------ 
Quick timetable 
 
WU : blc11_2bit_guppi_58406_26261_HIP20357_0101.25007.818.21.44.146.vlar.wu 
setiathome_8.05_windows_x86_64.exe -verb -nog :
  Elapsed 3586.335 secs
      CPU 3579.615 secs
MB8_win_x64_AVX_VS2010_r3330.exe :
  Elapsed 1791.239 secs, speedup: 50.05%  ratio: 2.00x
      CPU 1787.413 secs, speedup: 50.07%  ratio: 2.00x
MB8_win_x64_AVX_VS2017_r3714_Vlock.exe :
  Elapsed 1717.407 secs, speedup: 52.11%  ratio: 2.09x
      CPU 1694.623 secs, speedup: 52.66%  ratio: 2.11x
MB8_win_x64_SSE2_VS2008_r3330.exe :
  Elapsed 1969.947 secs, speedup: 45.07%  ratio: 1.82x
      CPU 1965.675 secs, speedup: 45.09%  ratio: 1.82x
MB8_win_x64_SSE3_VS2008_r3330.exe :
  Elapsed 1896.772 secs, speedup: 47.11%  ratio: 1.89x
      CPU 1892.823 secs, speedup: 47.12%  ratio: 1.89x
 
WU : blc12_2bit_guppi_58405_85309_GJ687_0026.13619.409.22.45.253.vlar.wu 
setiathome_8.05_windows_x86_64.exe -verb -nog :
  Elapsed 3792.654 secs
      CPU 3780.201 secs
MB8_win_x64_AVX_VS2010_r3330.exe :
  Elapsed 1753.042 secs, speedup: 53.78%  ratio: 2.16x
      CPU 1749.723 secs, speedup: 53.71%  ratio: 2.16x
MB8_win_x64_AVX_VS2017_r3714_Vlock.exe :
  Elapsed 1656.109 secs, speedup: 56.33%  ratio: 2.29x
      CPU 1648.697 secs, speedup: 56.39%  ratio: 2.29x
MB8_win_x64_SSE2_VS2008_r3330.exe :
  Elapsed 1944.966 secs, speedup: 48.72%  ratio: 1.95x
      CPU 1940.840 secs, speedup: 48.66%  ratio: 1.95x
MB8_win_x64_SSE3_VS2008_r3330.exe :
  Elapsed 1934.552 secs, speedup: 48.99%  ratio: 1.96x
      CPU 1930.341 secs, speedup: 48.94%  ratio: 1.96x
 ------------ 

blc11_2bit_guppi_58406_26261_HIP20357_0101.25007.818.21.44.146.vlar
WU true angle range is : 0.011157

blc12_2bit_guppi_58405_85309_GJ687_0026.13619.409.22.45.253.vlar
WU true angle range is : 0.006934

So it looks like the two AVX apps are better than sse2 or sse3, but r3714 is a few % better. Again, if the bulk of the work these days is vlar, then it looks like r3714 is the clear winner.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

....
Well then if it is that many VLARs these days, then that's probably what I should optimize the app choice for, eh? So far, it is looking pretty good for that r3714_avx app, but mbbench is still running. I'll know in another 2-3 hours what the results are.

. Yes the VLAR's from all current sources are very prevalent here these days and mostly GBT as well so optimizing for them is the best solution (but we still have to wait to see what happens with the new Parkes' work when it gets here). ;-)

Cheers.

I think it wold be safe to assume that Parkes will give us VLARS as it is going to be doing target rather than sweep observations.

---

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

I think it wold be safe to assume that Parkes will give us VLARS as it is going to be doing target rather than sweep observations.

I would assume the same thing, but we've been taught about assumptions in the past too Rob. ;-)

Cheers.

This thread seems to have wandered way off topic.

Perhaps someone would like to make a new thread for this current discussion.

This thread seems to have wandered way off topic.

Perhaps someone would like to make a new thread for this current discussion.

These messages about which apps/bench-marking would also fit nicely into Keith's Misc. thread :)

---

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

I wasn't intending to hijack. I just know these Panic threads get the most attention from the regulars, and only really had one question, which seems to have been answered now.

Dunno if i'm going to actually start crunching MB though, but now I know what to use.

Resume normal panic.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

back already??

---

I think so, well, maybe......

---

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

~7 hours? not bad.

---

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

back already??

. . I was worried when it started about 3 hours early. That normally means a very long outrage but as pointed out before, less than 7 hours (with backoffs it could have been only 6).

. . Now all we need is some new work, my rigs are nearly out ...

Stephen

. .

The RTS queue is looking good... too good. 2500+ AP and 742K V8.... will the system just start handing some WUs out!!!

sigh, sorry for my outburst. hope we get some WUs soon.

The RTS queue is looking good... too good. 2500+ AP and 742K V8.... will the system just start handing some WUs out!!!

sigh, sorry for my outburst. hope we get some WUs soon.

. . +1 here ...

. . Please, please, please! Somebody kick the servers ...

Stephen

:(

Now that Richard has pointed me to the svn, I found the r3714 changeset
Does anyone want to take a crack at compiling the app for Linux?

If i`m not mistaken Raistmers last changes are not commited t to svn yet.

Returning after a couple of days away. I think Raistmer's last committed change was on 27 April with

-MB: attempt to enable ARMv7 CPU build via SIMDe SSE emulation layer; changes in configuration for ARM platform; temporary configure line for ARM

(r3755) If he's still struggling to make Android work, that's fine. But if he's making and distributing Linux apps, without updating the source - that's a no-no.

As Bernie says, none of this is to do with server problems - make a new thread, and I'll track it through tomorrow.

The RTS queue is looking good... too good. 2500+ AP and 742K V8.... will the system just start handing some WUs out!!!

sigh, sorry for my outburst. hope we get some WUs soon.

. . +1 here ...

. . Please, please, please! Somebody kick the servers ...

Stephen

:(

When I last looked both of mine are running "reserve" tasks without anything new from Seti. Tried a hand update a while ago, came back with a "back off 2+ hours".

Tom

---

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

The RTS queue is looking good... too good. 2500+ AP and 742K V8.... will the system just start handing some WUs out!!!

. . +1 here ...
. . Please, please, please! Somebody kick the servers ...

When I last looked both of mine are running "reserve" tasks without anything new from Seti. Tried a hand update a while ago, came back with a "back off 2+ hours".

. . My problem now is that I have empty caches with over half a cache load allocated that will not download ...

. . Where can I get some hair to tear out when I need it ..........

Stephen

:(

so this is a new one for me...

I do a scheduler request, and get a successful response, but BOINC also says that comms failed and the reference site was OK.

2018-12-04 21:56:22 SETI@home [sched_op_debug] Starting scheduler request
2018-12-04 21:56:22 SETI@home Sending scheduler request: To fetch work.
2018-12-04 21:56:22 SETI@home Requesting new tasks
2018-12-04 21:56:22 SETI@home [sched_op_debug] CPU work request: 179712.00 seconds; 8.00 CPUs
2018-12-04 21:56:24 Project communication failed: attempting access to reference site
2018-12-04 21:56:24 SETI@home Scheduler request completed: got 0 new tasks
2018-12-04 21:56:24 SETI@home [sched_op_debug] Server version 709
2018-12-04 21:56:24 SETI@home Message from server: No tasks sent
2018-12-04 21:56:24 SETI@home Message from server: No tasks are available for AstroPulse v7
2018-12-04 21:56:24 SETI@home Message from server: Your app_info.xml file doesn't have a usable version of SETI@home v8.
2018-12-04 21:56:24 SETI@home Message from server: Tasks for NVIDIA GPU are available, but your preferences are set to not accept them
2018-12-04 21:56:24 SETI@home Message from server: Tasks for AMD/ATI GPU are available, but your preferences are set to not accept them
2018-12-04 21:56:24 SETI@home Message from server: Tasks for Intel GPU are available, but your preferences are set to not accept them
2018-12-04 21:56:24 SETI@home Project requested delay of 303 seconds
2018-12-04 21:56:24 SETI@home [sched_op_debug] Deferring communication for 5 min 3 sec
2018-12-04 21:56:24 SETI@home [sched_op_debug] Reason: requested by project
2018-12-04 21:56:26 Internet access OK - project servers may be temporarily down.

Is this a new behavior that I just haven't noticed recently?

edit: Just looked at the other machine.. it looks like this is "normal"

2018-12-03 18:51:23 SETI@home [sched_op_debug] Starting scheduler request
2018-12-03 18:51:23 SETI@home Sending scheduler request: To fetch work. Requesting 21488 seconds of work, reporting 0 completed tasks
2018-12-03 18:51:25 Project communication failed: attempting access to reference site
2018-12-03 18:51:27 Internet access OK - project servers may be temporarily down.
2018-12-03 18:51:33 SETI@home Scheduler request succeeded: got 0 new tasks
2018-12-03 18:51:33 SETI@home [sched_ops_debug] Server version 709
2018-12-03 18:51:33 SETI@home Message from server: Project has no tasks available
2018-12-03 18:51:33 SETI@home Project requested delay of 303.000000 seconds
2018-12-03 18:51:33 SETI@home [sched_op_debug] Deferring communication for 7 min 24 sec
2018-12-03 18:51:33 SETI@home [sched_op_debug] Reason: no work from project

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

There is a scheduled outage for Tuesdays. The start time is variable and the end time is variable. When the outage is done the seti servers get clogged with us all trying to return finished WUs and get new WUs at once. There is never enough WUs in the RTS queue when it does start handing out WUs again, so there are a variety of errors of communication that are "normal" for Tuesdays.

edit: I'm concerned by the line mentioning you don't have a usable version of V8