GPU to 72 status... - Page 446

chalsall · 2020-05-16, 15:40

Quote:

Originally Posted by Runtime Error

It seems that a notebook instance likes to first start a new exponent upon launch, and if it finishes, it will move on to any partially completed jobs. But unless it gets a T4, it will not finish the job within 12 hours. I currently have a handful of partially completed 81-bit jobs, and this evening's notebooks just started fresh exponents. Do you have any advice?

A new instance will first be re-issued work partially completed, in descending order. However, an assignment is only re-issued after no updates for 30 minutes.

This can lead to a bit of a "queue" if someone does the "Factory Reset" trick a few times -- anything which hasn't had work done on it is thrown back into the pool, but if the instance isn't reset within two minutes it will report back some progress, and then the candidate is held until completion.

My advice is to just stick with it -- all work will (eventually) be completed.

P.S. Oh, also... I set up a P-1 assignment for myself in 332M as a test. 17 days on the lone CPU core... I don't think it will make sense to make this worktype available to the Colab instances.

Runtime Error · 2020-05-16, 16:37

Quote:

Originally Posted by chalsall

A new instance will first be re-issued work partially completed, in descending order. However, an assignment is only re-issued after no updates for 30 minutes.

This can lead to a bit of a "queue" if someone does the "Factory Reset" trick a few times -- anything which hasn't had work done on it is thrown back into the pool, but if the instance isn't reset within two minutes it will report back some progress, and then the candidate is held until completion.

My advice is to just stick with it -- all work will (eventually) be completed.

P.S. Oh, also... I set up a P-1 assignment for myself in 332M as a test. 17 days on the lone CPU core... I don't think it will make sense to make this worktype available to the Colab instances.

Got it. I've been cycling until I get P100s, that makes sense. Thanks!

And wow 17 days = 34+ days with the time limitations. Ouch!

chalsall · 2020-05-17, 17:19

Quote:

Originally Posted by Runtime Error

Got it. I've been cycling until I get P100s, that makes sense. Thanks!

So, I've been thinking about how to handle these long-running tasks (and the restarting of same) in a better way.

One thing which could be done immediately would be to drop the number of assigned tasks per instance down to two, instead of three. The chances of a factor being found immediately after the start of the next job are very, very small, so mfaktc would (almost) never run out of work.

However, something to put out there... It would also be possible to only assign a single job at a time. The downside to this is there would be about 30 seconds of wasted compute between a job being finished, the next job being fetched, and mfaktc starting up again (along with the short self-test).

Thoughts? Perhaps make this optional, on a per-instance basis?

axn · 2020-05-17, 17:45

Quote:

Originally Posted by chalsall

The downside to this is there would be about 30 seconds of wasted compute between a job being finished, the next job being fetched, and mfaktc starting up again (along with the short self-test).

The horror, the horror!

James Heinrich · 2020-05-17, 17:58

I think the benefit of having fewer half-done assignments hanging around is well worth losing a minute a day or thereabouts.

Runtime Error · 2020-05-17, 18:51

Quote:

Originally Posted by chalsall

So, I've been thinking about how to handle these long-running tasks (and the restarting of same) in a better way.

One thing which could be done immediately would be to drop the number of assigned tasks per instance down to two, instead of three. The chances of a factor being found immediately after the start of the next job are very, very small, so mfaktc would (almost) never run out of work.

However, something to put out there... It would also be possible to only assign a single job at a time. The downside to this is there would be about 30 seconds of wasted compute between a job being finished, the next job being fetched, and mfaktc starting up again (along with the short self-test).

Thoughts? Perhaps make this optional, on a per-instance basis?

Sweet! I currently have 9 in-progress assignments at the 81-bit level. One of them has been stuck at 95% for a few days, presumably due to me cycling. The one-assignment per notebook rule for 81-bits would be welcomed!

Also, I just got kicked out of Colab after 1hr30min

Uncwilly · 2020-05-18, 03:47

GPUto72 is not seeing (in the stats) the factor found up in the 332M range on one of my colab sessions.

kladner · 2020-05-18, 04:10

Quote:

Originally Posted by Runtime Error

Sweet! I currently have 9 in-progress assignments at the 81-bit level. One of them has been stuck at 95% for a few days, presumably due to me cycling. The one-assignment per notebook rule for 81-bits would be welcomed!

Also, I just got kicked out of Colab after 1hr30min

That hasn't happened to me, yet. However, I am feeling that "THEY" are onto my dodges around usage limits. The GPU Nazi is giving me a lot of "No GPU for You!" I only seem to be able to run GPUs on my paid account, and that has shot its wad, at the moment.

EDIT: But when I turned off GPU in the settings of all the notebooks, and then tried running, I got 4 CPU/P-1 instances running with RAM showing 'BUSY' on all of them. I think I was getting more push-back when I left GPUs enabled, when I knew it wasn't going to let me have them. There were more 'excess sessions' warnings and it seemed the system would only allow one. This preemptive disabling of GPUs might help with free accounts, too. I can usually run two notebooks on free accounts. Trying to run multiple accounts simultaneously has not worked out for me at least, so 2 (free) or 4 (paid) notebooks are the limits in my experience. I would be happy to hear if others have gotten more going. (I know that chalsall and others are running multiple instances through VPNs and other more abstruse means, but I am not running in that class so far. Ignorance and laziness stand in the way.)

chalsall · 2020-05-18, 20:37

Quote:

Originally Posted by Runtime Error

The one-assignment per notebook rule for 81-bits would be welcomed!

OK, version 0.423 is now in production. Does the one assignment at a time thing.

A bit of wasted compute (as a %) for the shorter running jobs, but I'm too busy at the moment on other things to make this smarter. I have mapped out a solution of giving the next assignment a few minutes before the first expires, but it will take a little while to implement.

chalsall · 2020-05-18, 20:50

Quote:

Originally Posted by Uncwilly

GPUto72 is not seeing (in the stats) the factor found up in the 332M range on one of my colab sessions.

Copy. Will drill down in the next 48 hours.

Uncwilly · 2020-05-18, 23:19

Quote:

Originally Posted by chalsall

Copy. Will drill down in the next 48 hours.

Specifically I should have said the graph.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Status	Primeinator	Operation Billion Digits	5	2011-12-06 02:35
62 bit status	1997rj7	Lone Mersenne Hunters	27	2008-09-29 13:52
OBD Status	Uncwilly	Operation Billion Digits	22	2005-10-25 14:05
1-2M LLR status	paulunderwood	3*2^n-1 Search	2	2005-03-13 17:03
Status of 26.0M - 26.5M	1997rj7	Lone Mersenne Hunters	25	2004-06-18 16:46

2020-05-17, 17:58	#4900
James Heinrich "James Heinrich" May 2004 ex-Northern Ontario D5D₁₆ Posts	I think the benefit of having fewer half-done assignments hanging around is well worth losing a minute a day or thereabouts.

2020-05-18, 03:47	#4902
Uncwilly 6809 > 6502 """"""""""""""""""" Aug 2003 101×103 Posts 2·4,909 Posts	GPUto72 is not seeing (in the stats) the factor found up in the 332M range on one of my colab sessions.