UDP Network Delay Data
Le Chaud Lapin
I am looking for sample data on unidirectional inter-node delay using
UDP.
Ideally, someone would have set up highly-synchronized clocks between
source and target to measure the actual uni-directional delay. If I
may continue to be greedy, s/he would have done this independently in
both directions: source-to-target and target-to-source, with a
sufficient diversity of intermediate nodes between source and target
for a large swath of Internet. [Data for nodes confined within same
LAN would not be useful.]
The process does not have to be wide-sense stationary, nor do I need
data for multiple nodes, but something "representative" would be good.
I need the data to test a stochastic estimator.
TIA,
-Le Chaud Lapin-
mockturtle
> Hi All,
>
> I am looking for sample data on unidirectional inter-node delay using
> UDP.
My best wishes of good luck... Few years ago I searched for some
sample data about packet loss ratio over UDP, but with no luck (I was
working on technique for reliable transmission). Did you consider
using PlanetLab (http://www.planet-lab.org/)? If you work in a non-
profit organization (e.g., university), you could have your
institution joining PlanetLab almost for free (2 new nodes ~ 6000$,
according to my latest estimate) and you could setup the test by
yourself.
By the way, if I may ask, do you need "absolute" delay values or are
you more interested in the variability of the delays? (In the latter
case a constant difference in absolute time between the two "clocks"
would not matter).
Le Chaud Lapin
> On Nov 21, 6:53 am, Le Chaud Lapin <jaibudu...@gmail.com> wrote:
> > I am looking for sample data on unidirectional inter-node delay using
> > UDP.
>
> My best wishes of good luck... Few years ago I searched for some
> sample data about packet loss ratio over UDP, but with no luck (I was
> working on technique for reliable transmission). Did you consider
> using PlanetLab (http://www.planet-lab.org/)? If you work in a non-
> profit organization (e.g., university), you could have your
> institution joining PlanetLab almost for free (2 new nodes ~ 6000$,
> according to my latest estimate) and you could setup the test by
> yourself.
Ha! I am working on the same thing - retransmission.
It is my Passion Project that I do in my free time, so cannot use
PlanetLab or similar. I was very surprised at how hard it is to find
large sets of sample data. One would think that there would be not
only data sets, but PDF curves of real data, so we could compare
between hypothesis and actual.
> By the way, if I may ask, do you need "absolute" delay values or are
> you more interested in the variability of the delays? (In the latter
> case a constant difference in absolute time between the two "clocks"
> would not matter).
I was thinking of this. In steady state, arrival rate and variance
could be estimated. I figured real data would not hurt, because I
would still like to see how well it compares with various hypothesized
PDF's for inter-node delay put forth by researchers.
I am curious about your research, if you are able to talk about it.
Very exciting stuff!
-Le Chaud Lapin-
Jorgen Grahn
> On Nov 21, 6:53�am, Le Chaud Lapin <jaibudu...@gmail.com> wrote:
>> Hi All,
>>
>> I am looking for sample data on unidirectional inter-node delay using
>> UDP.
...
> By the way, if I may ask, do you need "absolute" delay values or are
> you more interested in the variability of the delays? (In the latter
> case a constant difference in absolute time between the two "clocks"
> would not matter).
If I recall correctly from some experiments I did years ago, if you
plot the delta between two system clocks over time, you may get a
sawtooth form -- one might run consistently slower than real time, and
jump forward to "catch up" now and then. This was on Linux, and I
can't recall what the time scale was (milliseconds or seconds between
the "teeth"?)
I know it botched my delay calculations, but they were just through
one router and I needed high resolution.
My point is: be careful with what you assume in this area. There are
more details in keeping time than what you would expect.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Le Chaud Lapin
I have to agree here.
After a few thought experiments yesterday, I cautiously backed off any
pretentions that I might be able to tame the time issues.
Instead, I will focus on those things that I can actually control or
make true assumptions of, which is not completely clear yet.
-Le Chaud Lapin-
Rick Jones
> I am looking for sample data on unidirectional inter-node delay
> using UDP.
Over what distance?
> Ideally, someone would have set up highly-synchronized clocks
> between source and target to measure the actual uni-directional
> delay. If I may continue to be greedy, s/he would have done this
> independently in both directions: source-to-target and
> target-to-source, with a sufficient diversity of intermediate nodes
> between source and target for a large swath of Internet. [Data for
> nodes confined within same LAN would not be useful.]
At one point I toyed with the idea of hacking netperf for one-way
latency measurements for two systems on a LAN, and even went as far as
exchanging posts with the NTP gurus in the ntp newsgroup
(comp.protocols.time.ntp? not sure).
In the course of that discussion, some papers about WAN one-way
latency measurements were brought-up, using I think, "PPS" (Pulse Per
Second) GPS devices at the endpoints - or perhaps they just synced to
> stratum 1 time servers and it was the LAN idea that brought PPS GPS
> into play. Anyhow, whatever they used, it got the time synchronized
"well enough" for the WAN. I don't recall that it would have been
synchronized "well enough" for the LAN, but I abandoned the idea after
taking a Garmin GPS 12 (perhaps not the best choice) into the machine
room where my systems would reside and finding no GSP signal
whatsoever.
rick jones
--
oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
Le Chaud Lapin
> Le Chaud Lapin <jaibudu...@gmail.com> wrote:
>
> > I am looking for sample data on unidirectional inter-node delay
> > using UDP.
>
> Over what distance?
France to USA would be representative for what we're trying.
> In the course of that discussion, some papers about WAN one-way
> latency measurements were brought-up, using I think, "PPS" (Pulse Per
> Second) GPS devices at the endpoints - or perhaps they just synced to> stratum 1 time servers and it was the LAN idea that brought PPS GPS
> > into play. Anyhow, whatever they used, it got the time synchronized
>
> "well enough" for the WAN. I don't recall that it would have been
> synchronized "well enough" for the LAN, but I abandoned the idea after
> taking a Garmin GPS 12 (perhaps not the best choice) into the machine
> room where my systems would reside and finding no GSP signal
> whatsoever.
Yes, the clocks would absolutely have to be syncrhonized. The lower
the transit delay, the greater the synchronization required.
-Le Chaud Lapin-
Rick Jones
Brest to New York, or Strasbourg to San Francisco?-)
If then you search comp.protocols.time.ntp for I guess posts by your's
truly, in that there one of the responses should have a pointer to the
papers discussing one-way WAN latency.
rick jones
--
portable adj, code that compiles under more than one compiler
Rob Warnock
+---------------
| Le Chaud Lapin <jaibu...@gmail.com> wrote:
| > France to USA would be representative for what we're trying.
|
| Brest to New York, or Strasbourg to San Francisco?-)
|
| If then you search comp.protocols.time.ntp for I guess posts by your's
| truly, in that there one of the responses should have a pointer to the
| papers discussing one-way WAN latency.
Even better, just run NTP between your endpoints, and look at the "delay",
"offset", and "dispersion" statistics that "ntpdc -p" gives you! ;-} ;-}
-Rob
p.s.
M. Lapin, if it's not obvious why Rick & I are suggesting you look at
NTP & the NTP literature, it's because: (1) NTP runs over UDP; and
(2) the NTP community has *lots* of experience with measuring [and
filtering] latency & jitter in UDP traffic over the public Internet.
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607