I know the convo was moving fast and furiously at that point, but anyone want to chime in on my post Post 1881379 ? I'd just prefer to not muff anything up. Oh, and just re-read this thread again (whew) and was wondering if there were links posted to the latest/current verions of the apps?

---

Thanks for the thoughts guys. So, I guess I should install the latest Lunatics package, do I have to uninstall it or just install the new one over it? Will that one have an SOG option as well? It's been a while since I messed with that, but I vaguely remember there was a bit more to it than just installing the software.

*edit* Oh, and since this thread is about the rescheduler and Mr Kevvys app, and was one of the reasons I posted it here, would it be a good idea to install it after installing the SOG app, or would that not be necessary as the SOG app handles such things?

Al,
I have re-run the Lunatics installer without having un-installed Lunatics. It doesn't seem to "trash" anything. However, I have not tried it with an "elderly" version of the Lunatics installer.

If you are feeling very paranoid (something that I can approve of, sometimes) you can either hand patch the beta6 installer resulting app_info.xml so it will recognize all the current stock Seti (eg. 822, etc) or you can run all your tasks out for Seti. Do a reset/remove/re-install cycle. Download some stock 8.22 tasks. Then use the Beta6 with the manual patch and you will be back in business with the current release including the SOG.

Or you can run your self out of tasks. Run the beta6 installer w/o changing anything else. Then start tasks and see if it behaves "normally".

I would be tempted to set the "get no new tasks" on tuesday morning for the blackout to run your gpu dry and then run the beta6 installer and turn the tasks on again. If nothing complains then you haven't trashed/aborted any tasks and you are golden.

All this assumes we are talking about under Windows. I have NO expertise for Linux on this.

HTH,
Tom

---

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

You can re-run any Lunatics installer as many times as you want over the top of a previous one. Richard made the installer bullet-proof. Just choose your apps. The only disadvantage of the
Beta-6 installer is that it doesn't have the latest SoG app. It only has the r3557 app. No harm, no big deal. Of no consequence really compared to the r3584 SoG app that is available at Mikes World. You just have to hand enter the r3584 app over the r3557 app and copy the r3584 app and r3584.CL file into the directory. Use the Find and Replace function in Notepad.

---

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

A proud member of the OFA (Old Farts Association)

Ok thanks, I will set it to NNT so after the Tuesday outage and the system has pretty much finished up all the tasks it has anyways because said outage, I'll do the upgrade/patch this afternoon, and see how it goes. And the lastest version of the rescheduler will work properly with the new apps?

---

Ok thanks, I will set it to NNT so after the Tuesday outage and the system has pretty much finished up all the tasks it has anyways because said outage, I'll do the upgrade/patch this afternoon, and see how it goes. And the lastest version of the rescheduler will work properly with the new apps?

I haven't had any trouble with the latest SoG apps with the Rescheduler. I HAVE no luck with the Rescheduler with the CUDA80 tasks. NO WORKY! I did have success with the cpu2gpu.pl script though. Just underestimated.

---

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

A proud member of the OFA (Old Farts Association)

Well, I DL'ed both programs, and there were about 20 odd CPU tasks on the list, but I decided to shut it down and do the update regardless. It appeared to go well, and I edited the app_info file and inserted the 3585 into it. Just restared it and allowed new tasks, and here is the startup log. It appears that there are no errors?

