After the last few challenges, and looking at all the data from my various gpus as well as the recent optimization thread and other threads about modern GPU resource utilization, I did some thinking and testing on the workunit size of the Wieferich and Wall-Sun-Sun subprojects. My main conclusion is that the workunits are simply too small. I did some testing on my machines, and I have the following proposal:

What if we increased the unit size by 10x? instead of a 1e11/1e10 range, how about 10e11 for WFS and 10e10 for WSS? (10x credit, too, of course)

This is what I discovered from my tests of 1e10/1e11 vs 10e10/10e11, results of which of several ranges were rather consistent. (Methodology: ran a big 10x range at or near current leading edge as one big unit and the same range in 10 1x units, just one unit at a time on each GPU, tested on Maxwell and Fermi):

1. The "init time" was within a few 1/100ths of a second for short and long ranges.
2. P/sec actually increased by up to 13% (and GPU load was consistently higher as measured through GPU-Z).
3. Doing 10x range in one unit took ~9-9.3 times (Maxwell) and ~8.9-9.1 times (Fermi) as long as doing 10 individual 1x ranges, not including any interstitial times between workunits that the prpclient creates.
4. Memory usage didn't change.
5. On little Fermi (GT430, 96 CU), 100% GPU usage is easily reached, so the time gains were generally limited to doing only a single init vs. 10, but more importantly, it never took more than 10x the time to do 10x the work.

In real world timing, on my old and hopefully soon to be upgraded GTX580, a 10e11 WFS unit took ~510 seconds or 8m30s, which is still rather fast for something that is slower than a GTX1050. Certainly lesser GPUs will take much longer (My unoptimized 980ti is over 20x faster than my GT430 at WSS, but people will often run what they have, big or small, and that's OK), but comparing to some BOINC projects, it's not a bad time at all. Heck, make the task size 100x and it's about the same time requirement as an AP27 task (theoretically, I didn't test it), though I think 10x is a good place to start the discussion, especially considering midrange and lower GPU users. I know I'm probably ignoring the needs of CPU users, but like PPS Sieve, the GPU over CPU advantage is too great already.

I like completing 70k tasks in a weeklong challenge (more if I didn't also love gaming) who wouldn't? But if I could do 8-12% more in the same time frame and have one fewer digit of tasks instead, wouldn't that be more worthwhile project-wise?

Sample raw comparison outputs of single ranges vs. 10x range on my 980ti. 104 Mp/s! On PRPnet, I can't even crack 100 consistently with 2+ tasks running at the same time:

WFS

Yes, you're ignoring the CPU users.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

Yes, you're ignoring the CPU users.

I will have to give the suggested ranges a try tomorrow.
Last 2 days I have been successfully testing WFS/WSS on an AMD R9 280X, Catalyst 14.12, with the following results from PRPNet:
Wieferich, wwwwcl v2.1.9
6 threads, 1024 blocks, 5x WU, 89% GPU, 98% CPU: 320 WU's in 5:13:09. This is average one Work Unit in 58.7 seconds.
6 threads, 2048 blocks, 5x WU, 93% GPU, 99% CPU: 630 WU's in 9:46:01. This is average one Work Unit in 55.8 seconds.

WallSunSun, wwwwcl v2.2.5
blocks=4096, threads=2, 94-99% GPU, 0-33% CPU: 300 Work Units in 3:16:19. This is average one Work Unit in 39.2 seconds.
2 Directories:
blocks=4096, threads=1, 85 Work Units in 1:41:14. This is average one Work Unit in 71.5 seconds.
blocks=4096, threads=1, 85 Work Units in 1:42:30. This is average one Work Unit in 72.4 seconds.
So total one Work Unit every 36.0 seconds. Therefore 2 Directories is superior.

There is overhead of init time and talking to the servers every 1-20 WU's. Wasted GPU time can be avoided running multiple instances per GPU.
2 instances is better than 1 as shown above. I am not sure how far that scales up though.

What if we increased the unit size by 10x? instead of a 1e11/1e10 range, how about 10e11 for WFS and 10e10 for WSS? (10x credit, too, of course)

Ran a full CPU (w/HT) run of WFS tasks, and the average time was about 68 minutes, so a 1.66x time increase on a single task, much better than I guessed yesterday. I would expect it might be a little higher on CPUs where the ratio of threads to memory channels is larger. I'm finding that calculation time on CPU scales roughly linear with task size, as there is a minimal initialization of the task, so I will still use the "worst case scenario" 10x length for 10x size.

So, CPU-wise, a 10x task on every core would take just 680 minutes or 11.3 hours, which is a really good time, all things considered. The credit sucks (just 2000 points per core per day, perhaps one of the lowest rates of all PG outside of the x87 GFN tasks), but by the same token it's also low for GPUs, too.

Edit: Just saw your post, Michael, and I definitely agree with you that the lack of double check (or even the abilty to verify) is a problem. I think there are many of us who would love to see an updated and fully usable wwww app, but I would understand if you just shut it off one day.
____________
Eating more cheese on Thursdays.

Running Grebuloner's suggested single range vs. 10x range on my AMD 280X gave me 9.68x with WFS and 9.36x with WSS.

Stopwatch time of WFS v2.1.9 below is the sum of "init" and "sieve" in brackets after "Elapsed time".
Stopwatch time of WSS v2.2.5 below is simply "Clock time".

WFS

I figured out why the checksum is zero, for WSS at least.
It's not saving the A value in the Kernel when it's not a Special Result.
In wallsunsun_kernel.h after:

OK, I got the WWWW.cpp LogStats() working too. The Checksum is reported by the threads to the main App in a call to WriteCheckPoint(), and that is not currently called unless the Sieve is interrupted. To fix just add a call to WriteCheckpoint() before printing out the "Sieve complete" message in App.cpp Finish(). That and the additional line in wallsunsun_kernel.h is all you need to get Checksum to report in WSS.

Similarly quot[gid] is not being set in wieferich_kernel.h unless it is a Special Result.