«

In article <kNIkc.1367$U75.564@edtnps89>, Knio 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():

import time
t = []
for i in range(10):
t.append(time.time())
print t

[1083429542.284164, 1083429542.2841799, 1083429542.2841859,
1083429542.2841921, 1083429542.284198, 1083429542.284204,
1083429542.284209, 1083429542.284215, 1083429542.2842209,
1083429542.2842269]

The Linux network stack also provides timestamps on the network
packets with at least 1us resolution.

> calling 4 ping functions one after the other will complete in much less
> then 1ms (assuming its asynchronous, or threaded). So, even if you could
> manage to send 4 packets at *exactly* the same time,

People, Ethernet is a _serial_ protocol. It allows exactly one
packet to be transmitted at a time. There is no way to send
more than one packet at a time.

> it would be no more accurate.

--
Grant Edwards grante Yow! As President I
at have to go vacuum my coin
visi.com collection!

Grant Edwards wrote:

> In article <kNIkc.1367$U75.564@edtnps89>, Knio 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 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.

-Peter

In article <r4idnSA-J8HtSw7dRVn->, 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.

--
Grant Edwards grante Yow! It's today's SPECIAL!
at
visi.com

Grant Edwards wrote:
> In article <r4idnSA-J8HtSw7dRVn->, 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

"Bart Nessux" <> wrote in message
news:c6unuq$d0f$...
> Cameron Laird wrote:
>
> > In article <c6udda$qpv$>,
> > bart_nessux <> wrote:
> >>I need a script to call several functions at the same time. How does one
> >>call more than one function simultaneously?
> >>
> >>
> >>
> >
> > This has several smart-alecky answers, including "you don't",
> > and "with co-routines". The best way you can help yourself is
> > to describe a concrete situation where your (Python?) script
> > has a need to call even two functions simultaneously.
>
> I need to ping 4 hosts at exactly the same time from the same machine (I
> plan to timestamp the pings) to test and measure network conditions over
> different routes to different hosts. Putting all the ping hosts in a list
> and looping through it is not a fair or balanced way to do this because of
> the time differences.
>
The network guy in me says that pinging 4 machines at the same time from 1
machine is not fair and
balanced. your network card really only does 1 request at a time... I would
think that the only fair judge
is to do it on 4 machines on the same segment, or 4 cards in the same
machine, otherwise you're bottleneck
becomes the single network card..
My opinion...
bobb

>
>
> > It turns
> > out "simultaneously" has a plethora of meanings, and you're the
> > only one in a position to get others to understand which you
> > have in mind.
>
> I mean it to mean: at the *exact* same time... concurrently. Like runners
> starting a race together.
>
> >
> > It'll also help to know whether you mean "function" as specific
> > to the Python language, or more abstractly, as a unit of useful
> > accomplishment.
>
> Specific to Python.

Grant Edwards wrote:

> In article <r4idnSA-J8HtSw7dRVn->, Peter Hansen wrote:
(Someone else wrote this first part, then Grant's reply, then mine)
>>>>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.

[snip other technical details]

> As soon as there are other ready tasks, the accuracy of the
> measurement quickly deteriorates to tens of millisconds due to
> scheduling latencies.

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...

The notes on timeit.py are helpful in this respect, however:
taking the shortest result of repeated measurements is a
pretty good way to get an "accurate" number, most of the
time. The other, higher results represent the interference
of all those other tasks which will tend to run as you
try to take measurements.

-Peter

Grant Edwards wrote:
> In article <kNIkc.1367$U75.564@edtnps89>, Knio 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():
>
> [snip]

ah, interesting.. on my windows machine (pentium 4) I only have a 1ms
timer resolution.

import time
t = []
for i in range(10):
t.append(time.time())
print t

[1083451302.5739999, 1083451302.5739999, 1083451302.5739999,
1083451302.5739999, 1083451302.5739999, 1083451302.5739999,
1083451302.5739999, 1083451302.5739999, 1083451302.5739999,
1083451302.5739999]

Bart Nessux <> writes:

> I mean it to mean: at the *exact* same time... concurrently. Like runners
> starting a race together.

On how many processors? You need to tell your operating system
services to schedule the two python funtion calls to each processor
simultaneously. I don't think anything in Python will let you do that.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

At 2004-04-30T23:43:37Z, Bart Nessux <> writes:

> I need to ping 4 hosts at exactly the same time from the same machine (I
> plan to timestamp the pings) to test and measure network conditions over
> different routes to different hosts. Putting all the ping hosts in a list
> and looping through it is not a fair or balanced way to do this because of
> the time differences.

In other words, you want to emulate the functionality of fping without using
fping. Is that about right?
- --
Kirk Strauser
The Strauser Group
Open. Solutions. Simple.
http://www.strausergroup.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAlRaz5sRg+Y0CpvERAt8xAJ4sS+FzCv/Bm57o2b3s3Weh2yTV3gCeM68p
JVstKJijYWIQxU9+izWk7hQ=
=zCda
-----END PGP SIGNATURE-----

Bart Nessux wrote:
> I need to ping 4 hosts at exactly the same time from the same machine (I
> plan to timestamp the pings)
>
> I mean it to mean: at the *exact* same time.

Unless your machine has 4 network interfaces, there's no
way you're going to get the pings sent out at *exactly*
the same time...

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg