pchar for v6

[Bruce A. Mah]

--==_Exmh_-420695554P
Content-Type: text/plain; charset=us-ascii

If memory serves me right, SUMIKAWA Munechika wrote:
> > We, KAME developers, made port/pkgsrc of KAME-NetBSD and KAME-FreeBSD
> > for easily installation. It will be distributed at next snap on Monday.
> bmah> Cool.  Does this mean that pchar works on NetBSD?  On which platform(s)
> ?
> 
> Yes. We checked that it works on only KAME-NetBSD1.4.1-i386.

OK, I'll make a note of that, thanks!

> But, I got strage results in some situation. See #3 item in the
> following results. Pchar reports minus Band Width. What happens?

[snip]

> prince:~% root pchar -p ipv6udp june.v6.wide.ad.jp
> pchar to june.v6.wide.ad.jp (3ffe:501:0:801:290:27ff:fe61:b0dd) using UDP/IPv
> 6
> Packet size increments by 32 to 1500
> 46 test(s) per repetition
> 32 repetition(s) per hop
>  0:
>     Partial loss:      0 / 1440 (0%)
>     Partial char:      rtt = 0.502937 ms, (b = 0.002287 ms/B), r2 = 0.997345
>                        stddev rtt = 0.013819, stddev b = 0.000018
    Hop char:          rtt = 0.502937 ms, bw = 3498.514557 Kbps
>     Partial queueing:  avg = 0.000084 ms (36 bytes)
>  1: 3ffe:501:4819:8000:200:f8ff:fe04:5469 (3ffe:501:4819:8000:200:f8ff:fe04:5
> 469)
>     Partial loss:      194 / 1440 (13%)
>     Partial char:      rtt = 22.162998 ms, (b = 0.015425 ms/B), r2 = 0.989061
>                        stddev rtt = 0.179215, stddev b = 0.000267
>     Hop char:          rtt = 21.660061 ms, bw = 608.906665 Kbps
>     Partial queueing:  avg = 0.005603 ms (363 bytes)
>  2: 3ffe:501:0:4800:21:6a39:6174:3 (paradise.karigome.wide.ad.jp)
>     Partial loss:      192 / 1440 (13%)
>     Partial char:      rtt = 26.774703 ms, (b = 0.025138 ms/B), r2 = 0.996783
>                        stddev rtt = 0.157757, stddev b = 0.000235
>     Hop char:          rtt = 4.611704 ms, bw = 823.676532 Kbps
>     Partial queueing:  avg = 0.003620 ms (144 bytes)
>  3: 3ffe:501:0:1c01:200:f8ff:fe03:d9c0 (pc3.nezu.wide.ad.jp)
>     Partial loss:      4 / 1440 (0%)
>     Partial char:      rtt = 47.038458 ms, (b = 0.024740 ms/B), r2 = 0.996857
>                        stddev rtt = 0.162686, stddev b = 0.000212
>     Hop char:          rtt = 20.263755 ms, bw = -20116.530889 Kbps
>     Partial queueing:  avg = 0.009824 ms (397 bytes)
>  4: 3ffe:501:0:801:290:27ff:fe61:b0dd (june.nara.wide.ad.jp)
>     Path length:       4 hops
>     Path char:         rtt = 47.038458 ms, r2 = 0.996857
>     Path bottleneck:   608.906665 Kbps
>     Path pipe:         3580 bytes
>     Path queueing:     average = 0.009824 ms (397 bytes)

What's happening here is that pchar has estimated the incremental time
to send a byte to be 0.025138, three hops into the network.  Normally
you would expect this cost to increase for measurements going four hops
into the network.  However, this wasn't the case (to go four hops, the
incremental time per byte was 0.024740). The inverse of the difference
is the negative bandwidth estimate (-20 Mbps).

This can happen in cases where you have differences in processing speed 
of routers, lots of loss or transient changes, or just poor curve fits.
(Actually the least squares fit did pretty well, since the r2 parameter
is pretty close to 1.)

It isn't quite a bug, it's just a case that pchar doesn't know how to
handle.  I need to make a FAQ item on this...I've answered this question
three times (in different forums) today.  :-)

Cheers,

Bruce.

PS.  Actually if you could make up a tracefile with the -w option
and send it to me, that'd be interesting to see.  I can't promise it'll
lead to a fix, but you never know....







--==_Exmh_-420695554P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: KxruldRedkGCdk1/uct5TNuPUJ7+tZL1

iQA/AwUBOCH/A9jKMXFboFLDEQI5qgCgxbKzywO+QFqdv/NCX9YKj7TqcFYAn3rY
LEsyUi80OzxfQ/lvdGrunZpF
=vbWh
-----END PGP SIGNATURE-----

--==_Exmh_-420695554P--