Hi, I noticed that the convention in Twisted is to measure time with python.runtime.seconds. This in turn uses time.time which is sensitive to the system clock, meaning that it may return decreasing values if the user sets the system clock to an earlier time between calls. This would likely break many things, no? Why not use time.clock or some combination between them? Antony Kummel ______________________________________________________ Click here to donate to the Hurricane Katrina relief effort. http://store.yahoo.com/redcross-donate3/
On 9/5/05, Antony Kummel <antonykummel@yahoo.com> wrote:
Hi,
I noticed that the convention in Twisted is to measure time with python.runtime.seconds. This in turn uses time.time which is sensitive to the system clock, meaning that it may return decreasing values if the user sets the system clock to an earlier time between calls. This would likely break many things, no? Why not use time.clock or some combination between them?
Seems to me that using the same clock as the rest of the system is the single best way to ensure that other logs and Twisted's logs agree on the time stamp. Just imagine the nightmare if there was an issue pointed to by the twisted log, but since it was "correct" it couldn't be directly matched up with another system log that actually pointed to the source of the problem. This has actually proven to be quite useful for me. -- "Things fall apart. The Center cannot hold." - Life as a QA geek, in a nutshell. Best, Jeff
--- Jeff Grimmett <grimmtooth@gmail.com> wrote:
On 9/5/05, Antony Kummel <antonykummel@yahoo.com> wrote:
Hi,
I noticed that the convention in Twisted is to
time with python.runtime.seconds. This in turn uses time.time which is sensitive to the system clock, meaning that it may return decreasing values if
user sets the system clock to an earlier time between calls. This would likely break many things, no? Why not use time.clock or some combination between
measure the them?
Seems to me that using the same clock as the rest of the system is the single best way to ensure that other logs and Twisted's logs agree on the time stamp.
Just imagine the nightmare if there was an issue pointed to by the twisted log, but since it was "correct" it couldn't be directly matched up with another system log that actually pointed to the source of the problem.
This has actually proven to be quite useful for me.
For logging, I agree, but the system clock is used for many purposes, among them, for example, the mechanics of LoopingCall, or the reactor's scheduling of delayed calls, I think (please correct me if I'm wrong). So it seems to me that while an application that uses the current method may produce more useful logs but it will also exhibit undefined behavior regarding the rest of its functionality, no? Antony Kummel __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On 9/5/05, Antony Kummel <antonykummel@yahoo.com> wrote:
For logging, I agree, but the system clock is used for many purposes, among them, for example, the mechanics of LoopingCall, or the reactor's scheduling of delayed calls, I think (please correct me if I'm wrong).
Your pardon; for some reason I read "logging" in your post when it wasn't there. It's been a long weekend :-) -- "Things fall apart. The Center cannot hold." - Life as a QA geek, in a nutshell. Best, Jeff
On Mon, 5 Sep 2005 03:09:42 -0700 (PDT), Antony Kummel <antonykummel@yahoo.com> wrote:
Hi,
I noticed that the convention in Twisted is to measure time with python.runtime.seconds. This in turn uses time.time which is sensitive to the system clock, meaning that it may return decreasing values if the user sets the system clock to an earlier time between calls. This would likely break many things, no? Why not use time.clock or some combination between them?
Twisted provides no real-time guarantees. The reliance on time.time() to return sensible results is just one aspect of this. If you're worried about scheduling in your application, you'll probably see more problems come up from Linux context switches, blocking syscalls (including disk I/O), system load, slow Python functions, Python's garbage collector, and user interference. Clock skew just doesn't come up much in practice, at least on any of the systems I run code on (NTP is your friend). Jp
On Mon, 5 Sep 2005 03:09:42 -0700 (PDT), Antony Kummel <antonykummel@yahoo.com> wrote:
I noticed that the convention in Twisted is to measure time with python.runtime.seconds. This in turn uses time.time which is sensitive to the system clock, meaning that it may return decreasing values if the user sets the system clock to an earlier time between calls. This would likely break many things, no? Why not use time.clock or some combination between them?
time.clock() is unfortunately useless due to differences in its behavior between different platforms:
import time; help(time)
Help on built-in function clock in module time: clock(...) clock() -> floating point number Return the CPU time or real time since the start of the process or since the first call to clock(). This has as much precision as the system records. "CPU time" has absolutely nothing to do with "real time" and so using clock() to measure anything at all is pointless; its behavior is completely different between platforms. There are other problems with time, too: it should return an integral number of milliseconds; the fact that it uses a float means that systems which cause the FPU to truncate double-precision floating point operations at single-precision (like DirectX) won't work at all with Twisted. Basically, in order to provide a truly correct implementation of time, Twisted would need its own re-implementation of the 'time' and 'select' modules from the python standard library, as well as for all 3rd-party multiplexing and GUI libraries to take a different signature (since the convention is to use floats for time in Python) and nobody has yet had the time. Clock skew is one of the easier issues to address; we just need an API to portably report a monotonically increasing real time in floating-point seconds, and for all the reactors to use it. Patches accepted :).
participants (4)
-
Antony Kummel -
glyph＠divmod.com -
Jeff Grimmett -
Jp Calderone