I use ColabPro for my deep learning work. Currently the ETA for every epoch is ~26 hours. I use the following code to avoid disconnection in the console:
function ClickConnect(){
console.log("Clicked on connect button");
document.querySelector("colab-connect-button").click()
}setInterval(ClickConnect,60000)
This code does maintain the interaction with Colab window.
However, I would like to know if this will help to automatically reconnect and get the code running beyond 24 hrs i.e. maximum runtime of ColabPro?
Related
I have a scenario, wherein if the user stays idle on the screen for 45 minutes, I will have to transfer the user to home screen.
In my Espresso test, I want to recreate the scenario, and i would not want to wait for 30 minutes for that to happen.
Is there a way we can advance time in Espresso?
I have checked idlingresource and waitingforview etc, but none of them seemed right to me. Can anyone guide me on how to advance time in espresso?
I don't know about manipulating the system clock for a test, but instead of hardcoding a 45-minute wait, you might want to handle the time limit with dependency injection - either by setting a timeout property, or passing in a Clock object that the code refers to, instead of accessing the system clock directly.
That way your test can either configure it with a more useful timeout setting, or the Activity (or whatever) can poll a Clock that you're able to manipulate from the test. (Having a configurable timeout would allow you to do things like set it as a user option too, maybe change the value in power-saving mode, etc)
Background: I'm trying to measure common metrics (e.g. firstContentfulPaint) using selenium with chromium over satellite links under different loss and delay parameters.
Problem: When running with high delay / loss rates, chromium stops the handshake relatively early with this error message: No recent network activity after 4001103us. (The exact number of microseconds changes but is always equal to between 4 and 5 seconds).
Found out so far:
This error message seems to be generated here: https://source.chromium.org/chromium/chromium/src/+/main:net/third_party/quiche/src/quic/core/quic_connection.cc;l=6323?q=%22No%20recent%20network%20activity%20after%22&ss=chromium
I believe the relevant variable is: quic_max_idle_time_before_crypto_handshake_seconds
and is set here: https://source.chromium.org/chromium/chromium/src/+/main:net/third_party/quiche/src/quic/core/quic_constants.h;l=139;drc=1b6e5b6710b7c002de308d7195326fc84d6e9b33
Question / TL;DR:
How do I change the timeout used by chromium during the handshake stage in HTTP/3 / QUIC? (without building chromium from scratch)
Thanks a lot!
while training my model google colab stops working and kernel got disconnected. What can I do to restart and continue my training ?
Google Colab notebooks have an idle timeout of 90 minutes and absolute timeout of 12 hours. This means, if user does not interact with his Google Colab notebook for more than 90 minutes, its instance is automatically terminated. Also, maximum lifetime of a Colab instance is 12 hours.
The one of the easiest method to prevent it from disconnecting is you can insert one more cell to the below and type
while True:pass
There are another methods to do that as well, one of these is:
You can basically open the console prompt and type
function ConnectButton(){
console.log("Connect pushed");
document.querySelector("#top-toolbar > colab-connect-button").shadowRoot.querySelector("#connect").click()
}
setInterval(ConnectButton,60000);
this is a js code which clicks on the connect button every 60 seconds to keep your session alive.
For long training files I recommend you to use GPU and local runtimes.
Suppose I have to move out 3 hours away from my girlfriend's apartment, and I am running a Colab Environment. I can't stop the process and I need to bring my computer with me. How can I prevent the running process from being disconnected?
I have tried that question, but I think the Google Colab Interface has changed a bit, so the answers are no longer up-to-date.
There are many answers there. Currently for me works perfectly to go to the console and type
function ClickConnect(){
console.log("Clicked on connect button");
document.querySelector("colab-connect-button").click()
}
setInterval(ClickConnect,60000)
Take note that this should prevent disconnecting after each 1.5 hours of inactivity, but each runtime, if you don't have Colab Pro, will be terminated after 12 hours.
Edit:
I have tested my self and come up that this works:
function ClickConnect(){
console.log("Clicked on connect button");
document.querySelector("#ok").click()
}
setInterval(ClickConnect,60000)
Note that it will throw an error, its ok, it means that the Disconnection notification is not shown. Once it appear it will be clicked to reconnect.
There is this article from towards science that might help you prevent colab from disconecting
As a second thought, I think that as long as your laptop stays connected and active to a network it will keep running, so, an alternative is to use your phone as a hotspot to connect; use ethernet && wifi all together in order when you remove the cable you'll still be connected. But you have to keep your laptop open so you need battery fully charged; otherwise use a different device to start colab from like phone or tablet.
I am creating a BREW app that requests the user's position.
If the phone cannot acquire the position, I would like to display an error.
How long should I wait for my callback to be called before I determine that the phone is not likely to get a GPS fix?
When a cold start is required, the receiver has to download a full set of Ephemeris data, which is broadcast from the GPS satellite over a 30 second cycle and re-transmitted every 30 seconds.
So I would say that 60-90 seconds (two or three Ephemeris cycles) would be a suitable time to wait before declaring failure.
http://www.navigadget.com/index.php/gps-knowledge/ttff-time-to-first-fix
Note that if a device requires an almanac download, the startup time can be much longer (on the order of 12.5 to 15 minutes). This is referred to as a Factory TTFF (Time to First Fix).
I might go with an increment (say 20 or 30 seconds) between notifying the user that you have failed to establish a link, and give them the option to stop trying. Keep at it until they stop you, or a set number of iterations have passes (say 5 - 10 iterations).
45-90 seconds.
For more information, see the GPS Time To First Fix article at Wikipedia.
But you can never know when the user actually has view to the satellites or not, maybe they are still inside when they start your program, so the approach suggested by Matthew Vines is much better than a constant delay.
Cellphone-specifically, I've had a Motorola phone that had a GPS receiver, but was horrendously bad at it - it could take it around 5 minutes to get a fix where my standalone Bluetooth receiver would manage in less than a minute.
Why are you declaring failure after a fixed timeout anyway? Why not, after a reasonable time has passed (say, a minute), display a message to the tune of "GPS fix still not available; but I'm still trying" with a possibility to cancel at any time if the user is fed up? What do you expect the user to do with the failure message you're proposing to give him?