Problem with time.time() standing still

[Roel Schroeven]

Hi Bob,

This reminds of a problem we had at work some years ago. I've followed
the thread from the beginning, but I hadn't a clue about what could
possibly cause the problem until you said:

Bob Cowdery schreef:
> Hopefully somebody can add the last piece of this puzzle. My code didn't 
> work because I did make a silly mistake. The number of seconds since 
> EPOC is a large number but it also needs a high precision. Attempting to 
> put this value into a 32 bit float corrupts the least significant part 
> because 24 bits  cannot hold that precision. Now Python floats are C 
> doubles and the calculation in timemodule.c is in doubles right back to 
> Python. Normally this retains the precision. For some inexplicable 
> reason when I make certain calls into this vendors SDK, ftime()  is 
> getting precision problems and appears to be frozen as a result.

Our problem turned out to be caused by a loss of precision in an
application of ours, caused by Direct3D. The solution for us was to
include the flag D3DCREATE_FPU_PRESERVE in CreateDevice(). The
documentation seems to imply that the lower precision only has effect in
the Direct3D code, but in reality it lowers precision in the rest of the
code too (the whole process or the whole thread, I'm not sure).

In your case it seems harder to solve: as far as I understand, the
trigger is somewhere in the vendors SDK, which you have no control over.
I'm afraid I don't know what you can do about that.

Best regards,
Roel

-- 
"The reasonable man adapts himself to the world. The unreasonable
man persists in trying to adapt the world to himself. Therefore,
all progress depends on the unreasonable man."
         -- George Bernard Shaw

roel at roelschroeven.net
http://roelschroeven.net