Colab question
 

Hi, so I just started using the Colab feature in the gpu72 website, and I was wondering if I could create more than 1 notebook acces key in order to have a key for every work type. I don't know if I should post this directly in the Notebook integration subthread, in case I made a mistake, I apologize.

[QUOTE=David703;528792]Hi, so I just started using the Colab feature in the gpu72 website, and I was wondering if I could create more than 1 notebook acces key in order to have a key for every work type. I don't know if I should post this directly in the Notebook integration subthread, in case I made a mistake, I apologize.[/QUOTE]

Hey. Welcome.

I have to say it was kinda cool watching you come in "green", and within a few minutes had spun up an instance and were working away! It's the way it should be! :smile:

To answer your question, you may create as many "AKeys" as you'd like. I have different keys named so I can keep track of what account they're running under, and where. For example, "Colab_CVH", "Kaggle_iROOT", etc.

For each key you can have a different "Work Type" selected. You will shortly be able to edit these, to be able to change the worktype (and even the name, if so desired).

Please let us know if you have any further questions.

Got it, thank you a lot!

[QUOTE=chalsall;528809]Please let us know if you have any further questions.[/QUOTE]

I would maybe like to know if there is a limit to the work I can do daily for each notebook in terms of hours, and if it would be a problem if I wanted to run 2 or more Colab notebooks at the same time from the same IP address.

[QUOTE=David703;528829]I would maybe like to know if there is a limit to the work I can do daily for each notebook in terms of hours, and if it would be a problem if I wanted to run 2 or more Colab notebooks at the same time from the same IP address.[/QUOTE]Colab should limit you to 12 hours at some point. Until they do, go for as much as they will give you (you will still need to restart it after 12 hours).
The IP is not the issue, it is the account/ID. I have had 2 accounts each running on a different phone, both attached to my home wifi.

Ok, thank you!

[QUOTE=Uncwilly;528836]The IP is not the issue, it is the account/ID[/QUOTE]
Are you referring to the google account used to access colab or to the notebook acces key? Sorry for my ignorance.

[QUOTE=David703;528839]Ok, thank you!


Are you referring to the google account used to access colab or to the notebook acces key? Sorry for my ignorance.[/QUOTE]
Google account. You can use any notebook access key on any account.
To know you are ignorant and acknowledge it is better than to believe that you are not ignorant.

[QUOTE=Uncwilly;528843]You can use any notebook access key on any account.[/QUOTE]

Thanks -- important to point that out.

To get a little "geeky" (sorry; I'm in that mode at the moment)...

1. The AKey is simply a way of tieing a running instance to a GPU72 Account.

1.1. The AKey is a "unique identifier" which says "do work as this person".

1.2. But, importantly, it doesn't give away any "access credentials" of said person (or more accurately, their Account).

1.2.1. Just to get pedantic... There is the risk that if an AKey "leaked" someone could reserve and do work on your behalf.

2. There is a "one-to-many" relationship between the GPU72 Account and the AKeys. An account can have 0 to "many" AKeys.

2.1. Each AKey, on the other hand, is only "related" back to one Account.

3. There is a "many-to-many" relationship between the AKeys and running Colab / Kaggle "Instances".

3.1. An instance may use any AKey.

3.2. It is perfectly OK to use the same AKey in more than one running instance at a time.

3.2.1. For resource management purposes, however, it is better to have each "class" of instance run under it's own name. This is so when you see an instance stop reporting on assignments, you know immediately which (and where) it is.

[QUOTE=Uncwilly;528843]To know you are ignorant and acknowledge it is better than to believe that you are not ignorant.[/QUOTE]

Indeed. Well worded sir. :smile:

Ok, thank you a lot for the kindness and the informations!

So if I have two different Google accounts, how best then to run 2 notebooks on the same browser?

[QUOTE=bayanne;528993]So if I have two different Google accounts, how best then to run 2 notebooks on the same browser?[/QUOTE]

Just launch a new browser tab/window. Go to Colab. You're "default" account will be linked.

Click on the account symbol at the far top right (will be your profile picture if you have one, otherwise a colored circle with a letter). A "pop-up" will appear, which lists all of your accounts. Click on the one you want to use.

Then proceed as usual.

[QUOTE=chalsall;529005]Just launch a new browser tab/window. Go to Colab. You're "default" account will be linked.

Click on the account symbol at the far top right (will be your profile picture if you have one, otherwise a colored circle with a letter). A "pop-up" will appear, which lists all of your accounts. Click on the one you want to use.

Then proceed as usual.[/QUOTE]

Thanks for that :)

Hi, sorry to bother you guys, but I've been experiencing this error on all my Google accounts recently:

"Failed to execute cell. Could not send execute message to runtime: SecurityError: Permission denied to access property "traceDefinedHardwareId" on cross-origin object"
Is it a known problem with a known solution?