8/1/2017 10:15:30 PM | | Starting BOINC client version 7.6.22 for windows_x86_64
8/1/2017 10:15:30 PM | | log flags: file_xfer, sched_ops, task
8/1/2017 10:15:30 PM | | Libraries: libcurl/7.45.0 OpenSSL/1.0.2d zlib/1.2.8
8/1/2017 10:15:30 PM | | Data directory: C:\ProgramData\BOINC
8/1/2017 10:15:30 PM | | Running under account Flash
8/1/2017 10:15:31 PM | | CUDA: NVIDIA GPU 0: GeForce GTX 1070 (driver version 378.66, CUDA version 8.0, compute capability 6.1, 4096MB, 3046MB available, 6900 GFLOPS peak)
8/1/2017 10:15:31 PM | | CUDA: NVIDIA GPU 1: GeForce GTX 980 Ti (driver version 378.66, CUDA version 8.0, compute capability 5.2, 4096MB, 3066MB available, 7271 GFLOPS peak)
8/1/2017 10:15:31 PM | | OpenCL: NVIDIA GPU 0: GeForce GTX 1070 (driver version 378.66, device version OpenCL 1.2 CUDA, 8192MB, 3046MB available, 6900 GFLOPS peak)
8/1/2017 10:15:31 PM | | OpenCL: NVIDIA GPU 1: GeForce GTX 980 Ti (driver version 378.66, device version OpenCL 1.2 CUDA, 6144MB, 3066MB available, 7271 GFLOPS peak)
8/1/2017 10:15:31 PM | SETI@home | Found app_info.xml; using anonymous platform
8/1/2017 10:15:31 PM | | Host name: FlashFlyer
8/1/2017 10:15:31 PM | | Processor: 8 GenuineIntel Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz [Family 6 Model 58 Stepping 9]
8/1/2017 10:15:31 PM | | Processor features: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss htt tm pni ssse3 cx16 sse4_1 sse4_2 popcnt aes f16c rdrandsyscall nx lm avx vmx tm2 pbe fsgsbase smep
8/1/2017 10:15:31 PM | | OS: Microsoft Windows 7: Ultimate x64 Edition, Service Pack 1, (06.01.7601.00)
8/1/2017 10:15:31 PM | | Memory: 31.95 GB physical, 63.89 GB virtual
8/1/2017 10:15:31 PM | | Disk: 223.47 GB total, 135.96 GB free
8/1/2017 10:15:31 PM | | Local time is UTC -5 hours
8/1/2017 10:15:31 PM | SETI@home | Found app_config.xml
8/1/2017 10:15:31 PM | | Config: event log limit disabled
8/1/2017 10:15:31 PM | | Config: use all coprocessors
8/1/2017 10:15:31 PM | | A new version of BOINC is available. (7.6.33) <a href=http://boinc.berkeley.edu/download.php>Download</a>
8/1/2017 10:15:31 PM | SETI@home | URL http://setiathome.berkeley.edu/; Computer ID 8017700; resource share 100
8/1/2017 10:15:31 PM | SETI@home | General prefs: from SETI@home (last modified 03-Apr-2013 23:59:56)
8/1/2017 10:15:31 PM | SETI@home | Computer location: home
8/1/2017 10:15:31 PM | SETI@home | General prefs: no separate prefs for home; using your defaults
8/1/2017 10:15:31 PM | | Reading preferences override file
8/1/2017 10:15:31 PM | | Preferences:
8/1/2017 10:15:31 PM | | max memory usage when active: 16357.26MB
8/1/2017 10:15:31 PM | | max memory usage when idle: 31078.80MB
8/1/2017 10:15:31 PM | | max disk usage: 100.00GB
8/1/2017 10:15:31 PM | | (to change preferences, visit a project web site or select Preferences in the Manager)



Anything look out of the ordinary? Hoping everything went well, and new tasks are downloading, so all appears well. We'll see in the morning.

---

Well, I DL'ed both programs, and there were about 20 odd CPU tasks on the list, but I decided to shut it down and do the update regardless. It appeared to go well, and I edited the app_info file and inserted the 3585 into it. Just restared it and allowed new tasks, and here is the startup log. It appears that there are no errors?
...
Anything look out of the ordinary? Hoping everything went well, and new tasks are downloading, so all appears well. We'll see in the morning.

Looks clean to me.
FWIW, I've never found it necessary to empty the cache before doing this.
Later, Jim ...

---

Well, I DL'ed both programs, and there were about 20 odd CPU tasks on the list, but I decided to shut it down and do the update regardless. It appeared to go well, and I edited the app_info file and inserted the 3585 into it. Just restared it and allowed new tasks, and here is the startup log. It appears that there are no errors?
...
Anything look out of the ordinary? Hoping everything went well, and new tasks are downloading, so all appears well. We'll see in the morning.

