<br><br><div class="gmail_quote">On Wed, Jan 30, 2013 at 4:43 AM, Fritz Payr <span dir="ltr">&lt;<a href="mailto:fritz.payr@salzburgresearch.at" target="_blank">fritz.payr@salzburgresearch.at</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Hi,<br>
<br>
I am trying to run an IPython notebook and (with it) use a Linux-cluster<br>
for long-running parallel work.<br>
My PC runs Windows7, and the network connecting it with the cluster<br>
tends to shut down ssh-connections from time to time. I&#39;ve tried running<br>
the notebook on the cluster (with a ssh-tunnel bringing it to a browser<br>
on my PC) and on my PC (with a ipcontroller running on the cluster,<br>
connected via the built-in ssh).<br></blockquote><div><br></div><div>First, let me express my gratitude that you are giving the Windows SSH code an exercise (you may be the first).</div><div>I&#39;m glad it at least sort-of works.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Both setups have problems:<br>
<br>
If I have the notebook running on the cluster ssh-tunneling to a browser<br>
on my PC I don&#39;t know how to &quot;reconnect&quot; the browser to the &quot;old<br>
session&quot; when the tunnel breaks down.<br></blockquote><div><br></div><div>This is probably easier.  If this connection is lost, you can just open a new tunnel,</div><div>with</div><div><br></div><div>ssh -f -N -L 127.0.0.1:LPORT:HOST:RPORT SERVER</div>

<div><br></div><div>(or whatever the Windows equivalent).  Precisely the same call as you used to start the first tunnel.</div><div><br></div><div>The Notebook may lose *websocket* connections (execution, output) when the tunnel goes down,</div>

<div>but you should at least be able to do things like save the notebook after re-establishing the tunnel</div><div>and then refresh the page to get new websocket connections.</div><div>This is one of the things that is probably better in current master than 0.13.1 - websockets will reconnect automatically,</div>

<div>and if the reconnect fails you get a dialog that lets you reconnect manually. This makes it harder to lose websocket connections</div><div>in a way that forces a page refresh.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<br>
If the notebook is running on the PC ssh-ing with the ipcontroller on<br>
the cluster, it seems they silently &quot;loose contact&quot; during long tasks.<br>
Then I can see the cluster finish its tasks (all 80 x 16 hours!), but<br>
the notebook remains &quot;busy&quot; and doesn&#39;t receive anything. - No idea how<br>
I could retrieve the results from the ipcontroller, the engines, or<br>
anyone else!<br></blockquote><div><br></div><div>The Hub can remember all tasks, so you can actually request past results by ID</div><div>with calls like `client.get_result(msg_id)`.  So you can do things like submit a bunch of tasks that will take days,</div>

<div>then in a later, totally different session, retrieve the results.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Is it bad to have tasks that run for so long?<br></blockquote><div><br></div><div>Not generally, but it may be if you have intermittent connection issues.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


Or is there a standard way to distribute notebook and cluster on an<br>
&quot;unstable network&quot; without these problems? - Surely it doesn&#39;t make<br>
sense to run a browser on the cluster?!<br></blockquote><div><br></div><div>No, there is no general solution to unreliable networks.</div><div>The real solution is to fix whatever erroneous configuration is killing these connections.</div>

<div>If you don&#39;t trust your connection, the best workaround is what I alluded to above:</div><div><br></div><div>1. submit tasks in a single session</div><div>2. record the msg_ids associated with that work in some persistent way (files, in the notebook itself, etc.)</div>

<div>3. retrieve results from the Hub via msg_ids (or filesystem, or anything else).</div><div><br></div><div>If you write your code such that submitting work and retrieving results are totally disconnected steps,</div><div>

then connections lost in between steps 2 and 3 should be less problematic.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
A smaller issue I noticed in the second configuration is that while<br>
IPython&#39;s paramiko can work nicely with PuTTY (rather: Pageant) to find<br>
private ssh keys, it doesn&#39;t recognize PuTTY&#39;s &quot;known hosts&quot; or remember<br>
its own. (Apparently PuTTY stores them in the registry, but paramiko<br>
would like them saved to a file by the application?) So I keep getting<br>
warnings about an unknown host (first time in the browser-notebook,<br>
later in its cmd-output) although it should be well-known by now.<br></blockquote><div><br></div><div>That sounds like an issue for Paramiko.  I don&#39;t know of anything IPython should be doing here.</div><div><br></div>

<div>-MinRK</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks,<br>
Fritz<br>
_______________________________________________<br>
IPython-User mailing list<br>
<a href="mailto:IPython-User@scipy.org">IPython-User@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/ipython-user" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-user</a><br>
</blockquote></div><br>