[Spread-users] Should I dare touch the clock?

[drago.krznaric at se.transport.bombardier.com]

Thanky you for prompt reply.  If I would like to try to use the monotonic 
clock, do you know if there
is some test suite I could use to see that things work after the change?
  
Please consider the environment before you print / Merci de penser à 
l'environnement avant d'imprimer / Tänk på miljön innan du skriver ut 






John Schultz <jschultz at spreadconcepts.com>
2009-05-08 17:50

To
Drago Krznaric/SE/Transport/Bombardier at TRANSPORT
cc
spread-users at lists.spread.org
Subject
Re: [Spread-users] Should I dare touch the clock?







Spread currently uses the wall clock time for all of its time based 
calculations.  If you only move the clock a little, then you probably 
won't have any issues, although I'm not 100% sure.  If you drastically 
jump the clock forward, then I can see major issues as suddenly the 
already scheduled timeouts will take forever to fire.  If you drastically 
jump the clock backwards, then a lot of timeouts will fire prematurely, 
which might cause a spurious partition or something, but the system would 
probably then return to normal operations immediately thereafter.

The events system definitely should be moved over to using a monotonic 
clock on whatever platforms such a service is available.  We would like to 
do this sometime in the future, but if you experiment with it and get 
something to work and want to contribute it back, then that would be 
great.

Cheers!
John

---
John Lane Schultz
Spread Concepts LLC
Phn: 443 838 2200 
Fax: 301 560 8875

Friday, May 8, 2009, 11:19:23 AM, you wrote:


>

Hi, 

I have a single spread daemon and a bunch of programs communicating via 
spread messages 
through this daemon. All programs and the daemon are running on the same 
machine. 

>From previous mails on this list, I know that people have had problems 
with message 
delivery when they have changed the clock, via settimeofday and even NTP. 

But I'm not sure if this can only occur when there are multiple daemons or 
if it can happen 
in my case too. Browsing through the code in events.c, it looks as it 
could happen in my case 
too, although the probability is perhaps small. 

Has someone a testprogram/argument proving that this is either true or 
false? 

I'm thinking about changing the gettimeofday call in E_get_time to 
something that is not 
affected by some external source setting the time, for example, 
clock_gettime(CLOCK_MONOTONIC). 

Has someone done something similar before? 

Cheers, 
Drago 








_______________________________________________________________________________________________________________ 

This e-mail communication (and any attachment/s) may contain confidential 
or privileged information and is intended only for the individual(s) or 
entity named above and to others who have been specifically authorized to 
receive it. If you are not the intended recipient, please do not read, 
copy, use or disclose the contents of this communication to others. Please 
notify the sender that you have received this e-mail in error by reply 
e-mail, and delete the e-mail subsequently. Please note that in order to 
protect the security of our information systems an AntiSPAM solution is in 
use and will browse through incoming emails. 
Thank you. 
_________________________________________________________________________________________________________________ 


Ce message (ainsi que le(s) fichier(s)), transmis par courriel, peut 
contenir des renseignements confidentiels ou protégés et est destiné à 
l?usage exclusif du destinataire ci-dessus. Toute autre personne est, par 
les présentes, avisée qu?il est strictement interdit de le diffuser, le 
distribuer ou le reproduire. Si vous l?avez reçu par inadvertance, 
veuillez nous en aviser et détruire ce message. Veuillez prendre note 
qu'une solution antipollupostage (AntiSPAM) est utilisée afin d'assurer la 
sécurité de nos systèmes d'information et qu'elle furètera les courriels 
entrants.
Merci. 
_________________________________________________________________________________________________________________ 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.spread.org/pipermail/spread-users/attachments/20090511/51c2c8c8/attachment.html