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