Looks clean to me.
FWIW, I've never found it necessary to empty the cache before doing this.
Later, Jim ...

I have had several experiences where if I didn't empty the cache before installing Lunatics beta 6, on Boinc startup "it" would delete all the 8.22 Gpu tasks as "unrecognized" unless I manually changed one of the entries in the "app_info.xml" file to catch those. The first time it clobbered 90+ cpu tasks.

Tom

---

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

Well, I DL'ed both programs, and there were about 20 odd CPU tasks on the list, but I decided to shut it down and do the update regardless. It appeared to go well, and I edited the app_info file and inserted the 3585 into it. Just restared it and allowed new tasks, and here is the startup log. It appears that there are no errors?
...
Anything look out of the ordinary? Hoping everything went well, and new tasks are downloading, so all appears well. We'll see in the morning.

Looks clean to me.
FWIW, I've never found it necessary to empty the cache before doing this.
Later, Jim ...

I have had several experiences where if I didn't empty the cache before installing Lunatics beta 6, on Boinc startup "it" would delete all the 8.22 Gpu tasks as "unrecognized" unless I manually changed one of the entries in the "app_info.xml" file to catch those. The first time it clobbered 90+ cpu tasks.

Tom

. . Hi Tom,

. . That is because version 8.22 (r3584) of SoG is not included in Beta 6 of Lunatics. So yes you need to edit app_info.xml to add/modify the listing for 8.22 tasks to use the 8.20 app (r3557) to process 8.22 tasks. It will happily do that as long as it knows which app to use for them. Or you can update it to 8.22 (the actual app should already be in your project folder). But you do not have to empty your cache. Merely suspend processing on all unstarted tasks and let running tasks finish before running the installer, then edit app_info.xml before resuming processing. No dramas and no task loss.

Stephen

:)


Stephen

Just got a copy of the "qopt.exe" to download after fighting with my Anti-virus :)

And now have it "installed" in the BOINC directory. After playing with it a couple of times I think I have it setup in the scheduler for my Jupiter 2 aka: E5 etal box.

I do have a question about Mr. Kevvi's program.

As an experiment I am running my Mercury box (with a newly installed used gtx 1060) as a Seti Gpu only box. I do have non-seti running on the cpu.

I just ran the rescheduler by hand and want to know if maybe there is "nothing to exchange with the gpu tasks, it won't transfer tasks to the cpu?"

Thanks,
Tom

---

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

I just ran the rescheduler by hand and want to know if maybe there is "nothing to exchange with the gpu tasks, it won't transfer tasks to the cpu?"

Thanks,
Tom

It appears that a -c10 is needed for my Boinc Manager to restart/reconnect so I have added that to the scheduler.

Tom

---

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

Well, I DL'ed both programs, and there were about 20 odd CPU tasks on the list, but I decided to shut it down and do the update regardless. It appeared to go well, and I edited the app_info file and inserted the 3585 into it. Just restared it and allowed new tasks, and here is the startup log. It appears that there are no errors?
...
Anything look out of the ordinary? Hoping everything went well, and new tasks are downloading, so all appears well. We'll see in the morning.

Looks clean to me.
FWIW, I've never found it necessary to empty the cache before doing this.
Later, Jim ...

I have had several experiences where if I didn't empty the cache before installing Lunatics beta 6, on Boinc startup "it" would delete all the 8.22 Gpu tasks as "unrecognized" unless I manually changed one of the entries in the "app_info.xml" file to catch those. The first time it clobbered 90+ cpu tasks.

Tom

. . Hi Tom,

. . That is because version 8.22 (r3584) of SoG is not included in Beta 6 of Lunatics. So yes you need to edit app_info.xml to add/modify the listing for 8.22 tasks to use the 8.20 app (r3557) to process 8.22 tasks. It will happily do that as long as it knows which app to use for them. Or you can update it to 8.22 (the actual app should already be in your project folder). But you do not have to empty your cache. Merely suspend processing on all unstarted tasks and let running tasks finish before running the installer, then edit app_info.xml before resuming processing. No dramas and no task loss.

