My Inconclusive results are going up too, even though I've only had a handful of Tasks since last night. Last night I had a large number of Inconclusive results that said 'minimum quorum 1' and only listed a single Inconclusive host. I didn't see how a single Inconclusive host task could ever validate. Now, it's very difficult to bring up my Inconclusive tasks lists, but, it seems those tasks are now listed as; https://setiathome.berkeley.edu/workunit.php?wuid=3862758806
minimum quorum 1
initial replication 3

   Task    Computer            Sent                  Time reported                 Status        Runtime CPUtime Credit             Application
8495599283  1473578  31 Jan 2020, 5:02:48 UTC  31 Jan 2020, 21:47:15 UTC  Completed and validated  15.36  12.61   3.59  SETI@home v8 v8.20 (opencl_ati5_mac) x86_64-apple-darwin
8498611906  6796479   1 Feb 2020, 3:00:50 UTC   1 Feb 2020, 4:00:03 UTC   Completed and validated   4.10   1.93   3.59  SETI@home v8 v8.11 (cuda42_mac) x86_64-apple-darwin
8498669733  8673543   1 Feb 2020, 4:01:52 UTC   1 Feb 2020, 5:29:49 UTC   Completed and validated  15.11  13.09   3.59  SETI@home v8 v8.22 (opencl_nvidia_SoG)

So, the single host are now triple hosts, but they are still just sitting there with a number of them showing one or two Completed, waiting for validation hosts, and some with one or two Inconclusive hosts.

If you have really long work units, then increasing the limits for returned signals is not enough. A rfi spike will fill any reasonable limit and this will then mask all the good parts of the data. Bigger time windows mean more observation time is lost due to these events.

This is why I suggested in another post that the clients would process the long workunits in multiple parts that would match the size of the current workunits and produce result data separately for each part. So you could have result overflow for one part but good results for the rest.

Beta IS a project in and of itself and does not need to be created. It already exists on the same severs as SETI Prime does. It is there to test new apps and server software, hence the name Beta. I don't see messing with Beta when Prime needs more fixing.

What do you actually mean by "doubling task size"?
Do you mean just adding more data points to increase the file size from 700k to 1400k?
Do you mean doubling the resolution, so doubling the file size?
Do you mean putting two data sets into one file, so doubling the file size?

This amount is exponentially decaying as we go back in time, but the volunteers of this project can provide the computing power to convert (even re-calculate) that amount of data (as the computing power is exponentially growing), but I'm not sure if it should be converted at all. The architecture of the science database can be changed without changing the meaning the data in it, so this project can use a different architecture in the future.

Not as exponential as you might think, as the number of active users has diminished over that period. For several reasons, BOINC and credit screw to name but two.

Greetings,

What you guys may or may not know or understand is that there is already a 2nd project here at SETI. It's call Beta. That project resides on the same servers as SETI Prime does. What you are suggesting is for a 3rd project to be installed. I don't see the point. Just one man's opinion on this topic. ;)

Have a great day! :)

Siran

The science data base only allows 30 items of interest to be recorded, this is not going to change.

What forbids it to change?

How many results does the Science database hold, considering it has been running for over 20 years.
Conservative estimate 3 million/day * 365 days * 20 years = ...

The science data base only allows 30 items of interest to be recorded, this is not going to change.

... this project should seriously consider doubling the length of its workunits, while reducing the max allowed to 50+50. That would halve the number of the entries of the tables the server need to keep. You can name it sah v9. After a test period it could be decided to go back to sah v8, or double the length of the workunits again (reducing limits to 25+25), even keep both alive. The variety in the performance of the devices connected to this project is so large that it could be seen even from the Moon it makes reasonable for this project to let go its "one fits for all" attitude, because this is the root cause of the server crashes. The practical problems we face every day is only the consequence of that. Tinkering with the server components and micro-managing the acute problems covers it for a long while, but the time spent with it could be put into making the project more future proof instead. The outages won't go away until the root cause is present in the system. It hurts every cruncher (though it hurts the top performers the most) therefore it hurts the performance of the whole project.

The Return rate keeps falling, the Work in progress numbers keep falling, yet the Validation/Assimilation backlogs continue to grow.