Here are the error details:
Permission denied to access property "traceDefinedHardwareId" on cross-origin object self.tr_NMvxyzOxhGbceXrQ/<@https://colab.research.google.com/github/chalsall/GPU72_CoLab/blob/master/gpu72_tf.ipynb:3:9 [EMAIL="self.tr_NMvxyzOxhGbceXrQ@https://colab.research.google.com/github/chalsall/GPU72_CoLab/blob/master/gpu72_tf.ipynb"]self.tr_NMvxyzOxhGbceXrQ@https://colab.research.google.com/github/chalsall/GPU72_CoLab/blob/master/gpu72_tf.ipynb[/EMAIL]:41:6 [EMAIL="get@https://colab.research.google.com/github/chalsall/GPU72_CoLab/blob/master/gpu72_tf.ipynb"]get@https://colab.research.google.com/github/chalsall/GPU72_CoLab/blob/master/gpu72_tf.ipynb[/EMAIL]:59:23 [EMAIL="get@https://colab.research.google.com/github/chalsall/GPU72_CoLab/blob/master/gpu72_tf.ipynb"]get@https://colab.research.google.com/github/chalsall/GPU72_CoLab/blob/master/gpu72_tf.ipynb[/EMAIL]:94:25 [EMAIL="get@https://colab.research.google.com/github/chalsall/GPU72_CoLab/blob/master/gpu72_tf.ipynb"]get@https://colab.research.google.com/github/chalsall/GPU72_CoLab/blob/master/gpu72_tf.ipynb[/EMAIL]:50:25 [EMAIL="get@https://colab.research.google.com/github/chalsall/GPU72_CoLab/blob/master/gpu72_tf.ipynb"]get@https://colab.research.google.com/github/chalsall/GPU72_CoLab/blob/master/gpu72_tf.ipynb[/EMAIL]:36:25 [EMAIL="get@https://colab.research.google.com/github/chalsall/GPU72_CoLab/blob/master/gpu72_tf.ipynb"]get@https://colab.research.google.com/github/chalsall/GPU72_CoLab/blob/master/gpu72_tf.ipynb[/EMAIL]:37:25 [EMAIL="I_@https://colab.research.google.com/v2/external/external_polymer_binary.js"]I_@https://colab.research.google.com/v2/external/external_polymer_binary.js[/EMAIL]?vrz=colab-20191025-092551-RC00_276702382:2519:66 Ida/<@https://colab.research.google.com/v2/external/external_polymer_binary.js?vrz=colab-20191025-092551-RC00_276702382:2562:424 [EMAIL="za@https://colab.research.google.com/v2/external/external_polymer_binary.js"]za@https://colab.research.google.com/v2/external/external_polymer_binary.js[/EMAIL]?vrz=colab-20191025-092551-RC00_276702382:12:336 [EMAIL="xa.prototype.next_@https://colab.research.google.com/v2/external/external_polymer_binary.js"]xa.prototype.next_@https://colab.research.google.com/v2/external/external_polymer_binary.js[/EMAIL]?vrz=colab-20191025-092551-RC00_276702382:10:453 Ba/this.next@https://colab.research.google.com/v2/external/external_polymer_binary.js?vrz=colab-20191025-092551-RC00_276702382:13:206 [EMAIL="b@https://colab.research.google.com/v2/external/external_polymer_binary.js"]b@https://colab.research.google.com/v2/external/external_polymer_binary.js[/EMAIL]?vrz=colab-20191025-092551-RC00_276702382:22:43

[QUOTE=David703;529117]Hi, sorry to bother you guys, but I've been experiencing this error on all my Google accounts recently:[/QUOTE]

Hmmm... Google is being a bit "grumpy" this morning -- refusing to give my shivering virtual selves (read: SOCKS tunneled "human instances") environments. My two Barbados manifesting accounts are getting instances, but they are being killed after an hour.

But... No errors such as you're reporting.

A couple of thoughts... I do remember Google presents a warning message when running the GPU72_TF Section for the first time. Something along the lines of "Google didn't author this -- be sure you review and trust it before running". Perhaps you didn't acknowledge that?

Alternatively, rather than cloning from Github, you can also just copy-and-paste the code from the GPU72 "View Note Access Key" -> "Notebook Access Key" page into a new Colab and/or Kaggle Notebook.

Remember that both Colab and Kaggle are very particular about the copy-and-paste. You can't just highlight the code, and then middle-button-click. You have to highlight, then "Cntl-C", then "Cntl-V" into the Notebook Section.

Please let us know if either of the above resolves your issue.

It always displays the message "Google didn't authorize etc etc" and I always press "Run anyways" so I don't think that is the problem. Just tried to copy and paste the code from the Notebooks Acces Keys section but Colab is still displaying the same error.

[QUOTE=David703;529122]Just tried to copy and paste the code from the Notebooks Acces Keys section but Colab is still displaying the same error.[/QUOTE]

Hmmm... Have you tried turning it off and on again?

That's meant to be funny, and serious, at the same time...

Perhaps try fulling exiting from your browser, and restarting. I can't think of a reason a full reboot would be needed, but if a browser reset doesn't help, perhaps try going to Settings, and flush your cache.

Tried to exit Firefox and then run Colab but it still displays the same error. Not weirdly, it seems to work fine using Chrome, it must have to do with the dozen addons I installed yesterday. I'm going to try to disable them one at a time and see which one is causing problems. Will let you know if I can figure this out.


EDIT: Just found the problem: the addon "Trace" was somehow preventing the cell from running, now that I jave disabled it Colab works fine, thank you guys for your help!

[QUOTE=David703;529125]EDIT: Just found the problem: the addon "Trace" was somehow preventing the cell from running, now that I jave disabled it Colab works fine, thank you guys for your help![/QUOTE]

Excellent. Good you found the cause of the "regression".

It's our pleasure to help with stuff like this. It's an important way to find the "edge-cases" of our code.

Sounds great! I would like to ask just another thing. Out of sheer curiosity: how come trial factoring a number in the 97M exponent range from 2^74 to 2^75 "costs" around 40GHz-days while an exponent in the 63M range still from 2^74 to 2^75 costs 60? Why, in general, is the TF algorithm that we run slower with lower exponents?

[QUOTE=David703;529188]Sounds great! I would like to ask just another thing. Out of sheer curiosity: how come trial factoring a number in the 97M exponent range from 2^74 to 2^75 "costs" around 40GHz-days while an exponent in the 63M range still from 2^74 to 2^75 costs 60? Why, in general, is the TF algorithm that we run slower with lower exponents?[/QUOTE]The number of candidates that need to be tested at each bit level goes down as the exponent goes up. Any divisor of a Mersenne number must be in the form 2kp+1 , where the p is the exponent in question. As it gets larger, there are fewer numbers in each bit size that will fit that requirement.

[QUOTE=Uncwilly;529193]Any divisor of a Mersenne number must be in the form 2kp+1 , where the p is the exponent in question[/QUOTE]


Oh, got it, thank you!

Just got assigned 2 Tesla P100s on 2 different accounts! :smile::smile::smile:

[QUOTE=dcheuk;530045]Just got assigned 2 Tesla P100s on 2 different accounts! :smile::smile::smile:[/QUOTE]

Make it 3 including my university's google account. :picard::picard::picard:

3 Kaggle accounts? Did you add 3 different phone numbers?

Careful about that, I created a 2nd account without adding any phone number just for the 10 cpu instances, and now they blocked both accounts.
I wrote to them and asked if they could open the main account again and just delete the 2nd account, but no response yet.

[QUOTE=ATH;530068]3 Kaggle accounts? Did you add 3 different phone numbers?

Careful about that, I created a 2nd account without adding any phone number just for the 10 cpu instances, and now they blocked both accounts.
I wrote to them and asked if they could open the main account again and just delete the 2nd account, but no response yet.[/QUOTE]