Stephen

:)


Stephen

I just ran the rescheduler by hand and want to know if maybe there is "nothing to exchange with the gpu tasks, it won't transfer tasks to the cpu?"

Thanks,
Tom

It appears that a -c10 is needed for my Boinc Manager to restart/reconnect so I have added that to the scheduler.

Tom

It will move from CPU to GPU in the absence of an exchange, but not vice-versa. Long discussion much eralier in this thread as to why that makes sense, if you're interested.
Regarding the -cx delay timer, I'm starting to think that's related to a startup issue I've seen discussion about on BOINC_Alpha. May be interesting to see how that looks when 7.8.x hits the street. Interesting to hear that it actually helped someone. I added that as a debugging tool and never heard that it actually was helpful:) I see you're running 7.6.33, so the issue was still out there.

---

I was looking at my historical results via "Boinc Tasks" (THANK YOU!) and when I sorted them by work unit names I noticed that the Guppi tasks were running in the 2-3 hour range but the "non-guppi" tasks (in cpu) were running in the 3-4 hour range.

Wow.

I hadn't segmented it out previously. I can now see how running Guppi tasks on the cpu would boost your production giving that major general trend. So far, running Guppi's on the gpu is still much faster than on the cpu but I have a LOT more cpu cores than gpu "cores" :)

I think I read this result is specific to the Nvidia gpu? Apparently AMD gpu's run the guppi's at the same pace as the non-guppi's? But even if that is true, it seems to me that the cpu differential should hold up.

That sound's like a scheduler upgrade project. I wonder if we could find a volunteer programmer team to take that on? It would speed up the whole infrastructure. Setup a parameter file driven scheduler so that at least for now, if it is a Guppi it is issued as a cpu task only.

Tom

---

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

That sound's like a scheduler upgrade project. I wonder if we could find a volunteer programmer team to take that on? It would speed up the whole infrastructure. Setup a parameter file driven scheduler so that at least for now, if it is a Guppi it is issued as a cpu task only.

Tom

Not gonna happen, Tom.
At some point Arecibo data will either be scarce or unavailable. We are already reprocessing '08 data with the newer apps.
When Arecibo data is unavailable, all work will be Guppi, unless or until some other data sources are brought into the mix.
And as far as the project goes, restricting Guppi work to CPU only would not be a priority at all.

Just my opinion, of course.

---

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

Mark is correct Tom.

The future of all work units will be "Guppi" or more actually BLC..since some BLC won't have guppi in their name (tends to confuse some people) I'm guilty because I was among the first to coin that term and realized later it confused alot of people.

Z

---

Hi,

The BLC/GBT/Guppi work units complete in under 2 or 3 minutes on NVIDIA with the 1080 and the 1080Ti running 'special' app. The old CUDA 50 app is slow. The same applies to Arecibo vlars. So I don't reschedule.

Petri

---

To overcome Heisenbergs:
"You can't always get what you want / but if you try sometimes you just might find / you get what you need." -- Rolling Stones

...When Arecibo data is unavailable, all work will be Guppi, unless or until some other data sources are brought into the mix.

Maybe we could talk these guys into either installing a multi-gigabit trans pacific data link or maybe schedule regular shipments of HD's full of data to process between there and Berkeley? ;-) Especially since we apparently have decided the funding even a basic level of research at a facility that has been paid off for many years, and is still completely functional and produces good scientific data, is no longer worthwhile. Oh! But the Chinese seem to think that it is. Funny, that. And the first statement in the comments section of the article summed up my feelings to a T:

While U.S. Ponders Closing Arecibo China Builds Something Much Bigger

Bulldog • a year ago

