[QUOTE=chalsall;588610]Been there for as long as GPU72 has existed. (Not meaning to be mean or anything, but I believe it was actually you who asked it be rendered as UTC rather than AST many years ago...)[/QUOTE]

Not the first time; won't be the last time I've had a senior moment.

[QUOTE=chalsall;588607]I don't really understand the feature request/bug report.
<snip>
With regards to the report being out of sync with Primenet, that will (almost) *always* be the case. GPU72 only "spiders" Primenet twice an hour to get updates wrt factors found and P-1'ing/TF'ing completed.[/QUOTE]

When the report says "Updated: xxxx UTC", I expect all the results reported to primenet by xxxx UTC to be there. If that is not the case can you please give a "Data as of" time as well which represents the last time primenet was spidered?

I don't really care what time report was generated. I only care how recent the data actually is.

[QUOTE=axn;588643]I don't really care what time report was generated. I only care how recent the data actually is.[/QUOTE]

I hear your reasoning for the change request. Having thought about it, I'm going to remain with the current code paths.

There are many clients (read: workers) who interact with GPU72 by way of direct IPC. The Colab TF'ers and P-1'ers for example.

The timestamp on the report at [URL="https://www.gpu72.com/twok/"]https://www.gpu72.com/twok/[/URL] should perhaps be interpreted as the knowledge GPU72 had at that moment in time. One hour resolution is the same as provided by Primenet for many of its reports.

I hope and trust this is acceptable, taking into consideration the computational and bandwidth constraints of the IPC between these two systems.

Hey Chris, we have arguments again :razz:

[CODE]20220930_093729 ( 0:02): Installing needed packages...
20220930_093749 ( 0:02): Fetching work...
20220930_093753 ( 0:02): Running GPU type Tesla T4

20220930_093753 ( 0:02): running a simple selftest...
20220930_093804 ( 0:02): Selftest statistics
20220930_093804 ( 0:02): number of tests 107
20220930_093804 ( 0:02): successfull tests 107
20220930_093804 ( 0:02): selftest PASSED!
20220930_093804 ( 0:02): Starting trial factoring M121004437 from 2^76 to 2^77 (126.48 GHz-days)

20220930_093804 ( 0:02): Exponent TF Level % Done ETA GHzD/D Itr Time | Class #, Seq # | #FCs | SieveRate | SieveP
20220930_093804 ( 0:02): 121004437 76 to 77 0.1% 1h45m 1729.39 6.582s | 0/4620, 1/960 | 67.58G | 10267.1M/s | 82485
20220930_093810 ( 0:02): 116038357 using up to 10496MB of memory.
20220930_093810 ( 0:02): Assuming no factors below 2^77 and 2 primality tests saved if a factor is found.
20220930_093810 ( 0:02): Optimal bounds are B1=972000, B2=77451000
20220930_093810 ( 0:02): Chance of finding a factor is an estimated 4.64%
20220930_093810 ( 0:02): 116038357 P-1 77 39.62% Stage: 1 complete.
20220930_093810 ( 0:02): 116038357 using up to 10496MB of memory.
20220930_093810 ( 0:02): Assuming no factors below 2^77 and 2 primality tests saved if a factor is found.
20220930_093810 ( 0:02): Optimal bounds are B1=972000, B2=77451000
20220930_093810 ( 0:02): Chance of finding a factor is an estimated 4.64%
20220930_093810 ( 0:02): 116038357 P-1 77 39.62% Stage: 1 complete.
20220930_093905 ( 0:03): 121004437 76 to 77 1.0% 1h48m 1658.82 6.862s | 44/4620, 10/960 | 67.58G | 9848.2M/s | 82485
20220930_093939 ( 0:04): M121004437 has a factor: 80397885568786528793209[/CODE]This may be the record for the fastest, non-trivial factor ever found, haha :lol: (time is UTC, not Thai).

And the most unluckiest factor, to be found exactly after the GPU72 script started, as it can be seen from the screen output - the interposed CPU-related stuff in the middle is bothering but I let it there for authenticity.

So, this factor was "unlucky" to be in a very incipient class and was found out in a minute after starting mfaktc, there was no other work to do, mfaktc closed, and resources were wasted. On the lucky side, I was still there, I didn't just evaporate after launching the notebook :razz: and the resources were wasted only for a minute. But what if I would not?

I know we "argued" and then you implemented the trick to give more assignments in the same time, and not only one, why the process wasn't working this time? Did you revert it back accidentally when you fixed the A100, or was it just implemented at that time for me/for very short assignments?

[QUOTE=LaurV;614593]Hey Chris, we have arguments again :razz:[/QUOTE]

You are non-nominal... :razz:

If you had waited about twenty seconds, the Notebook code would have fetched the next assignment from GPU72.com, and Oliver's code would have launched. TF'ing the next assignment.

It is trivial for me to change the number of assignments from 1 to 2 (or X). As you well know. At the same time, you have demonstrated the ability to do this yourself. Trivial in the Pro environment, since you have Terminal access. Most don't have Pro, so this doesn't impact most people.

P.S. Just in case it isn't clear to the casual reader, LaurV and I get along great. Respectfully razzing each other is just a way of keeping each other on our toes! 8^)

:tu:
So, you have some hidden process in bkgnd that fetches assignments. Good to know. Didn't look, and I was impatient, I was thinking ":davar55: I got him!" :razz:
:blush:

Edit: however, a parameter line to select the number of assignments wouldn't hurt. Also, since I can't get GPUs anymore (Gugu is upset with me, I think....:rant:), I started playing with CPU-only, High-Mem sessions. There you get about 51G, and about 45 could be used for P-1. Is there any way for you to detect that? If not, maybe a parameter line where we could specify the amount for stage 2 memory wouldn't hurt either... You always assume we have the 12G sessions, and you use about 10. In case we take the High-Mem sessions, about 35G are wasted.

So, when you get the time, and not digging out cement boulders in that garden of yours... :razz:

I have 2 instances running on Colab. I THOUGHT assignments were supposed to run until they were finished but every once in a while after a reset even if I have 2 unfinished P-1 assignments a new one will start. To my thinking that just pushes back when the original ones will end up getting done. Is there anything that can be done to fix/correct/change that? I thought at one time is was setup that way but then it changed but I may be wrong on that. I haven't seen this happen with TF's. It's only with P-1's.

[QUOTE=mrk74;616733]I have 2 instances running on Colab.[/QUOTE]

Yes. Some have more; some have less. Some are using the GPU72 Notebook.

[QUOTE=mrk74;616733]I THOUGHT assignments were supposed to run until they were finished but every once in a while after a reset even if I have 2 unfinished P-1 assignments a new one will start.[/QUOTE]

Nominal and sane behaviour. Exactly as engineered into the code paths. Race conditions can be amusing...

[QUOTE=mrk74;616733]To my thinking that just pushes back when the original ones will end up getting done. Is there anything that can be done to fix/correct/change that?[/QUOTE]

Sure. Wait about twenty minutes before restarting. Or just trust that the system is sane, and all work will be completed by (and credited to) you.

Just to share... It is absolutely wonderful being able to experiment in this kind of domain.

The "edge cases" are something everyone /should/ consider, but they can sometimes be subtle... 8^)