<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
<br>&gt;      This is the "clock jump" problem that I reported here a number of times<br>&gt; last year.  It can be triggered by an interruption in transmission of data<br>&gt; over your Internet connection for a period exceeding<br>&gt; NUM_JUMPED_SECONDS_BEFORE_WARN seconds (see src/or/main.c).  Currently, that<br>&gt; is 100 seconds.  tor interprets this situation as meaning that it is running<br>&gt; on a system that has just awakened from suspension/hibernation, so it marks<br>&gt; all OR connections (and circuits over them) as having expired.  It has been<br>&gt; quite a few months since my relay last suffered from this situation, so I<br>&gt; don't remember now whether it also results in publication of a new descriptor<br>&gt; as if the relay had just been reinitialized.<br>&gt;      In the short run, you can work around the problem with the patch below,<br>&gt; which will reduce broken connections but will not stop the holdups nor their<br>&gt; effect upon the tor network.  The better, longer-term solution is most likely<br>&gt; to fire your ISP and hire a better one, which is what I did at the earliest<br>&gt; opportunity.<br>&gt; <br>&gt;  ----------&gt;8 start of clockjump patch to 0.2.1.12-alpha 8&lt;------------------<br>&gt; *** main.c        2009/02/10 16:35:05        0.1<br>&gt; --- main.c        2009/02/10 16:40:15<br>&gt; ***************<br>&gt; *** 1200,1206 ****<br>&gt;   <br>&gt;   /** If more than this many seconds have elapsed, probably the clock<br>&gt;    * jumped: doesn't count. */<br>&gt; ! #define NUM_JUMPED_SECONDS_BEFORE_WARN 100<br>&gt;     if (seconds_elapsed &lt; -NUM_JUMPED_SECONDS_BEFORE_WARN ||<br>&gt;         seconds_elapsed &gt;= NUM_JUMPED_SECONDS_BEFORE_WARN) {<br>&gt;       circuit_note_clock_jumped(seconds_elapsed);<br>&gt; --- 1200,1206 ----<br>&gt;   <br>&gt;   /** If more than this many seconds have elapsed, probably the clock<br>&gt;    * jumped: doesn't count. */<br>&gt; ! #define NUM_JUMPED_SECONDS_BEFORE_WARN 300<br>&gt;     if (seconds_elapsed &lt; -NUM_JUMPED_SECONDS_BEFORE_WARN ||<br>&gt;         seconds_elapsed &gt;= NUM_JUMPED_SECONDS_BEFORE_WARN) {<br>&gt;       circuit_note_clock_jumped(seconds_elapsed);<br>&gt;  ----------&gt;8 end of clockjump patch to 0.2.1.12-alpha 8&lt;--------------------<br>&gt; <br>&gt; I haven't tried this on 0.2.0.34, but this area of the code seems to change<br>&gt; fairly infrequently, so patch(1) can usually deal with changes in the line<br>&gt; numbers from release to release.  Or you can change "100" to "300" by hand,<br>&gt; or course. :-)<br>&gt; <br>&gt; <br>&gt;                                   Scott Bennett, Comm. ASMELG, CFIAG<br>&gt; <br><br>Thank you, that makes sense.<br>I don't compile, so I can't apply the patch, but perhaps the developers could add that constant to the torrc options?<br><br>GD<br><br /><hr />Windows Live™: Keep your life in sync.  <a href='http://windowslive.com/explore?ocid=TXT_TAGLM_WL_allup_1b_explore_032009' target='_new'>Check it out.</a></body>
</html>