Proof positive of a society in decline. No human space flight capability, dumped the Superconducting Super Collider, Fermilab Tevatron shutdown, ceding superiority in ground based optical astronomy, now serious discussion of closing Arecibo. Hey, its okay though, Dancing with the Stars is on tonight. <facepalm>

Little more info on it if you're interested.

China uproots 9,000 people for huge telescope in search for aliens

China begins operating world's largest radio telescope

Link to Sat image of it on Google maps

But Hey! Last I heard, that 2 Billion that they spent before killing the Superconducting Super Collider seems to returning at least something on the investment. I guess they are (or were, haven't checked recently) growing mushrooms down there! Spectacular. Too bad they couldn't find a way to finish it, and could have made the discoveries that the Large Hadron Collider has made since 2008, but might have been done a decade or more sooner, and it would have actually been the USA that lead the way. Sad, all just very sad.

The Supercollider That Never Was

/rant off[/url]

---

I was looking at my historical results via "Boinc Tasks" (THANK YOU!) and when I sorted them by work unit names I noticed that the Guppi tasks were running in the 2-3 hour range but the "non-guppi" tasks (in cpu) were running in the 3-4 hour range.

Wow.

I hadn't segmented it out previously. I can now see how running Guppi tasks on the cpu would boost your production giving that major general trend. So far, running Guppi's on the gpu is still much faster than on the cpu but I have a LOT more cpu cores than gpu "cores" :)

I think I read this result is specific to the Nvidia gpu? Apparently AMD gpu's run the guppi's at the same pace as the non-guppi's? But even if that is true, it seems to me that the cpu differential should hold up.

That sound's like a scheduler upgrade project. I wonder if we could find a volunteer programmer team to take that on? It would speed up the whole infrastructure. Setup a parameter file driven scheduler so that at least for now, if it is a Guppi it is issued as a cpu task only.

Tom

. . This discussion has been running since guppis first appeared. I wouldn't hold your breath waiting for a scheduler change to optimise performance in this respect. Hence the need for the rescheduler. But while AMD cards do not seem to suffer as great an increase in runtimes for guppis as the Nvidia cards do, I believe they do still take longer than non-arecibo tasks, have a look at the results of someone running AMD. It has been observed from the beginning that guppies run more quickly on CPUs than Arecibo work and the complete opposite on GPUs. But finding an optimum setting is difficult because that depends on the relative abilities of of the CPU/GPU combination in use. For example with my i5/GTX950 combo the mix is about equal (maybe 40/60 to be peak), but on my other systems the GPUs can chew through many times the number of Arecibo tasks on the GPUs as the CPU's can manage in guppies, especially as some or many CPU cores are required to support GPU crunching. So when guppies are few like now it would be easy enough (in fact ATM I am finding it hard to get guppies for the CPU on this i5), but when the guppi floods are running they need to be crunched on GPUs as well as CPUs. I don't know that the good folk at SETI Central have the time or inclination to tackle such changes in the scheduler as would be needed to accommodate this degree of variability. So for now us geeks just hope to have the best possible re-scheduler we can get. A simpler but more pragmatic change might be to issue only Guppies and Arecibo VLARs to CPUs but everything to GPUs (perhaps with a priority on non-guppies).

. . That is my perspective and not news to most people I am sure.

Stephen

:)

That sound's like a scheduler upgrade project. I wonder if we could find a volunteer programmer team to take that on? It would speed up the whole infrastructure. Setup a parameter file driven scheduler so that at least for now, if it is a Guppi it is issued as a cpu task only.

Tom

Not gonna happen, Tom.
At some point Arecibo data will either be scarce or unavailable. We are already reprocessing '08 data with the newer apps.
When Arecibo data is unavailable, all work will be Guppi, unless or until some other data sources are brought into the mix.
And as far as the project goes, restricting Guppi work to CPU only would not be a priority at all.

Just my opinion, of course.

. . Hey, I am still waiting to see if we get any work from Parkes, they have been online for a long time now but we are not getting any data from them. I wonder if we need to fund some racks of water cooled recorders like at Greenback ? :)

Stephen

:)