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

John Lane Schultz jschultz at spreadconcepts.com
Mon May 11 21:43:06 EDT 2009

No, not really.  One way you could test would be to see how normal Spread
reacts when you jump the clock around and then contrast that with how it
operates using your monotonic clock.



John Lane Schultz
Spread Concepts LLC
Phn: 443 838 2200 


From: drago.krznaric at se.transport.bombardier.com
[mailto:drago.krznaric at se.transport.bombardier.com] 
Sent: Monday, May 11, 2009 4:18 AM
To: John Schultz
Cc: spread-users at lists.spread.org
Subject: Re: [Spread-users] Should I dare touch the clock?


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 


Drago Krznaric/SE/Transport/Bombardier at TRANSPORT 


spread-users at lists.spread.org 


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. 


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

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



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

>From previous mails on this list, I know that people have had problems with
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

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,

Has someone done something similar before? 


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.

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

More information about the Spread-users mailing list