Oh it was 3 Google accounts under Colab. Two personal google accounts and one by the university. Maybe I should tune it down a notch. :smile:

How did you get P100 on Google Colab?

I'm only getting K80 every time, I don't even think I ever got a T4.

I always got P100 on Kaggle for the 30 GPU hours.

[QUOTE=ATH;530178]How did you get P100 on Google Colab?

I'm only getting K80 every time, I don't even think I ever got a T4.

I always got P100 on Kaggle for the 30 GPU hours.[/QUOTE]

At first I kept getting K80, now half the time I got assigned P100, surprised but not unwelcomed.

I've been getting P100s and T4s in my playing around with my GPU experiments a lot more frequently. I don't stay on too long at a time, though.

Maybe Google's like, 'well we are not using these machines and these guys are not mining btc so why not like them have it?' :smile:

That's probably not why though. It does feel like a `waste' using these P100 for TF on colab, instead I can be running at least DCs.

Yeaah.. joining the club, like somebody said, not unwelcome.

[ATTACH]21287[/ATTACH]

[QUOTE=dcheuk;530197]...That's probably not why though. It does feel like a `waste' using these P100 for TF on colab, instead I can be running at least DCs.[/QUOTE]

If it will give you the time! It might actually take much longer to run a DC this way instead of on a local GPU with [I]CUDALucas[/I]. Sometimes, I think maybe [I]Colab[/I] sees all we do as crypto-mining because of the high utilization.

[QUOTE=storm5510;530212]Sometimes, I think maybe [I]Colab[/I] sees all we do as crypto-mining because of the high utilization.[/QUOTE]

Doubt it.

Most CM involves connecting with a "hive", keeping in constant contact.

Little sense wasting any additional time (beyond the 99.999999999999...% already expected to be wasted) searching for the magic random plaintext which results in the coveted special-case hash, if it's already been found.

100% utilization of compute is quite common nowadays.

Thankfully, at least /some/ of it is productive and co-operative towards actual value...

[QUOTE=chalsall;530241]Doubt it.

Most CM involves connecting with a "hive", keeping in constant contact.

Little sense wasting any additional time (beyond the 99.999999999999...% already expected to be wasted) searching for the magic random plaintext which results in the coveted special-case hash, if it's already been found.

100% utilization of compute is quite common nowadays.

Thankfully, at least /some/ of it is productive and co-operative towards actual value...[/QUOTE]

I wonder how large the "hive" actually is? It doesn't seem practical to have thousands of single-instance processors, or more. Fewer processors with the ability to have a great many threads would seem more likely. After all, they would want to keep their electrical utility costs as low as possible.

[QUOTE=storm5510;530283]I wonder how large the "hive" actually is? It doesn't seem practical to have thousands of single-instance processors, or more.[/QUOTE]

No. Instead there are thousands of geographically diverse "peers", each with thousands of threads of compute wasting their time searching an effectively random problem space, consuming massive amounts of energy for very little actual reduction of enthalpy.

IMO, a beautiful thought experiment. But, empirically, some implementations don't scale terribly well...

[QUOTE=storm5510;530212]It might actually take much longer to run a DC this way instead of on a local GPU with [I]CUDALucas[/I].[/QUOTE]It's not instead of, it's in addition to.

[QUOTE=kriesel;530345]It's not instead of, it's in addition to.[/QUOTE]

This implies a person could jump from one to another with one, or more, checkpoint files. Is this correct?

[QUOTE=storm5510;530351]This implies a person could jump from one to another with one, or more, checkpoint files. Is this correct?[/QUOTE]
Yes. Checkpoints are compatible, assuming you run a mfaktc newer than 1.18 or so, when they were changed, and assuming you do not interchange "special" versions (like less classes). You can freely move assignments and checkpoint files between computers, colab included. However keep in mind that moving the checkpoint alone means nothing, unless you have the assignment in worktodo too. This is how mfaktX works, it gets the work from the worktodo file and [U]then[/U] it checks for checkpoint. The checkpoint only stores the last class that was done for an exponent, and it will not do again the classes already done. Each class is sieved and powmoded separate. I used this method to split huge assignments (like M666666667 to 86 bits or so) between more computers/cards, by creating "fake" checkpoints so each computer/card does different classes.

[QUOTE=storm5510;530351]This implies a person could jump from one to another with one, or more, checkpoint files. Is this correct?[/QUOTE]Not necessary. Start and finish each exponent separately works. Colab finishes what it starts, owned gpu finishes what it starts. Completely parallel. If you decide to move an mprime or gpuowl run off Colab, yes, the same app run on your own pc can finish what was started on Colab and stored on Google drive, and vice versa (as long as the application versions are compatible). [url]https://www.mersenneforum.org/showpost.php?p=508637&postcount=12[/url]

Hmm got the following error while running colab on TF.

