A little bemused that srbase do not seem to be reporting the level of factors that they had once been doing, or have I got it wrong, in some way ...

[QUOTE=bayanne;542409]A little bemused that srbase do not seem to be reporting the level of factors that they had once been doing, or have I got it wrong, in some way ...[/QUOTE]

He's now factoring to 78 bits. At first it only to 74.

Here is his daily chart.

[url]https://www.gpu72.com/reports/worker/1f51ffc3b3beb59724a343cbfa4f0cd1/[/url]

[QUOTE=petrw1;542427]He's now factoring to 78 bits. At first it only to 74.[/QUOTE]

Yes. He's /not/ cheating -- this is simply a function of his swarm doing the deeper work, and so fewer factors are found per wall-clock time.

When he starts doing 73 to 74 again (which he's free to continue getting from GPU72) his factors found will increase again.

Quick update...
 

So, a quick update...

1. Yesterday I moved into production version 0.422 of the GPU72_TF payload. This fixes the bug which caused the cron sub-system to sometimes not be installed, and thus the check-point files for the P-1'ing CPU runs not being thrown back to the server. Thanks to PhilF for pointing out my SPE.

2. The auto submission of results to Primenet from Colab TF'ing runs now correctly populates the Facts table when a factor is found.

2.1. I've written and run a script that back-filled all 454 cases where the Factor was not correctly recorded.

2.2. This means the reports and charts should once again be sane.

[QUOTE=chalsall;542461]2.2. This means the reports and charts should once again be sane.[/QUOTE]
:tu:

Does this look ok? I have seen something like this a few times recently.
[CODE]Exiting...
20200412_205357 INFO: Comms spider starting...
20200412_205357 INFO: Gracefull shutdown...
cat: worktodo.txt: No such file or directory
Use of uninitialized value $AID in concatenation (.) or string at ./comms.pl line 309.
Done.[/CODE]

[QUOTE=Uncwilly;542468]Does this look ok? I have seen something like this a few times recently.[/QUOTE]

OK, thanks for the report. It's harmless, although I'll add a conditional to handle it more gracefully.

Chris, any big trouble to add one or two more columns to [URL="http://www.gpu72.com/reports/workers/"]this table[/URL] ("77" and "78") and rename the last to ">77" or ">78"? If not big trouble, then please? :geek: (but if trouble, then forget it, there are not so many people crunching there anyhow, however, adding some column may "stimulate" them? :big grin:)

[QUOTE=LaurV;542491]Chris, any big trouble to add one or two more columns to [URL="http://www.gpu72.com/reports/workers/"]this table[/URL] ("77" and "78") and rename the last to ">77" or ">78"?[/QUOTE]

Yeah. That's on my todo list. There's actually quite a bit of back-end work involved with that report, but it needs to be done.

There's also the issue of the web page's width. I run 1920 by 1080 (times three), but not everyone does. I may drop the DC 68and 69 columns, since that work is from years ago, and there are only ~400K such runs. I'll have a "< 71" column instead, which will be an aggregate.

[QUOTE=LaurV;542491]If not big trouble, then please? :geek: (but if trouble, then forget it, there are not so many people crunching there anyhow, however, adding some column may "stimulate" them? :big grin:)[/QUOTE]

Yeah... The "real" GPU72 BOINC system will regularly go up to 78, so it will be worthwhile having that data exposed. :smile:

[QUOTE=chalsall;542543]I run 1920 by 1080 (times three), but not everyone does.[/QUOTE]I run 1280x1080 (x2) (two windows on 2560x1080) and the screen already cuts off halfway through the yellow "Saved" column.

On one machine I am running a 1080 x 1920 on the left and a 1920 x 1080 on the right. Before my current dual screen I was using just the 1920 x 1080 (I do most of my browsing on it still.):razz::cmd: