[QUOTE=linament;542094]For the first time, I received this message on Colab when attempting to run without a GPU: "Sorry, no backends available. Please try again later."[/QUOTE]


Just happened to both of my accounts. Got backends again a short time later.

[QUOTE=linament;542094]For the first time, I received this message on Colab when attempting to run without a GPU: "Sorry, no backends available. Please try again later."[/QUOTE]

I had 2 CPU only sessions running which ended early. I think they are in the middle of making changes.

[QUOTE=linament;542094]For the first time, I received this message on Colab when attempting to run without a GPU: "Sorry, no backends available. Please try again later."[/QUOTE]

Same for me for the last few days.

[QUOTE=petrw1;542439]Same for me for the last few days.[/QUOTE]

Hmmm... I have /never/ not received a CPU. And the daily GPU allotment has been running for ten hours more often than seven the last couple of days.

[QUOTE=petrw1;542439]Same for me for the last few days.[/QUOTE]

Did you try the trick of changing the runtime type to TPU and attempting restart?

[QUOTE=chalsall;542443]Hmmm... I have /never/ not received a CPU. And the daily GPU allotment has been running for ten hours more often than seven the last couple of days.[/QUOTE]


I am sure Google tries its best so that users wouldn't see that. But I can see how instances could be unavailable for a short time in times of congestion. Other than that one brief time when it happened a few days ago, Google is pretty regular in letting 1 instance run always, and the others are time limited. (CPU only.)

As expected this morning my 4 instances were shut down. Just now, a couple of hours later, I got 1 CPU-only worker to start. A second one refused to start. Getting to see all the P-1 startup was enlightening. With 10,240MB allowed only 192 relative primes are being processed. Optimal bounds are B1=720,000, B2=1,332,0000. Meanwhile, Prime95, on a 32GB machine is setting 765,000 and 13,593,750, and running 480 RPs. High memory notebooks have about 25.5GB available. Wouldn't it improve results to let mfaktc use more of the available RAM?

[QUOTE=kladner;543258]High memory notebooks have about 25.5GB available. Wouldn't it improve results to let mfaktc use more of the available RAM?[/QUOTE]

Hmmm... (And I presume you mean mprime using the RAM.)

To the best of my knowledge, only you and Chuck are running the paid tier. So such high-memory instances wouldn't be that common.

There's also the issue of assignment reissuing. If a high-memory instance got an assignment and started working with really high bounds, what would happen if it then was reassigned to a standard memory sized instance? mprime will still work at the already worked B1/B2 bounds, but at what efficiency? Perhaps George can weigh in on this.

I guess I could have my server code-path make assignment decisions based on the memory available at request time (the telemetry sent back does include this information).

Let me meditate on this a bit, and see if I can come to sane convergence in my head (can be a somewhat painful exercise -- arguing with myself)...

OK. Thanks Chris. I had not thought of the possibility of High RAM not being available on subsequent launches. The whole thing is mostly curiosity based. Good thing I am not a cat.

[QUOTE=kladner;543258]As expected this morning my 4 instances were shut down. Just now, a couple of hours later, I got 1 CPU-only worker to start. A second one refused to start. [/QUOTE]

My quota has settled into four 19-hour GPU sessions each day. After six hours I can restart them. I have only ever received P100s on the paid tier.

[QUOTE=Chuck;543277]My quota has settled into four 19-hour GPU sessions each day. After six hours I can restart them. [B]I have only ever received P100s on the paid tier.[/B][/QUOTE]
Same here. I wonder if having multiple instances causes this, even if one is only using one at a particular time. I guess I could delete three of the four and mess around for a while to see if anything changes.