calling functions at the same time

T

Tim Sharpe

Peter Hansen said:
The last sentence is really the whole point. The OP needs
to be aware that the accuracy *cannot* be *guaranteed*
to better than "tens of milliseconds", overall, regardless
of the "accuracy" of the clock tick or the resolution of
anything...
As a network geek who writes crude software to test problems, I wonder
if we're not getting overly hung up on "exact". My experience shows
that, outside of bulk transfers running at least tens of megabits per
second, network delays don't become noticeable until round-trip delays
in the range 100mS or greater are observed (there's a wealth of
Internet documentation on "bandwidth-delay issues" that well cover the
impact of delay on performance of TCP-based applications). This would
appear to indicate that the above numbers (tens of milliseconds) may
be quite reasonable if the intent is to identify operational problems,
vice academic interest. To troubleshoot problems that occur with
delay deltas less than about 25mS, you're going to be into those
$100,000+ software packages that rich folks use to model traffic
patterns, that is if you want anything meaningful.

For this kind of accurancy, it should be reasonable to create a
multithreaded program, spawn the worker threads (they'll do the actual
pinging) in advance, then use queues (see Aahz's great threading
tutorial at http://starship.python.net/crew/aahz/OSCON2000/TOC.HTM) to
activate the workers to ping each host. This would seem to get as
close to a simultaneous start and operation as practical. The trick
would be to make sure that your Ping code runs thread safe and that
you use unique numbers in the ICMP "indentifier" field, or your code
can't tell which ICMP packet belongs to which thread (it may still be
tough).

If you really need more accuracy, then your best bet is to use libpcap
(or winpcap for Windows, see http://www.tcpdump.org), as it provides
packet timestamps that I've found to be accurate to fractions of
milliseconds. You could spawn Pings, capture them with libpcap, then
decode the libpcap packet header to extract the timestamp.

Ok, not a great answer, but it really depends on the desired result of
the program. Less accuracy may well do the job.

Tim
 
P

Peter Hansen

Tim said:
Peter Hansen said:
The last sentence is really the whole point. The OP needs
to be aware that the accuracy *cannot* be *guaranteed*
to better than "tens of milliseconds", overall, regardless
of the "accuracy" of the clock tick or the resolution of
anything...

As a network geek who writes crude software to test problems, I wonder
if we're not getting overly hung up on "exact". [snip]
If you really need more accuracy, then your best bet is to use libpcap
(or winpcap for Windows, see http://www.tcpdump.org), as it provides
packet timestamps that I've found to be accurate to fractions of
milliseconds.

Tim, you're quite right of course. I think many of us were just
sort of caught up in the fun of trying to show the OP how futile
his attempt at "exact and simultaneous" timing really was.

Someone really needed to come along and give some useful practical
advice instead, and you're that guy. :)

-Peter
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,733
Messages
2,569,440
Members
44,832
Latest member
GlennSmall

Latest Threads

Top