🚀 go-pugleaf

Vik,
neither of your posts to me made it to Dejanews. Someone was gracious
enough to send me a copy of your post and I've reponded here.

Vik wrote:
>mreid@rogers.wave.ca wrote:
>
>: I find that ICMP echoes CAN be used to show various trends. These
>: graphs show
>: what I would expect: Latency increases in such busy periods such as
>: from 10:00 -
>: 12:00, from 14:00 to 16:00 and from 18:00 to 01:00 .
>
>Yes, but these trends are valid only in one direction and for
>you.  Real throughput is dependent on router conditions, route loss
>patterns (which are asymmetric), and various other things
>which cannot effectively be measured from your site, including
>end-user stack configuration.  This is a very complicated issue
>and I do not feel that you should extrapolate anything
>from ping reports.  In essence, ping reports from one
>single site to another are of absolutely no value to anyone
>else.


In an academic and theoretical sense this may be true. Nothing can
be extrapolated from anything with any certainty. We can't extrapolate
tomorrows network performance from todays with any certainty for example.

In practice, when I see the latency time graphs for two ISPs
connected to the same network backbone by the same routers, and one
is very flat and low while the other is much higher and spiked,
I conclude  that the ISP with huge latency spikes PROBABLY has
a much lower general performance. I'm well aware that technically
this might be untrue, but I find it telling that the now deceased
Ottawa Public Net fared the worst in my tests, when they should
have had an advantage by being on iStar.

Infinite ping times for an extended period are also quite interesting.
When I see this happening, I make efforts to verify from various remote
systems that the ISP or site in  question is indeed down. Note that
this is not a single site observation.

>What statistical models and time-resolved samples of intermediate
>networks have you used to make adjustments to ping-times
>such that they reflect the reality of anyone's situation?

None.

>If you mean that you've just smoothed the figures by
>subtratcting intermediate delays and taking the time-averaged
>value, this hasn't really done anything.

I haven't done any such thing. These are just some initial and
apparently incorrect thoughts I've had. These points are moot
in any case as I acknowledge that distributed testing is much
more meaningful. Fine. I have no problem admitting when I am wrong.


>: intend to add such logic to my software although I acknowledge it's
>: not a simple
>: task and could require the dynamic traceroutes I've mentioned.
>
>It's not a simple task;  people at the DSL at my University
>routinely do theses on related topics.

Granted, nothing is simple. Have they written any code that is
publicly available ?


>: There are many different tools for many different purposes. I'm
>: familiar with
>: Bing and aware it does little more than ping two routers with
>: different size
>: ICMP packets. This provides a sometimes accurate bandwidth estimate,
>: but of
>: course there are many ifs, ands and buts... I've done the same thing
>: manually
>: with ping and some calculations. The T1 line to Rogers I use appeared
>: to vary
>: from 1.6 - 1.8 Mbits/s according to these calcs, when it's actually
>: 1.544
>: Mbits/s minus overhead.
>
>You are confusing bandwidth and single-user throughput.

I don't believe I'm the one who is confused about the differences
between bandwidth and throughput. I don't want to get picky about
terminology as we all use technically incorrect terminology sometimes.
As an example, it's been argued that the term multimedia is incorrect
and that multimedium would have been more proper. When confusion may or
does arise, I define my terms.

I define bandwidth as the total amount of data (bits, bytes, cycles
or whatever) which  can be sent and/or received over a given link in
a given period of time (by all users and processes). For example,
the Rogers Wave T1 line from Ottawa to Toronto  provides a
bi-directional bandwidth of 1.544 Mbps .

Throughput I define as the actual amount of data any given user,
process, session or whatever can send or receive in a given period
of time. For example, my cable modem is limited to 512 Kbps or so
and the maximum throughput I can achieve through this modem is in
theory 512 Kbps. In practice the maximum I see is about 480 Kbps.


>You cannot expect to provide real-world performance figures from
>one host.  Accordingly, the best you can do is give a time-averaged
>estimate by RTT method of the effective throughput for unidirectional
>communcation to an ISP along the link from ISP to network provider.
>Of course, this is of only limited value for obvious reasons.

You may call it anything you wish and you may be more technically
accurate. The term "Ping latency test" suits me just fine.


>: speeds. Bing
>: results purport to show actual total line speeds rather than speed
>: available to
>: your host.
>
>Actually, no, it displays a weighted average throughput and
>packet loss, which is really the only useful information
>you can gain from single-host examination.


Perhaps you are referring to some other Bing. The Bing I refer
to is based on Bing 1.0.4 and available at
http://www.mygale.org/~fgouget/apps/bing_src-1.0.4.tar.gz .

I'll quote the readme file. Note that the writer(s) of this document
appear to use bandwidth and throughput interchangably.


*Bing is a point-to-point bandwidth measurement tool (hence the
*'b'), based on ping.
*
*Bing determines the real (raw, as opposed to available or average)
*throughput on a link by measuring ICMP echo requests roundtrip times
*for different packet sizes for each end of the link.

<snip>

*If we do that for two different packet sizes, we can compute the
*raw capacity (bps) of the link.



The readme.txt file from the "Unofficial Release" of Bing 1.1.3
available at http://www.mygale.org/~fgouget/apps/bing_src-1.1.3.tar.gz
has the same information

The bing.txt file from that Bing 1.1.3 has this:

*NAME
*       bing  -  compute point to point throughput using two sizes
*       of ICMP ECHO_REQUEST packets to pairs of remote hosts.
*
*DESCRIPTION
*       Bing determines bandwidth  on  a  point-to-point  link  by
*       sending  ICMP  ECHO_REQUEST  packets  and  measuring their
*       roundtrip times for different packet sizes on each end  of
*       the link.


I suggest that the writers of these documents and source code have
used the terms bandwidth and throughput interchangeably and incorrectly
and that you may have become similarly confused.

The readme.txt file from both Bings also contains:

*5. Measurement problems
*-----------------------
*
*There are many cases in which the measurements may not be accurate
*(read:  "plain wrong") :
*
*	- saturated links. bing works by measuring the minimal rtts.
*	  The more saturated links there are in the measure path,
*	  the more time it takes to get a packet through all of
*	  them with minimal delay.


I would suggest that attempting to use Bing to estimate throughput
from the testing host to some other host is invalid and merely
demonstrates this problem.

Running Bing on my own computer to estimate the bandwidth of Rogers
T1 link from Ottawa to Toronto produces figures from about 1.2 to 1.9
Mbps . My cable modem is limited to about 512 Kbps. If Bing was
measuring my throughput it would show figures much closer to 500 Kbps.


>I don't understand these http tests;  the tests would be so
>algorithm-dependent that I would advise a high degree
>of caution in presenting the results.

Perhaps that would be appropriate. OTOH, I beleive that as long as
one is reasonably aware of the limitations of the data, having
some data, even raw data, is better than having no data at all.
We could argue all day long about how useful it is or isn't but I
really don't wish to argue, beyond defending myself from misconceptions
and the like.


Mike.

-------------------==== Posted via Deja News ====-----------------------
      http://www.dejanews.com/     Search, Read, Post to Usenet