Hi there!
Today, we had some problems on a server (running gemstone) where the system clock was being synchronized. There was a deviation of +- 20 minutes and when we (re)activated the ntp process to (more or less) gently get the system clock back on track, we had some gems crashing and failing to restart without error warnings. When the clock was back on track, everything started running smoothly again. I cannot see any lasting problems at this time. Everything is running fine and the stones are not reporting any errors. Are there known guidelines when using an NTP-controlled slowing down of the system clock when running Gemstone? It was probably better to shutdown all stones before doing that? Is there anything specific I want to check now to ensure everything is running fine? thanks! Johan |
It seems that some mail that I intended responding to went into a black hole and with the move to GemTalk Systems, I have uncovered this little treasure trove:)
So Johan, Here's Martin's (timely) response: The only possibility I can immediately think of is that when NTP is slowing down the realtime clock, a nanosleep can return early, or at least at a time that appears early relative to the realtime clock. If we have any code that does nanosleep(n) for, and relies on the system clock advancing by at least n nanoseconds while sleeping, this could cause a problem. This might also apply to things like timeout values on poll(). -Martin Dale ----- Original Message ----- | From: "Johan Brichau" <[hidden email]> | To: "GemStone Seaside beta discussion" <[hidden email]> | Sent: Friday, September 14, 2012 10:40:15 AM | Subject: [GS/SS Beta] system clock sensibility of gemstone? | | Hi there! | | Today, we had some problems on a server (running gemstone) where the | system clock was being synchronized. | | There was a deviation of +- 20 minutes and when we (re)activated the | ntp process to (more or less) gently get the system clock back on | track, we had some gems crashing and failing to restart without | error warnings. | | When the clock was back on track, everything started running smoothly | again. I cannot see any lasting problems at this time. Everything is | running fine and the stones are not reporting any errors. | | Are there known guidelines when using an NTP-controlled slowing down | of the system clock when running Gemstone? | It was probably better to shutdown all stones before doing that? | Is there anything specific I want to check now to ensure everything | is running fine? | | thanks! | Johan |
haha, thanks guys :-)
In the meantime, I discovered that it's not only Gemstone that has problems with NTP syncing the clock when there is a large drift. In essence, many processes (like for example the top application) also freeze. I have taken the precaution to execute this kind of syncs only in quite hours, which is perfect. On 16 May 2013, at 19:11, Dale K. Henrichs <[hidden email]> wrote: > It seems that some mail that I intended responding to went into a black hole and with the move to GemTalk Systems, I have uncovered this little treasure trove:) > > So Johan, Here's Martin's (timely) response: > > The only possibility I can immediately think of is that when NTP is > slowing down the realtime clock, a nanosleep can return early, or at > least at a time that appears early relative to the realtime clock. If we > have any code that does nanosleep(n) for, and relies on the system clock > advancing by at least n nanoseconds while sleeping, this could cause a > problem. > > This might also apply to things like timeout values on poll(). > > -Martin > > Dale > > ----- Original Message ----- > | From: "Johan Brichau" <[hidden email]> > | To: "GemStone Seaside beta discussion" <[hidden email]> > | Sent: Friday, September 14, 2012 10:40:15 AM > | Subject: [GS/SS Beta] system clock sensibility of gemstone? > | > | Hi there! > | > | Today, we had some problems on a server (running gemstone) where the > | system clock was being synchronized. > | > | There was a deviation of +- 20 minutes and when we (re)activated the > | ntp process to (more or less) gently get the system clock back on > | track, we had some gems crashing and failing to restart without > | error warnings. > | > | When the clock was back on track, everything started running smoothly > | again. I cannot see any lasting problems at this time. Everything is > | running fine and the stones are not reporting any errors. > | > | Are there known guidelines when using an NTP-controlled slowing down > | of the system clock when running Gemstone? > | It was probably better to shutdown all stones before doing that? > | Is there anything specific I want to check now to ensure everything > | is running fine? > | > | thanks! > | Johan |
Free forum by Nabble | Edit this page |