Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
/ 2004-04-12 12:15:19 -0500 \ Todd Denniston: > > The only thing where DRBD has a notion of time are some local > > timers, connection timeout and so on. It just deferres certain > > actions by some configured amount of time (usual seconds) > > relative to "now". E.g. I issue a DrbdPing, and then set a > > timer to notify me after, say, 6 seconds... if the peer > > answers in time, the timer action is discarded again. > > > > A smoothly adjusting time via NTPD by sub-second amounts... > > How should that be noticed at all, and by whom? Not by DRBD. > > > <SNIP> Note, unless '-x' is passed to NTPD, with an offset of 8 > hours ntp will "jump" the time about 8 to 10 minutes[1] in after > it detects the large offset, it will also do this anytime there > is more than 128ms offset. '-x' 'forces the time to be slewed > in all cases.'[2] > > > So Lars, should we expect bad things to happen if the jump is > over 6 seconds in one direction or another? No. As I said, this *should* go unnoticed. After smoking some psychedelic stuff, I might be able to imagine a race condition which could lead to connection loss and immediate reconnect under very weird circumstaces... I'd of course deny that when sober ... > [Jump forward should expire the timer early in wall time] [Jump > back should expire the timer 'jump time delta' later in wall > time] I have seen X (or rather X apps) do funny things when you > set the system time backward while it is running, like not > updating screens. Hm. Under very weird circumstances, it might take longer to recognize a broken link or crashed peer. But not more than an other iteration of the "hey, peer, do you copy? /yes, peer here, whats up?/ ..." game... which happens with an offset to "now" after every successfull transmitted/received packet, unless some other packet is tx/rx earlier, in which case the game it defered further. but always relative to "now"... But, ok, many if not all timers used by the kernel may under certain conditions behave "strange" when the time is not monotonously increasing, including the network internal timers, and maybe even some hardware related stuff... Lars Ellenberg