Opened 8 years ago

Last modified 5 years ago

#522 new defect

Ability to work with system clock exclusively, and recover from clock jumps

Reported by: mk Owned by:
Priority: minor Milestone:
Component: router/general Version: 0.8.8
Keywords: Cc:
Parent Tickets:

Description

For environments where I2P router is started before clock is set to the correct time, it would be nice to be able to tell the router that it should use the system clock exlcusively, and not to adjust its internal clock offset. Whenever a clock shift is detected, the router can just perform a restart.

I have tried applying the following patches:

sed -i 's/\<return _offset;/return 0;/' core/java/src/net/i2p/util/Clock.java
sed -i 's/\<return _alreadyChanged;/return true;/' core/java/src/net/i2p/util/Clock.java
sed -i 's/\<return offset + systemNow;/return systemNow;/' router/java/src/net/i2p/router/RouterClock.java
sed -i 's/\( CLOCK_FUDGE_FACTOR =\) 1\*\(.*\);/\1 90*\2;/' router/java/src/net/i2p/router/Router.java

Nothing helps: with an incorrect clock, the router just goes into CPU hogging mode (see another bug), and does not recover whenever the clock is set to the correct time by an external service. There is no difference with not applying these patches, save for some missing warnings in the log.

I am filing this under defects, since ability to deal with clock jumps is a major issue. Tor does that just fine, for instance.

The configuration used is here (wrapper) and here (router). The VM is JamVM 1.5.4 with GNU Classpath 0.98 (linked against GMP).

Steps to reproduce: set the clock forward by 4 hours. Start I2P router, wait for a while. Set the clock to the correct time plus 15 minutes. Wait for a while. Set the clock to the correct time. Observe CPU hogging, no connections to peers. (Some steps may be unnecessary.)

Subtickets (add)

Change History (7)

comment:1 Changed 8 years ago by mk

PS. A very simple fix could be an option to soft restart on any system clock shift, and never using / ignoring the internal clock offset.

comment:2 Changed 8 years ago by zzz

  • Milestone changed from 0.8.9 to 0.9

I understand what you're saying and proposing, the trouble is that it goes in the opposite direction of what we've been working on for years and years. What we've learned after a massive amount of experience is that the system clock is often wrong, and we go to great lengths, with multiple sources and mechanisms, to discover the correct time and adjust as we go. And also to handle system clock jumps, both small and large.

When you start I2P before the system clock is accurate, and then step-adjust the system clock shortly after I2P starts, that stresses things quite a lot, and I'm not surprised that there are problems.

I'm not sure if your "simple fix" would indeed work... especially since you said your patches didn't work, those are almost the same thing.

As of 0.8.8 we do a soft restart after a clock shift of -1 minute or +2 1/2 minutes. It should be working, but if the clock shift is happening right during startup, there may be bugs that are difficult to reproduce.

In the short term I recommend you do what you can to prevent step-adjustments after i2p starts.

comment:3 Changed 8 years ago by mk

Indeed, I am working on having I2P start only after htpdate first sets the clock (the daemon only uses adjtime afterwards).

Forgive my ignorance - why does I2P need to maintain precise time at all? Tor, for instance, only requires an approximate clock window (+- 90 minutes or so) for the client to be able to connect - in order to prevent replaying attacks. And whenever Tor detects a clock jump, it assumes none of the circuits work anymore, and drops any existing circuits.

Time synchronization should be left to an external service, in my opinion. I guess that overall, it's much easier to have I2P perform a correct restart on any detected clock shift, instead of trying to replicate what is basically an unrelated functionality.

comment:4 Changed 8 years ago by zzz

Why? Many network messages contain expiration time stamps, and routers will drop expired messages (and messages that expire too far in the future). There are other features, for example netdb keyspace rotation, that require an accurate clock as well.

Yes, ideally it should be an external function, and on most computers it is, and works fine. But as I said above, we've learned over the years that there's a large number of computers in which the system clock is bad for whatever reason, and it was probably the number one reason why I2P didn't work for people. Our improvements over the years have almost completely eliminated that class of problem.

Having said that, I'm sure there are still issues to resolve, as you have pointed out in this and other tickets.

comment:5 Changed 8 years ago by mk

Well, I guess that you would agree that whereas a large number of computers do not indeed maintain an incorrect clock, some do, and hence the internal clock maintenance feature should be optional. For instance, I had to patch htpdate to be able to restart I2P when the clock is shifted by the HTP daemon.

comment:6 Changed 6 years ago by str4d

  • Milestone 0.9 deleted

comment:7 Changed 5 years ago by zzz

  • Priority changed from major to minor
Note: See TracTickets for help on using tickets.