![]() |
[QUOTE=PhilF;533834]If that was in writing I would. However, their silence about it is deafening.[/QUOTE]It is if you read between the lines. [URL]https://research.google.com/colaboratory/faq.html[/URL][QUOTE][B]Why are hardware resources such as T4 GPUs not available to me?[/B]
The best available hardware is prioritized for users who use Colaboratory interactively rather than for long-running computations. Users who use Colaboratory for long-running computations may be temporarily restricted in the type of hardware made available to them, and/or the duration that the hardware can be used for. We encourage users with high computational needs to use Colaboratory’s UI with a [URL="https://research.google.com/colaboratory/local-runtimes.html"]local runtime[/URL]. Please note that using Colaboratory for cryptocurrency mining is disallowed entirely, and may result in being banned from using Colab altogether.[/QUOTE] |
[QUOTE=kriesel;533837]It is if you read between the lines.[/QUOTE]
I guess since we are such a fringe case we should be used to having to read between the lines when it comes to what is acceptable behavior and what isn't. But Colab, unlike Kaggle, has never answered any of Chris' repeated emails about whether or not they wish we would just go away. |
[QUOTE=kriesel;533837]It is if you read between the lines. [URL]https://research.google.com/colaboratory/faq.html[/URL][/QUOTE]
It deosn't even require much reading between the lines, if you ask me. That's damn near explicit. |
[QUOTE=PhilF;533839]But Colab, unlike Kaggle, has never answered any of Chris' repeated emails about whether or not they wish we would just go away.[/QUOTE]
Correct. I've tried reaching out to them at least four different times, with not a single response -- not even a "Your email has been received". But then Google is (in)famous for being unreachable unless you're spending money with them (AdSense, GCE, etc). Also, it appears there is definitely some kind of a "per account" (NOT per user) quota'ing going on. Yesterday I was able to get four instances for 10 hours each -- three appearing to be here in Barbados, and one (RPi) tunneled into the States. All P100s. This morning none of the accounts are getting instances, but a Virtual Machine based browser (CentOS) tunneling into another IP in the States just got a back-end. I hadn't used this for the last two days. Also, I see twelve (12) different people have successfully had access to a GPU backend over the last fourteen (14) hours; six (6) people are running right now. Oh well... While the apparent randomness of the access can be a bit annoying, the good news is we haven't been banned. And, again, we can hardly complain about free compute. |
That which is not prohibited is allowed.
|
For a couple of days I was getting bumped off of colab after 20 minutes. I normally alternate between a pair of signons which run for ten hours each. I waited a day, and now it looks like things are back to "normal". I just had one session run for ten hours and I have successfully started the other one.
|
This saga kind of reminds me of Whack-a-Mole. :richd:
|
1 Attachment(s)
The [B]*** buffer overflow detected ***[/B] problem of CUDALucas on colab using P100 is [B]solved[/B] now.
When I first encountered this "buffer overflow detected" error on colab, I made a joke to my roommate that it must because the name of P100 is [COLOR="Red"]too long[/COLOR] - [B]Tesla P100-PCIE-16GB[/B]. Today when I tried to compile CUDALucas on colab I noticed that the compiler warnings that some sprintf may cause buffer overflow, and I found that the size of many char arrays is 32, which cannot accommodate some information that contains device name [B]if the name of device is [COLOR="Red"]too long[/COLOR][/B]...:davieddy: I enlarged the size of some array, and yes, it worked on colab P100 without "buffer overflow" error now... The compiler just told me everything, alas...:redface: Attached file contains the modified source file CUDALucas.cu, the binary CUDALucas.exe I compiled and the Makefile I used. In detail, I changed sizes of all char arrays which may cause overflow by sprintf to 371 or 742. Please notice me if I left some unchanged or I made some bad changes. I'm using the compiled binary to do a double check. About 13 hours for ~50M exponent. Seems a little slower than excepted to be. |
[QUOTE=Fan Ming;533913]The [B]*** buffer overflow detected ***[/B] problem of CUDALucas on colab using P100 is [B]solved[/B] now.
When I first encountered this "buffer overflow detected" error on colab, I made a joke to my roommate that it must because the name of P100 is [COLOR=Red]too long[/COLOR] - [B]Tesla P100-PCIE-16GB[/B]. Today when I tried to compile CUDALucas on colab I noticed that the compiler warnings that some sprintf may cause buffer overflow, and I found that the size of many char arrays is 32, which cannot accommodate some information that contains device name [B]if the name of device is [COLOR=Red]too long[/COLOR][/B][/QUOTE]Interesting. I count "Tesla P100-PCIE-16GB" as 20, and "GeForce GTX 1080 Ti" as 19.[CODE]CUDALucas v2.06beta 64-bit build, compiled May 5 2017 @ 13:02:54 binary compiled for CUDA 8.0 CUDA runtime version 8.0 CUDA driver version 8.0 ------- DEVICE 0 ------- name GeForce GTX 1080 Ti [/CODE]But, "GeForce GTX 1060 3GB" as 20 also, and no problem.[CODE]CUDALucas v2.06beta 64-bit build, compiled May 5 2017 @ 13:00:15 binary compiled for CUDA 6.50 CUDA runtime version 6.50 CUDA driver version 8.0 ------- DEVICE 0 ------- name GeForce GTX 1060 3GB [/CODE]Those are from flashjh's compiles for Windows. |
[QUOTE=Fan Ming;533913]Attached file contains the modified source file CUDALucas.cu, the binary CUDALucas.exe I compiled and the Makefile I used.
In detail, I changed sizes of all char arrays which may cause overflow by sprintf to 371 or 742. Please notice me if I left some unchanged or I made some bad changes. I'm using the compiled binary to do a double check. About 13 hours for ~50M exponent. Seems a little slower than excepted to be.[/QUOTE] Thanks, I used your CUDALucas.cu and compiled it as well and it works. But you should ONLY use CUDALucas on the P100 if you want to do double check LL tests, because gpuowl is faster for first time tests: I'm getting 1.17ms/iteration on 5120K FFT on gpuowl and 1.44 ms/iteration on 5184K FFT on CUDALucas (and even more on 5120K). |
[QUOTE=ATH;533949]Thanks, I used your CUDALucas.cu and compiled it as well and it works.
But you should ONLY use CUDALucas on the P100 if you want to do double check LL tests, because gpuowl is faster for first time tests: I'm getting 1.17ms/iteration on 5120K FFT on gpuowl and 1.44 ms/iteration on 5184K FFT on CUDALucas (and even more on 5120K).[/QUOTE] Yes, gpuowl is significantly faster. |
| All times are UTC. The time now is 23:01. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.