[QUOTE=xx005fs;535694]The tip to keep them running is when the cell containing the code to execute GPUOWL or MFACTx, the top right will show 2 status bars with RAM and Disk, click the little triangular tab next to it to expand that small menu, then click "Connect to a hosted runtime." After a successful connection, it should have 3 green dots and say "busy" after them, which means that you won't need a manual reconnection after a certain time has passed.[/QUOTE]Interesting. I've not found that to be necessary in most cases to get the full 10 or 12 hour session. Also it replaces the little ram and disk bar graphs with the word BUSY.

[QUOTE=kriesel;535834]Interesting. I've not found that to be necessary in most cases to get the full 10 or 12 hour session. Also it replaces the little ram and disk bar graphs with the word BUSY.[/QUOTE]

That's really strange, since every time I have to click that button to avoid a manual reconnection after around 15 minutes. It really is kind of a pain to do it for every single session everytime I run them.

This may be relevant here:
[QUOTE=Xyzzy;535833]As an experiment, we have disabled the robots.txt file.:mike:[/QUOTE]

[QUOTE=xx005fs;535854]That's really strange, since every time I have to click that button to avoid a manual reconnection after around 15 minutes. It really is kind of a pain to do it for every single session everytime I run them.[/QUOTE]FYI, I leave the Colab sessions going in active browser tabs, minimized browsers. The Colab sessions survive brief periods of browser absence, such as a system restart and restoration of browser session. But on lengthy system update sessions, that are slow to boot, the Colab sessions don't always survive.

[QUOTE=kriesel;535889]FYI, I leave the Colab sessions going in active browser tabs, minimized browsers. The Colab sessions survive brief periods of browser absence, such as a system restart and restoration of browser session. But on lengthy system update sessions, that are slow to boot, the Colab sessions don't always survive.[/QUOTE]

That's what I do too, iirc if you don't leave your browser open then the session will terminate within 10 minutes. There is once I had a big windows update that took over 10 minutes and all my sessions died.

[QUOTE=xx005fs;535897]That's what I do too, iirc if you don't leave your browser open then the session will terminate within 10 minutes. There is once I had a big windows update that took over 10 minutes and all my sessions died.[/QUOTE]I'm only running 2 Colab sessions; on separate accounts, separate Google drive trees, separate browsers, on separate hosts,.

[QUOTE=kriesel;535904]I'm only running 2 Colab sessions; on separate accounts, separate Google drive trees, separate browsers, on separate hosts,.[/QUOTE]

Oh i see. I am running multiple different accounts as well but not different hosts or browsers. That might be the reason. But I am happy that it works at all :)

Today after 30+ times retry with all T4 GPUs, finally got the "No GPU Available" message...:no:

A few people continue to get GPUs...
 

So, more data...

I continue to get a GPU backend about once a day, lasting anywhere from 30 minutes to three hours. Three other GPU72_TF'ers are also getting an instance every day or so, again lasting up to (but no more than) three hours.

Has anyone who used to run the GPU72_TF Notebook but haven't for a while tried recently? It appears there's a sliding quota going on.

[QUOTE=chalsall;536045]

Has anyone who used to run the GPU72_TF Notebook but haven't for a while tried recently? [/QUOTE]

It does not seem to really matter. See post #820.

[QUOTE=chalsall;536045]So, more data...

I continue to get a GPU backend about once a day, lasting anywhere from 30 minutes to three hours. Three other GPU72_TF'ers are also getting an instance every day or so, again lasting up to (but no more than) three hours.

Has anyone who used to run the GPU72_TF Notebook but haven't for a while tried recently? It appears there's a sliding quota going on.[/QUOTE]

Maybe there's a cron that runs about every 3 hours, looking for certain processes, or user names, ip addresses, etc, that is responsible for this behavior, and once targeted the length of time you get depends entirely upon how long it has been since the last cron interval.