calling functions at the same time

[bart_nessux]

Grant Edwards wrote:
> In article <r4idnSA-J8HtSw7dRVn-hQ at powergate.ca>, Peter Hansen wrote:
> 
> 
>>>>You can't get greater then 1ms accuracy when measuring a time
>>>>on todays machines, and that will be less when measuring time
>>>>over a network...
>>>
>>>Not sure what you mean by "todays machines", but on a
>>>Pentium-class machine running Linux, you get approx 1us
>>>resolution with calls to time.time():
>>
>>Keep in mind the difference between "accuracy" and
>>"resolution" (or "precision").
> 
> 
> I do.
> 
> Not only do you get 1us resolution, you get packet timestamp
> _accuracy_ to well under 1ms according to tests I've run 
> comparing packet timestamps against an oscilloscope trace.
> 
> Delta-T accuracy of calls to time() are accurate to 1us as
> well.  Absolute accuracy depends on how you set your system
> clock.  Running NTP with in-kernel FLL control of the system
> tick will generally allow you to maintain absolute accuracies
> of under 100us.
> 
> 
>>I think Knio is probably right that, unless you are running on
>>a realtime OS, you won't be able to guarantee anything better
>>than 1ms accuracy, and quite probably not even that.
> 
> 
> Under Linux, I can guarantee you the answer you get back from
> time.time() is accurate to 1us.  However, it is a multitasking
> system, and there are other things running.  While it's easy to
> _determine_ exactly when you called time.time(), it's difficult
> to _control_ the point in time when you call time.time(). When
> your task does get a chance to run, and you do get to call
> time.time(), you'll generally get a result accurate to 1us.
> 
> If I do a busy-wait loop with nothing else running, I've been
> able to accurately measure pulsewidths of a few microseconds
> under Linux using the gettimeofday() call (which I believe is
> what time.time() calls.
> 
> As soon as there are other ready tasks, the accuracy of the
> measurement quickly deteriorates to tens of millisconds due to
> scheduling latencies.
> 

Thanks to all for the tips and advice. I experimented with threading... 
it works, but I don't fully understand it so I'm not using it. I ended 
up using ntp on 4 hosts (side by side on the network) to do the pings. I 
wrote some socket server/client scripts so that all four hosts can start 
pinging together. I understand this approach and it's working well.

Thanks again,
Bart