rotor alternative?

[Bengt Richter]

On Thu, 20 Nov 2003 19:02:59 -0500, Peter Hansen <peter at engcorp.com> wrote:

>Paul Rubin wrote:
>> 
>> Peter Hansen <peter at engcorp.com> writes:
>> > The docs for Py2.3 say:
>> > """On Windows, this function returns wall-clock
>> >    seconds elapsed since the first call to this function, as a floating
>> >    point number, based on the Win32 function QueryPerformanceCounter().
>> >    The resolution is typically better than one microsecond. """
>> >
>> > I wonder if the part about "since the first call to this function" would
>> > make this dangerous for your purposes.
>> 
>> I don't run Windows and don't want to use something Windows specific.
>> Although, "since the first call to this function" is probably ok.  All
>> that's needed is to get a unique number to initialize the internal
>> PRNG with.  Hopefully sometime, the Python library will include a C
>> extension to get secure random numbers from the Windows Crypto API.
>> On *nix, they are already generally available from /dev/urandom.
>
>It just struck me that if it's the first call to the function during
>a given program invocation which matters (as opposed to during a power-on 
>cycle of the whole PC), then it seems possible that you'll get exactly the 
>same valueeach time you call it if it's called only once by the program.
>
Ugh, you're right:
====< firsttimes.py >=======
import time
c = time.clock()
t = time.time()
print c,t
============================


[16:27] C:\pywk\ut\crypto>firsttimes.py
1.25714266558e-005 1069374432.09

[16:27] C:\pywk\ut\crypto>firsttimes.py
1.25714266558e-005 1069374437.29

[16:27] C:\pywk\ut\crypto>firsttimes.py
1.25714266558e-005 1069374445.84

[16:27] C:\pywk\ut\crypto>firsttimes.py
1.25714266558e-005 1069374449.78

[16:27] C:\pywk\ut\crypto>firsttimes.py
1.17333315454e-005 1069374454.33

Why'd they do that? On my platform it ought to go back to either to the rdtsc pentium
instruction, which reads a 64-counter of CPU cycles since power on (I assume it
starts from zero) or maybe to the clock chip time counter, which is probably ~55ms/2**16 or so
resolution. But this looks like python gets and stores a value on _python_ startup
as a reference.

Well, at least the least significant bits ought to be fairly random after some time
has gone by. Hm, ... except that NT scheduling may group sampling towards the beginning
of the 10-ms slice times anyway. Phooey. Sorry Paul, I didn't realize it was re-zeroed like that.

Regards,
Bengt Richter