Light Speed Socket Connections

[Bengt Richter]

[T Angell]
>I wrote some code to test how long it takes to make socket connections
>and ran it against several hosts around the world, here are some
>sample times:
>
>socket time: 0.0047459602356
>socket time: 0.00469899177551
>socket time: 0.00404000282288
>socket time: 0.00537407398224

[Bengt]
>For accurate timing, time.clock()
>is recommended, I believe:

[Skip Montanaro]
>Not in this case.  He wants to know how long it takes the socket to be
>connected between the two machines.  That is an elapsed time sort of thing,
>what you measure with time.time.  It has little or nothing to do with the
>CPU time used by the client process making the connection.

[Steve Holden]
>> Well, after this little experiment on PythonWin 2.0/Win95 I'm no longer
>sure what is going on:
>
>>>> for i in range(10):
>...  time.sleep(2.5)
>...  print time.time(), time.clock()
>...
>994956779.3 5.86667560636e-006
>994956781.88 2.55270956603
>994956784.41 5.0637313733
>994956786.94 7.58865720176
>994956789.41 10.1181121038
>994956791.99 12.6327050403
>994956794.46 15.1421897786
>994956796.99 17.6518547076
>994956799.51 20.1890552976
>994956802.04 22.7061055331
>
>Is my CPU usage really ~100% during those sleeps?

It all becomes clearer referring back to an old post by
the usual authority ;-) (See appended below).

The upshot is that windows and unix apparently don't access
the same clock() even on identical intel pentium hardware
boxes. For timing algorithms that seems less than ideal.
IMHO there ought to be a platform-independent way to access
the best tick counter available.

I feel another bout of idearrhea coming on ... ;-)
More on that later. Here's the old post (hope no one minds):
___________________________________________________
On Fri, 20 Apr 2001 01:38:25 -0400, "Tim Peters" <tim.one at home.com> wrote:

>[Les Schaffer]
>> i am talking to some hardware, needing to resolve 10's-100's of msec
>> of time. So I started playing around with the clock and GetTickCount
>> functions under win32 to check for finer time resolution.
>>
>> See code below. timimg results for win2k at:
>>
>>   http://folks.astrian.net/godzilla/ticks.html
>>
>> GetTickCount has some funniness in its behavior.
>>
>> i'm good and stickin with clock for now. But I am curious to hear
>> other people's observations about msec time resolution or possibly
>> even smaller, particularly on winXX and linux.
>
>GetTickCount is a legacy API; its resolution varies across systems, but is
>never better than 10ms, and is as coarse as 55ms on Win9X.
>
>Python on Windows uses the QueryPerformanceCounter API for time.clock(),
>thanks to Mark Hammond.  How good that is (indeed, whether it even exists!)
>depends on your platform.  On my home box, it updates 1,193,180 times per
>second (use QueryPerformanceFrequency to get your magic number -- it will
>probably be the same if you're running on a Win9X Pentium).  So ms resolution
>is a yawn for it.  BTW, you'll find the hardcoded number 1193180 in
>winsound.c too:  this isn't a coincidence <wink>.
>
>clock() on Linux returns CPU time, not wall-clock time.  I don't remember
>what its resolution is, but you won't like it.  time.time() may or may not be
>better for you there (across Unix flavors, it varies from microsecond to
>full-second resolution; on Win9X it's something bizarre, *appearing* to be
>10ms unless you look very carefully and notice it's only updated 18.2 times
>per second).
>
>In any case, don't mistake resolution for accuracy.  You didn't ask about
>accuracy <0.5 wink>.
>
>for-more-on-that-do-a-google-search-ly y'rs  - tim
>
>
__________________________________________________