@flabdablet said:
@jes said:
I see nothing broken in a design which uses timestamps
to determine if an update is applicable to a record.
Then I hope nobody ever puts you in charge of a project sensitive to event ordering.
Well, since you know everything, then you'll know that I have done exactly that, did use NTP and the project was quite successful - the software I developed remained in production for over 12 years
@flabdablet said:
@jes said:
Ntp is an excellent method for synchronising a collection of services across multiple machines
Doesn't matter how good NTP is, or how good the network is; there will always be some residual uncertainty in the clock sync, and that uncertainty will always give rise to race conditions. Timestamps are simply the wrong tool for keeping track of event ordering.
Those of us who actually practice software engineering are aware of both the practicalities and the limitations. If events which have to be distinguished by ordering[[ are known to occur at intervals greater than the uncertainty of ntp synchronised clocks, then NTP is an excellent solution. If not, then a competent developer will not use NTP.
@flabdablet said:
@jes said:
why add inordinate complexity and a multitude of failure modes in trying to have systems to issue sequence numbers.
If you seriously believe that sequence numbering solutions like Lamport timestamps or even vector clocks are more complicated than NTP, then I'm afraid you are TRWTF.
Honestly, some days I wonder why computer scientists bother inventing round wheels when there are so many developers who cling so lovingly to their self-invented square ones.
Sometimes I wonder why arrogance seems to be a requirement for aspiring developers. More experienced ones learn their trade and select the tools to fit the requirements, both present and expected future ones.
Yes, I do believe that where ntp's resolution is sufficent to meet requirements (and snoofle's original posting did not suggest that it wasn't), then using a well engineered, well understood, widely deployed system which is available on most platforms, requires nothing more than simple configuration to set up and keep running and provides a reliable, quite reasonably accurate clock easily accessible within most programming languages sounds like a good idea. That there are other techniques available is not in dispute. That they are more complicated to integrate into a software system seems to me to be likely to be true. Neither of the techniques you mention are embedded at the lowest level of support libraries, their use will require significant intrusive changes in every application which forms part of the system. Gettimeofday() and its equivalent are available and require trivial work to incorporate.
But of course, you had to make your unfounded claims in the hopes you would demonstrate a wider knowledge of systems than someone who posted a quite reasonable response and who may in fact, have an equal level of knowledge to yours without the encumberance of a vastly inflated ego.