Howdy!
Actually clock synchronization is quite tough job when one needs
sub-millisecond acuracy. Here's output of one host:
$ ntpq -pn
remote refid st t when poll reach delay
offset jitter
==============================================================================
10.101.10.189 10.13.4.30 2 u 70h 1024 0 0.216
-0.477 0.000
+10.101.10.188 10.13.4.30 2 u 569 1024 377 0.285
-2.188 0.208
*10.101.10.168 172.25.2.3 2 u 403 1024 377 0.210
-1.147 0.094
+10.13.4.168 10.101.10.188 3 u 339 1024 377 5.583
-3.031 2.734
-10.101.10.97 10.101.10.188 3 u 525 1024 377 0.223
-1.086 0.014
-10.13.4.1 10.101.10.1 3 u 301 1024 377 0.257
-8.948 4.490
-10.101.10.1 10.13.4.30 2 u 511 1024 377 0.706
4.535 9.706
All of hosts are on one LAN (VLAN segmented) and you can see that delay
and jitter wildly differ between different NTP servers. Alas, it's
offset that matters: it varies in order of several milliseconds which is
simply too much if one wants to measure delay of the same order of
magnitude.
Peace!
Mkx
-- perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
-- echo 16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D4D465452snlb xq | dc
------------------------------------------------------------------------
BOFH excuse #42:
spaghetti cable cause packet failure
Aaron Brown wrote:
I'm not sure if you've looked into it, but there's another tool,
OWAMP, that can be used to measure delay, jitter and packet loss
unidirectionally ( http://www.internet2.edu/performance/owamp/ ). The
thing with unidirectional packet measurement is that the hosts need to
have their clocks well synchronized since the method for calculating
one-way delay is to take a timestamp on the sender, and take a
timestamp on the receiver and compare the two. Configuring NTP on both
hosts to synchronize against 4 different good NTP servers is usually
adequate for making sure the hosts are reasonably well synchronized.
There are a load of other things that can affect the precision of
timings (how good the clocks are, what other software is running on
the host, etc), but having synchronized clocks is probably good enough
for basic measurements of delay/jitter/loss.
Cheers,
Aaron
On Dec 3, 2009, at 10:34 AM, Tobi Hofer wrote:
Hello together
I have some problems with the Delay, Jitter from Iperf.
How does Iperf calculate the Jitter Delay? When I measure with UDP
the Jitter
Delay over a 100Mb-Ethernet, the results are ok (avg delay: 124us,
avg jitter
31us).
I'm on my Bachelor-Thesis and I have to measure the Delay, Jitter and
Packet
loss ratio over a PPP-Device (3G) to a Server in the Internet in both
ways,
up- and downlink.
Iperf UDP downlink, 1800k (no loss):
avg Delay: 8.35ms
avg Jitter: 0.43ms (standard deviation).
When I variate the bitrate, the change is about 1 or 2ms.
This result can't be correct, because with thrulay the udp delay is
avg 75ms.
With NDT I have an avg RTT 1142ms
After Internet research the Delay over 3G is between 70ms.....180ms
How does Iperf calculate the Delay? Is it a problem over 3G UMTS?
I work with Iperf 2.0.4-4 for UDP, on the computers is Ubuntu 9.04
installed.
Thanks
Regards
Tobias
------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
<mailto:Iperf-users@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/iperf-users
Winter 2010 ESCC/Internet2 Joint Techs
Hosted by the University of Utah - Salt Lake City, UT
January 31 - February 4, 2010
http://events.internet2.edu/2010/jt-slc/
<http://jointtechs.es.net/indiana2009/>
------------------------------------------------------------------------
------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
------------------------------------------------------------------------
_______________________________________________
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users
--
Peace!
Mkx
-- perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
-- echo 16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D4D465452snlb xq | dc
------------------------------------------------------------------------
BOFH excuse #87:
Password is too complex to decrypt
------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users