[CODE]Failed to execute cell. Could not send execute message to runtime: TypeError: Cannot read property 'getKernelInfo' of null
Cannot read property 'getKernelInfo' of null
TypeError: Cannot read property 'getKernelInfo' of null
at d (https://colab.research.google.com/v2/external/external_polymer_binary.js?vrz=colab-20191111-080000-RC00_279737042:3474:140)
at w8 (https://colab.research.google.com/v2/external/external_polymer_binary.js?vrz=colab-20191111-080000-RC00_279737042:3474:275)
at za.program_ (https://colab.research.google.com/v2/external/external_polymer_binary.js?vrz=colab-20191111-080000-RC00_279737042:3467:302)
at Ba (https://colab.research.google.com/v2/external/external_polymer_binary.js?vrz=colab-20191111-080000-RC00_279737042:12:336)
at za.next_ (https://colab.research.google.com/v2/external/external_polymer_binary.js?vrz=colab-20191111-080000-RC00_279737042:10:453)
at Da.next (https://colab.research.google.com/v2/external/external_polymer_binary.js?vrz=colab-20191111-080000-RC00_279737042:13:206)
at b (https://colab.research.google.com/v2/external/external_polymer_binary.js?vrz=colab-20191111-080000-RC00_279737042:22:43)
[/CODE]

[QUOTE=dcheuk;530482]Hmm got the following error while running colab on TF.[/QUOTE]

Hmmm... That is a *deep* error. Never seen it before myself.

Taking a stab in the dark, this looks like the "supervisor" hosting the VM is undergoing maintaince, or having a hardware issue.

Edit: Actually, maybe not really that deep an error. Did you try reconnecting?

[QUOTE=storm5510;530212]Sometimes, I think maybe [I]Colab[/I] sees all we do as crypto-mining because of the high utilization.[/QUOTE]

While I lived in the university apartments, they (the university IT department) thought I was `mining crypto currency' due to comparatively larger electricity consumption and `suspicious network activites,' and tried to discipline me for such misbehavior.

I had to send them a bunch of friendly emails explaining that I was using it to parallel computing data for a research project. :smile:

[QUOTE=chalsall;530484]Hmmm... That is a *deep* error. Never seen it before myself.

Taking a stab in the dark, this looks like the "supervisor" hosting the VM is undergoing maintaince, or having a hardware issue.

Edit: Actually, maybe not really that deep an error. Did you try reconnecting?[/QUOTE]

Yes, after reconnecting every seems to work fine. Only saw this error message once. Error codes are scary.

I noticed the colab now halts my session every couple hours instead of full 12 hours now. I guess they're onto us hehehe

Colab Exiting on "Getting Initial Work" Phase.
 

I tried several times including restarting the tunnels.

[QUOTE=petrw1;530947]I tried several times including restarting the tunnels.[/QUOTE]

There appears to have been a change in the underlying VM on Colab.

The mfaktc executable which has worked since the beginning of September is no longer working on Colab (but still is under Kaggle). Absolutely no changes to the bootstrap payload nor server code.

I'm currently seriously handicapped wrt workstation capability. If anyone can build a mfaktc which works in the new environment, please post it here or email it to me.

An exceptionally unhappy day today. Tomorrow (or, actually, now, today) us unlikely to be much more fun...

[QUOTE=chalsall;530954]There appears to have been a change in the underlying VM on Colab.

The mfaktc executable which has worked since the beginning of September is no longer working on Colab (but still is under Kaggle). Absolutely no changes to the bootstrap payload nor server code.[/QUOTE]
I can confirm that it is an issue with Colab, not an issue with chalsall's creation. Mfaktc has stopped working for me on Colab, and I don't use chalsall's tunneling approach. It went from [CODE]ERROR: get_next_assignment(): no valid assignment found in "worktodo.txt"[/CODE]to [CODE]
./mfaktc.exe: error while loading shared libraries: libcudart.so.10.0: cannot open shared object file: No such file or directory[/CODE]somewhere in Nov 16 to Nov 18, after I replenished an exhausted worktodo file. Meanwhile gpuowl and mprime continue to work.
[URL]https://www.mersenneforum.org/showthread.php?p=527911#post527911[/URL]

Unfortunately, while [URL]https://download.mersenne.ca/[/URL] has NVIDIA dlls for Windows, it does not have the corresponding .so files for linux, perhaps because there are so many flavors. So off to NVIDIA for a download for x86_64 ubuntu: [URL]https://developer.nvidia.com/cuda-downloads?target_os=Linux&target_arch=x86_64&target_distro=Ubuntu&target_version=1804[/URL]

"Fixed" the problem, put !apt-get -y install cuda-cudart-10-0
before it launches bootstrap.pl

[QUOTE=kracker;530998]"Fixed" the problem, put !apt-get -y install cuda-cudart-10-0 before it launches bootstrap.pl[/QUOTE]

Sweet! Thanks!!!

Just back from buying a new MB, CPU and RAM. Going offline to rebuild the machine now.

I'll be able to apply the change later today (hopefully)...

[QUOTE=kracker;530998]"Fixed" the problem, put !apt-get -y install cuda-cudart-10-0
before it launches bootstrap.pl[/QUOTE]

:fusion:

Any way to reset the uptime?
 

Sometimes my multiple Colab sessions get "out of sync" — that is, the uptime values are not the same.

Is there any way to stop and restart a notebook so the uptime restarts at zero? So far whenever I restart one, the uptime value resumes where it left off.

I could just let them all run out, but that would waste two sessions while the shortest one runs out (24 hours on the paid tier).

[QUOTE=Chuck;538600]Is there any way to stop and restart a notebook so the uptime restarts at zero? So far whenever I restart one, the uptime value resumes where it left off.[/QUOTE]

Under the Colab front end's "Runtime" menu, choose "Restart Runtime".

I /believe/ this gives you a freshly launched runtime, but I could be wrong. If that doesn't help, try the "Factory reset runtime" menu time.

Failing all of that not working, try "Manage Sessions" -> "Terminate" on the pop-up window, assuming that option isn't greyed out.

I'd test this myself, but I don't want to risk losing any of my current seven T4s... :wink:

BTW, thanks for beta testing the P-1'ing CPU side-job thingy. Looks like it's working nominally.

The Colab CPU
 

The Colab CPU doesn't work like I thought it would. I thought I would get a second executing cell with scrolling output like the GPU process. The CPU process seems to run secretly.

Could you give a simplified explanation as to how this works?

[QUOTE=Chuck;538602]Could you give a simplified explanation as to how this works?[/QUOTE]

Under the Notebook concept, only a single "Section" can run at a time. Thus, it would be impossible to have a second scrolling section of the output. This interface concept is more designed for education. We're doing this at the sufferance of (and thanks to) Google -- we work with what we've been given...

Thus, the GPU72_TF Notebook launches a subprocess that runs in the background, fetching, working, and reporting on the CPU "work units".

Now that I'm happy that the code is sane (including with the server interaction, and restarting), the next step is to make the progress lines from the CPU process available to the GPU process, to report in the same window output to the humans.

[QUOTE=chalsall;538601]Under the Colab front end's "Runtime" menu, choose "Restart Runtime".

I /believe/ this gives you a freshly launched runtime, but I could be wrong. If that doesn't help, try the "Factory reset runtime" menu time.

Failing all of that not working, try "Manage Sessions" -> "Terminate" on the pop-up window, assuming that option isn't greyed out.

I'd test this myself, but I don't want to risk losing any of my current seven T4s... :wink:

BTW, thanks for beta testing the P-1'ing CPU side-job thingy. Looks like it's working nominally.[/QUOTE]

Restart runtime started with the old uptime.
Factory reset runtime started over at zero.

Selftest loop
 

I can't say I've ever seen this before but somehow I'm stuck in a self test loop and can't get out of it. Any suggestions? I've done interrupt execution and then did run all and it just picked right back up with the test.

20200415_143255 ( 0:28): running a simple selftest... 20200415_143301 ( 0:28): Selftest statistics 20200415_143301 ( 0:28): number of tests 107 20200415_143301 ( 0:28): successfull tests 107 20200415_143301 ( 0:28): selftest PASSED! 20200415_143301 ( 0:28): Fetching initial work... 20200415_143302 ( 0:28): Running GPU type [B]Tesla P100-PCIE-16GB[/B]


Edit: If I stop execution I get...

Exiting...
20200415_143808 INFO: Comms spider starting... 20200415_143808 INFO: Gracefull shutdown... Use of uninitialized value $AID in concatenation (.) or string at ./comms.pl line 309. Done.

[QUOTE=mrk74;542765]I can't say I've ever seen this before but somehow I'm stuck in a self test loop and can't get out of it. Any suggestions?[/QUOTE]

Yeah... Swear in my general direction...

I made a mistake in a change to the assignment code-path just now, moving LG72D down to 99M for a while. If you just rerun your Notebook things should be sane again.

[QUOTE=chalsall;542766]Yeah... Swear in my general direction...[/QUOTE]


Nah I won't go THAT far. Did another "run all" and it's back to normal. :smile:

I have seen 2 or 3 cycles in the beginning. The GPU type get reported. It runs through again the GPU type gets reported etc. It does start the test after it has looped 1 or 2 times. (Don't ever think I have seen more.) Doesn't seem harmful, so I haven't said anything.

[QUOTE=Uncwilly;542788]Doesn't seem harmful, so I haven't said anything.[/QUOTE]

OK. Thanks for the report.

I don't understand why it happens, but *very* rarely the Notebook payload doesn't get work, and so the (newish) loop catches (and recovers from) this edge-case.

Having done some drill-down a while ago, I suspect that it's a temporary networking issue between the Colab instance and the GPU72 server. In cases where I've observed this myself, there's no record in the server's logs of an initial fetch attempt.

Concurrency is fun! :smile:

I got a T4 just now on my maiden voyage with Colab. :smile:
It looks like it is doing 1 class per minute.

[QUOTE=kladner;542797]I got a T4 just now on my maiden voyage with Colab. :smile:
It looks like it is doing 1 class per minute.[/QUOTE]

T4 on your first try? Sounds like a typical bait-and-switch strategy to me. :smile:

My expectation are limited. It's good while it lasts.
BTW: How often does Colab submit results, and where do they appear?

[QUOTE=kladner;542822]BTW: How often does Colab submit results, and where do they appear?[/QUOTE]

In order to automatically have results be submitted to Primenet, the system needs to know your Primenet Username (but not your PW). Please go to [URL="https://www.gpu72.com/account/settings/"]your account settings page[/URL], and enter this information on that form.

Then your results appear in your usual [URL="https://www.gpu72.com/account/completed/"]Completed Assignments[/URL] report.

Thanks for trying out the GPU72_TF'ing thing. Also, so you know, when GPU72 knows your PNUN, you'll also be given P-1 work to do in parallel, on the CPU. Not terribly fast, but it all adds up... :smile:

Thanks! [STRIKE]Would that be the Login or the Public name?[/STRIKE]
Nevermind. The mention of password not needed answers that. :smile:

Working on the 9th TF now.

Do I need to restart the runtime for this to take effect?

[QUOTE=kladner;542824]Do I need to restart the runtime for this to take effect?[/QUOTE]

Nope. The auto submission starts as soon as I do a bit of "magic" in the background, which I just did. You'll now see a GPU72_TF "Virtual Machine" in your Primenet Computer's list, and the eight just-submitted results.

The P-1 CPU work won't be assigned until you start your Notebook again. It's safe to stop and then restart your current running session, or you can just wait until your next run. Up to you.

[QUOTE=chalsall;542823]Also, so you know, when GPU72 knows your PNUN, you'll also be given P-1 work to do in parallel, on the CPU.[/QUOTE]

I'm sure this has been considered before but the ones which have not added the PNUN (Primenet Username) would it be beneficial to sieve on the CPU and let the GPU be dedicated to TF?

[QUOTE]The auto submission starts as soon as I do a bit of "magic" in the background, which I just did. [/QUOTE]Woohoo! Thanks Chris.
I actually hate to restart while I have a T4 crunching, especially since that seems like a privileged assignment. After this many hours I'll probably have limits kicking in sometime.

EDIT: Update: The first run, with the T4 lasted many hours. I'm still not tuned in enough to see how long. I fumbled around this morning a good bit before I got the notebook running again. It came up with a P4, which seems to run at about 0.4 of the T4 speed. P-1 started up and reports every 5 minutes, interleaved with the TF output.

Another edit: Unlike Covid-19, where flattening the curve is the object, Colab is starting to bend my 30 average curve upward. :smile:

[QUOTE=RichD;542826]I'm sure this has been considered before but the ones which have not added the PNUN (Primenet Username) would it be beneficial to sieve on the CPU and let the GPU be dedicated to TF?[/QUOTE]

Actually, I hadn't thought of that... Although I suspect that with the CPUs so (relatively) underpowered, and the GPUs so high-end, that there wouldn't be much upside in doing that.

One thing I've modeled is to give P-1'ing work to those who's PNUN isn't known by GPU72, but under a collective Primenet account. Each worker would get the credit on GPU72, but not Primenet. (Assuming, of course, that the worker hasn't disabled CPU work in their instance(s) settings.)

Barbados is currently suffering hugely degraded international connectivity at the moment. FLOW, our provider, is either having OSPF and/or BGP issues. Frustrating!

[QUOTE=kladner;542827]It came up with a P4, which seems to run at about 0.4 of the T4 speed.[/QUOTE]

Yeah. One of the tricks we've figured out is if you get a P4 or a K80, go to the Runtime menu and choose "Factory Reset". Then "Connect" again, and rerun your Notebook. After a few itterations you should get a P100 or a T4 -- worth the effort! :smile:

[QUOTE=chalsall;542864]Yeah. One of the tricks we've figured out is if you get a P4 or a K80, go to the Runtime menu and choose "Factory Reset". Then "Connect" again, and rerun your Notebook. After a few itterations you should get a P100 or a T4 -- worth the effort! :smile:[/QUOTE]
Thanks! That got me a P100. Looks like it runs at about 0.65 of a T4.

UPDATE: After 8.5 hours, the CPU is up to 77% of Stage 1 of its first P-1 run. [STRIKE]Two cores of an i7-6700K do both stages in 3-3.5 hours.[/STRIKE] In the past I have found information on the CPU running the notebook, but now I can't track it down. It seems hard to believe that even a single core would take that long on Stage 1.
EDIT: EEK! I have to retract my statement about 6700K run times (@ 4.3 GHz, 32 GiB DDR4-3000). Total brain fart. I'm seeing S1 ~5 hours, and S2 a bit over 6 hours.
Found the CPU type in Primenet account summary, and of course on the CPUs page. Currently:
Intel Xeon E3-1230 v6 @ 3.50GHz GPU72_TF Linux64,Prime95,v29.8,build 6 2020-04-17 01:04
OK. In broad terms, if some parity is assumed between CPUs, doubling the 6700K S1 timing says a single core might take ~10 hours. The single 3.5 GHz Xeon core is not going to match that. It is at 83% at 9h 52m.

OK. After a few Factory resets I got a T4 again. (The resets were after I poked the wrong thing and disconnected the notebook.) However, the CPU started a new P-1. The one that was running is in the GPU72 Assignments, showing ~82% Stage one. Is there some way to recover this job?

Dang! T4s are bloody fast! Does a 'what makes sense' assignment (99.7M) in 32 min where the best my 1060 can do is about 3 times that. I know that is lower rank and older hardware, but Sheesh!

I must be missing something. I now have two partial P-1 S1 assignments, and the current run started another. I've looked through the thread but haven't found anything relevant for searching "resume." Sorry for being needy. :redface:

[QUOTE=kladner;542958]I must be missing something. I now have two partial P-1 S1 assignments, and the current run started another. I've looked through the thread but haven't found anything relevant for searching "resume." Sorry for being needy. :redface:[/QUOTE]

No problem. And I don't think this behavior has been clearly laid out...

The P-1 assignment code has a longer timeout period between reissuing work. Forty (40#) minutes between the last check-in (CKPoint file or Estimated completion) and when it will be reissued to another Instance. I can probably shorten this now that the code (finally) looks sane (read: no edge-cases (that I know of)).

You *will* get this assignment back, with the checkpoint file to continue from. So at most ten minutes of work will have been lost (average five, of course).

P.S. Oh, also... I don't yet have the system un-reserving abandoned assignments without work done yet. Maybe over the weekend I can implement that -- not a bug, it just means a few assignments may collect in your account while being processed.

That is a relief! Thanks Chris. I currently have 3 at 10%, 19%, and 98%. Meanwhile it is working on a 4th. It's good to know it will return to those. I'm still just running 1 notebook, but I've been thinking about getting another Google account to try running another.


One other thing: In Tools>Settings>Miscellaneous what do the setting for Power, Corgi mode, and Kitty mode do? Are they applicable to our work?

[QUOTE=kladner;542965]One other thing: In Tools>Settings>Miscellaneous what do the setting for Power, Corgi mode, and Kitty mode do? Are they applicable to our work?[/QUOTE]

Not at all applicable to our work. But very amusing to try... Googlers have a great sense of humor! I particularily like Kitty mode! :smile:

LOL! I'll give it a try on the next restart. Thanks again.


Later: No restart was needed. Try turning them on together.

Becoming a YouTube Star! (Or maybe just a Nerd...)
 

So, I plan to start producing training videos, to teach kids how to do various geeky things.

I'm just getting started, and uploaded my very first YouTube video just now. This is using some really neat Open Source desktop capture software I've found --
[URL="https://obsproject.com/"]Open Broadcaster Software[/URL]. Still making friends with it, but wow! Seem very capable.

My first video is an experiment; mostly just a proof-of-concept. The audio is effectively non-existent. It's picking up my office fan and my typing (I forgot to speak during the recording). But the video shows the Factory Reset trick, as well as how I use my Reverse SSH Tunnels to get Bash shell access to and telemetry from the running sessions.

[url]https://youtu.be/IAXEpRvUEkc[/url]

I think cultivating and encouraging geeky kids is a fantastic idea! They may be really glad for the support, too.

[QUOTE]I've been thinking about getting another Google account to try running another.[/QUOTE]
oops. Misconception, I think. After more study I just started another notebook with my key on it. Both are P100s at the moment. I haven't lucked into a T4 for a while. I don't know how you manage to snag 7. I did go paid BTW. Not running mfaktc locally won't pay for it, but the machine will get cooler and quieter.


So far, the second instance has not showed up in GPU72 or Primenet.

[QUOTE=kladner;543024]oops. Misconception, I think. After more study I just started another notebook with my key on it. Both are P100s at the moment. I haven't lucked into a T4 for a while. I don't know how you manage to snag 7. I did go paid BTW. Not running mfaktc locally won't pay for it, but the machine will get cooler and quieter. So far, the second instance has not showed up in GPU72 or Primenet.[/QUOTE]

I see in my Admin report that you are running two instances, both with the same name. If you want to differentiate between them, just create a new Instance Key (or more).

So you know, all your TF results show up on Primenet under the GPU72_TF "virtual machine". If you create a new key, a new machine will appear on Primenet for your P-1 submissions.

Lastly, Chuck is also using the paid tier, and he's reported he's only ever seen P100s (he regularly runs four at a time). This surprises me a bit, since I'm on the free tier (paid isn't available except in the USA) and quite regularly get T4s.

OK. I saw the advice to rename, but I only named the instances Note 01 and 02. I'll create another key, then.
Oh, and thanks again. This is a fun thing to poke at, but I'm still learning a lot of it.

[QUOTE=chalsall;542823]In order to automatically have results be submitted to Primenet, the system needs to know your Primenet Username (but not your PW). Please go to [URL="https://www.gpu72.com/account/settings/"]your account settings page[/URL], and enter this information on that form.

Then your results appear in your usual [URL="https://www.gpu72.com/account/completed/"]Completed Assignments[/URL] report.

Thanks for trying out the GPU72_TF'ing thing. Also, so you know, when GPU72 knows your PNUN, you'll also be given P-1 work to do in parallel, on the CPU. Not terribly fast, but it all adds up... :smile:[/QUOTE]
Hey Chris,
I just went to the account settings page and found that I had entered kladner as klander. I'm not sure how any results are showing up. It doesn't seem that I can change it.
Also, on my first key, where I have two notebooks running, can I just stop using the second one and let the other pick up the assignments? Or tell it to stop getting assignments and finish what it's got?


But meanwhile, I got 4 instances running and showing up in GPU72! Had to resolve a 'Too many sessions' issue. Finally terminated them all, reset the notebooks, and restarted them gradually, though I don't know if that matters.

[QUOTE=kladner;542973]Try turning them on together.[/QUOTE]
Don't. Check CPU resources used by the browser. They may or may not increase (depending on your CPU) but generally, all animations (unless is a stream) run locally, taking few percents of your locally running P95. Less animations in your browser/screen, more resources for P95 running in background.

[QUOTE=LaurV;543037]Don't. Check CPU resources used by the browser. They may or may not increase (depending on your CPU) but generally, all animations (unless is a stream) run locally, taking few percents of your locally running P95. Less animations in your browser/screen, more resources for P95 running in background.[/QUOTE]
Agreement. It was cute for a minute or two at most.

This is a series of notes while I have getting a grip on various Colab procedures. The sections are probably hours apart.

About P100 versus T4: maybe this is one of those heavy user limitations. This is relative to a discussion earlier of paid accounts only getting P100 GPUs, while some free users get frequent T4 access, which are substantially faster.

Saturday: After a lot of messing around I am finding that High-RAM is troublesome. It seems that the only way to use it is to set it for all Runtimes. There is no way I have found to know which P-1 runtimes are going to be doing Stage 2 assignments. It seems wasteful, and I suspect it would be another reason for being throttled.

Follow up: I got 2 notebooks to go into High RAM mode for S2, but they both are only using 10.78GB out of ~25 GB available. 10.78 fit in the standard memory of 12 something. Do they have to have Hi-RAM enabled from the beginning of the run?

More fussing with RAM. Getting the notebook to shift back to standard memory takes factory reset, prodding, and patience as things realign themselves. When it gets going again, it is only using 9 of 12+GB. I'm not sure if an additional 1.7GB is enough to matter. Can the program be set to use more? There are probably 21-22GB available in Hi-RAM mode. I see this line in the P-1 launch:
99904531 using up to 10240MB of memory. Can that be doubled? That would get almost in range of doing 480 relative primes in one pass.

Later still: I can switch freely between High and Standard RAM. It takes a few seconds, although the runtime sometimes glitches. A Factory Reset will snap it out, I don't know at this point what assignment will come up: S1 or S2. A bother, but switching RAM size can transition while underway. Also clear the screen.

This is really cool! I am having a blast!

Would I be right in assuming you can only do TF and P-1 with Colab? Was hoping to maybe do some LL but if I'm looking at it right that's not a possibility right?

[QUOTE=mrk74;543127]Would I be right in assuming you can only do TF and P-1 with Colab? Was hoping to maybe do some LL but if I'm looking at it right that's not a possibility right?[/QUOTE]
I don't know for sure if there's any work being done on LL. My personal feeling is that the CPU's aren't that fast: Intel Xeon E3-1230 v6 @ 3.50GHz, and you get one core. The thing to check for is if anyone is getting CUDALucas set up to run LL on notebook GPUs. There's a good bit of discussion and instruction in this thread that might help. Also, more knowledgeable folks will have more to say. I've only picked up on this in the last few days.

[QUOTE=mrk74;543127]Would I be right in assuming you can only do TF and P-1 with Colab? Was hoping to maybe do some LL but if I'm looking at it right that's not a possibility right?[/QUOTE]

Colab is a general-purpose GPU and/or CPU ephemeral compute environment, so doing LL/PRP is certainly possible. Probably using an attached Google Drive for persistent storage between instance runs. See [URL="https://mersenneforum.org/showthread.php?t=24839"]Ken's reference[/URL] area for some ideas on how you might proceed.

GPU72's Notebook is focused on TF'ing (on the GPU) and P-1'ing (on the CPU). I don't have any plans to expand into First Checking. In addition to being super busy, there's the question of what would happen if a Colab instance found the next MP...

[QUOTE=mrk74;543127]Would I be right in assuming you can only do TF and P-1 with Colab? Was hoping to maybe do some LL but if I'm looking at it right that's not a possibility right?[/QUOTE]

You can do LL on a Colab instance (and really any work that PrimeNet can dish out). You'll need my [URL="https://www.mersenneforum.org/showthread.php?p=527399#post527399"]mprime notebook code[/URL] in order to run it. With that code you'll need to change the line V5UserID=Dylan14 to your PrimeNet ID.
There are a few issues with PRP though. See [URL="https://www.mersenneforum.org/showpost.php?p=527910&postcount=3"]kriesel's post on mprime in Colab[/URL].

I feel like a kindergarten kid on time out. My notebooks were disconnected this morning. When I tried to restart one, the GPU Nazi kicked in, "No GPU for You!" Aw shucks. I only managed to quadruple my throughput in the last few days. :cmd: :wink:

[QUOTE=kladner;543166]I feel like a kindergarten kid on time out. My notebooks were disconnected this morning. When I tried to restart one, the GPU Nazi kicked in, "No GPU for You!"[/QUOTE]

Nominal behavior. You'll get used to its "mood(s)" after a few days of use. I have mental temporal alarms set in my head now -- "Oh, it's 1300 UTC. Time for SSG to get to work..."

[QUOTE=kladner;543166]Aw shucks. I only managed to quadruple my throughput in the last few days. :cmd: :wink:[/QUOTE]

Yeah. Not too bad for $10 USD a month, huh? I'd happily pay for the Pro version, if they'd just let me. Oh, also, I've moved my last running Barbados based GPU (a slow and inefficient 560) into standby, since it was only producing ~200 GHzD/D.

It's great! I think I will try the second Google account to see if I can get any T4s. :smile:
I am letting the current assignments on the GTX1060 run out. No need to feed more local electricity for such a small return. Maybe I'll put that card back to actual display work. I've been running display with the onboard adapter, but switching will also allow better co-processing for graphics programs.

EDT: Well, scratch the above, for now. I apparently don't know how to cover my tracks sufficiently. I got outed instantly.

So I had/have a colab session. It finished 1 P-1 and then the CPU part did not start another.
[CODE][COLOR="SeaGreen"]0200429_000702 ( 0:44): 99924313 stage 2 complete. 113978 transforms. Time: 2529.885 sec.
20200429_000702 ( 0:44): Starting stage 2 GCD - please be patient.[/COLOR]
20200429_000732 ( 0:44): 98157911 74 to 75 78.9% 6m45s 1756.67 1.997s | 3636/4620, 757/960 | 20.83G | 10429.0M/s | 82485
[COLOR="seagreen"]20200429_000740 ( 0:45): Stage 2 GCD complete. Time: 36.372 sec.
20200429_000740 ( 0:45): 99924313 completed P-1, B1=775000, B2=15112500, E=6, Wh8: 19FD743E
20200429_000740 ( 0:45): 99924313 completed P-1, B1=775000, B2=15112500, E=6, Wh8: 19FD743E, AID: 40bb898f0b301263139f3535d43fabc3[/COLOR]
20200429_000832 ( 0:45): 98157911 74 to 75 82.0% 5m45s 1757.55 1.996s | 3781/4620, 787/960 | 20.83G | 10434.3M/s | 82485
20200429_000932 ( 0:46): 98157911 74 to 75 85.1% 4m46s 1752.28 2.002s | 3921/4620, 817/960 | 20.83G | 10403.0M/s | 82485
20200429_001032 ( 0:47): 98157911 74 to 75 88.2% 3m46s 1755.79 1.998s | 4068/4620, 847/960 | 20.83G | 10423.8M/s | 82485
20200429_001132 ( 0:48): 98157911 74 to 75 91.4% 2m46s 1751.40 2.003s | 4204/4620, 877/960 | 20.83G | 10397.8M/s | 82485
20200429_001232 ( 0:49): 98157911 74 to 75 94.5% 1m46s 1760.19 1.993s | 4348/4620, 907/960 | 20.83G | 10450.0M/s | 82485
20200429_001332 ( 0:50): 98157911 74 to 75 97.6% 0m46s 1753.15 2.001s | 4504/4620, 937/960 | 20.83G | 10408.2M/s | 82485
20200429_001420 ( 0:51): no factor for M98157911 from 2^74 to 2^75 [mfaktc 0.21 barrett76_mul32_gs]
20200429_001420 ( 0:51): tf(): total time spent: 32m 15.475s
20200429_001420 ( 0:51): Starting trial factoring M97438519 from 2^74 to 2^75 (39.27 GHz-days)
[COLOR="Blue"][U]
20200429_001425 ( 0:51): Exponent TF Level % Done ETA GHzD/D Itr Time | Class #, Seq # | #FCs | SieveRate | SieveP[/U][/COLOR]
20200429_001428 ( 0:51): 97438519 74 to 75 0.1% 32m15s 1751.22 2.018s | 0/4620, 1/960 | 20.98G | 10396.7M/s | 82485
20200429_001529 ( 0:52): 97438519 74 to 75 3.6% 31m02s 1755.57 2.013s | 164/4620, 35/960 | 20.98G | 10422.5M/s | 82485
20200429_001629 ( 0:53): 97438519 74 to 75 6.8% 30m03s 1754.70 2.014s | 317/4620, 65/960 | 20.98G | 10417.4M/s | 82485
20200429_001743 ( 0:55): 97438519 74 to 75 9.5% 29m10s 1754.70 2.014s | 432/4620, 91/960 | 20.98G | 10417.4M/s | 82485
20200429_001844 ( 0:56): 97438519 74 to 75 13.8% 27m52s 1750.35 2.019s | 636/4620, 132/960 | 20.98G | 10391.6M/s | 82485
20200429_002004 ( 0:57): 97438519 74 to 75 16.8% 26m48s 1756.44 2.012s | 776/4620, 161/960 | 20.98G | 10427.7M/s | 82485
20200429_002105 ( 0:58): 97438519 74 to 75 21.0% 25m30s 1750.35 2.019s | 969/4620, 202/960 | 20.98G | 10391.6M/s | 82485
20200429_002224 ( 0:59): 97438519 74 to 75 24.1% 24m32s 1750.35 2.019s | 1109/4620, 231/960 | 20.98G | 10391.6M/s | 82485
20200429_002325 ( 1:00): 97438519 74 to 75 28.2% 23m06s 1757.31 2.011s | 1304/4620, 271/960 | 20.98G | 10432.9M/s | 82485
20200429_002446 ( 1:02): 97438519 74 to 75 31.4% 22m07s 1755.57 2.013s | 1445/4620, 301/960 | 20.98G | 10422.5M/s | 82485
20200429_002546 ( 1:03): 97438519 74 to 75 35.5% 20m50s 1750.35 2.019s | 1641/4620, 341/960 | 20.98G | 10391.6M/s | 82485[/CODE]

[QUOTE=Uncwilly;544151]So I had/have a colab session. It finished 1 P-1 and then the CPU part did not start another.[/QUOTE]

I have three of four notebooks that also stopped doing P-1

I saw something similar from sessions that ran overnight.

That was about the time that GPU72.com had some server maintenance.

[QUOTE=Uncwilly;544178]That was about the time that GPU72.com had some server maintenance.[/QUOTE]
Sorry. I don't understand. :confused2:

[QUOTE=kladner;544180]Sorry. I don't understand. :confused2:[/QUOTE]
GPU72 had some server downtime yesterday (time zone dependent). The P-1 in my example did not start a new exponent at about that same time. Maybe it was not able to get new work.

[QUOTE=Uncwilly;544183]GPU72 had some server downtime yesterday (time zone dependent).[/QUOTE]

Yeah... Sorry guys. Cascading SPEs...

Things should be back to nominal now (1500 UTC).

[QUOTE=Uncwilly;544183]GPU72 had some server downtime yesterday (time zone dependent). The P-1 in my example did not start a new exponent at about that same time. Maybe it was not able to get new work.[/QUOTE]
DOH! Thanks.

First let me say everything seems to be running fine as far as I can tell. I'm doing some P-1 only (darn usage limits) Anyway, I finished one exponent and went on to the next and when the next one started I got this. Don't know if it means anything substantial or not but thought I would let it be known.
[CODE]
20200429_203344 ( 6:39): [Comm thread Apr 29 20:33] PrimeNet error 7: Invalid parameter

20200429_203344 ( 6:39): [Comm thread Apr 29 20:33] parameter c: Invalid string length: 0
[/CODE]