I think they're just going to have to stop all work production, and let the servers sit for a week (or more) and let systems return the odd resend they get in order for the Validation backlog to clear, and then allow the resulting increased Assimilation backlog to clear (and hopefully the Deleters & Purgers won't develop a backlog).
Then reset the server side limits back to 100 + 100, pull all BLC35 files and not re-release them until both extra replication to handle the RX5000 series is reduced back to just 2 and they have their new storage server running, which will hopefully perform well enough even if all the data isn't cached.
Then re-release the BLC35s and see if the system grinds to halt again or not. And just maybe release their wish list for better hardware that can handle the loads Seti will be dealing with in the future (maybe get a second hand 2015 PowerEdge R730 server- supports 2 CPUs and 128GB of RAM per CPU?).

So E@H doesn't generate as much "heat"?

1.       GPUGrid / Acemd3 (cuda10)              GPU@1700MHz 331W
2.     SETI@home / GPU special app (cuda10.2)   GPU@1875MHz 325W
3. Einstein@home / O2MDF 2.07 GW-OpenCL-NVidia  GPU@1875MHz 295W
4. Einstein@home / FGRPB1G 1.20 OpenCL-NVidia   GPU@1875MHz 293W

Of topic but IMHO the next bottleneck of the project in the following years is the grow of the GPU capacity. Today top GPU could crunch a WU in less than 30 secs. So a host with 10 of this GPUs produces 100 WU on each 5 min, the ask for new job cicle. With the arrival of the ampres GPU`s that number will be rise even more. Feed them with this 5 min cicle will be an impossible task on such multi GPU`s coming monsters who probably will run with a lot of cores CPU (maybe more than 1) too.

Perhaps I missed it, but I don't see anyone mentioning what might be the best way to shrink things a bit.
I grab a task from Einstein, the deadline is around 10-14 days.
I grab a task here, the deadline is 1-2 months. That's too high.
They're very upfront at e@h about not wanting to raise their deadlines, specifically due to database server loading issues.
Perhaps lowering it here only makes sense.
SETI is arguably the most visible BOINC project.
As a result, I suspect this project gets the largest percentage of people new to the concept, and thus more likely to decide it isn't for them and go away, leaving work in the db to time out.
The long deadlines made sense in the earlier days of the project when task run times were high, and computers weaker. Perhaps it's time to revisit the decision.

Database Error
Database Error
Warning: Invalid argument supplied for foreach() in /disks/carolyn/b/home/boincadm/projects/sah/html/inc/result.inc on line 757 Database Error
Warning: Invalid argument supplied for foreach() in /disks/carolyn/b/home/boincadm/projects/sah/html/inc/result.inc on line 766

As per the ReadMe, the 10.2 version in the All-In-One requires Pascal and Higher. Maxwells run just about as well on CUDA 9.0. If you add Maxwell to the 10.2 App, the App will be around 220MBs instead of around 200MBs. The larger you make the App, the Slower it will run for everyone. For the Newer GPUs it's best to keep Maxwell out of the App. That's why it says Maxwell can use the CUDA 9.0 App, it won't work with the smaller App.

As far as the Release Notes, this is All you need to read, "Note that support for these compute capabilities may be removed in a future release of CUDA." That means Maxwell will still work with 10.2 , but MAY be removed on Newer ToolKits. nVidia has been complaining about Clang 6.0 since ToolKit 10.0, but, it still works with ToolKit 10.2 even though it has been listed as 'deprecated' for some time now.
That doesn't matter for this CUDA 10.2 App though, if you Read the First Post you will see, "The 10.2 App will need driver 440.33 or Higher, Ubuntu 15.04 or Higher, and Pascal or Higher GPU." Maxwell users can use the CUDA 9.0 App, it works just about as well on Maxwell.

SIGSEGV: segmentation violation

Libraries: libcurl/7.58.0 OpenSSL/1.1.1 zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) nghttp2/1.30.0 librtmp/2.3
CUDA: NVIDIA GPU 0: GeForce GTX TITAN X (driver version 440.44, CUDA version 10.2, compute capability 5.2, 4096MB, 4006MB available, 6611 GFLOPS peak)
OpenCL: NVIDIA GPU 0: GeForce GTX TITAN X (driver version 440.44, device version OpenCL 1.2 CUDA, 12210MB, 4006MB available, 6611 GFLOPS peak)
OS: Linux Ubuntu: Ubuntu 18.04.3 LTS [5.0.0-37-generic|libc 2.27 (Ubuntu GLIBC 2.27-3ubuntu1)]

Bad news: It's not received the instruction to run on device 0 / device 1