[Flent-users] SmokePing probe

Pete Heist peteheist at gmail.com
Sun Feb 18 13:35:46 EET 2018

The author pulled the probe in pretty quickly, so it’s already upstream. Some samples:

https://www.drhleny.cz/bufferbloat/smokeping/irtt_smokeping.png <https://www.drhleny.cz/bufferbloat/smokeping/irtt_smokeping.png>

https://www.drhleny.cz/bufferbloat/smokeping/irtt_smokeping2.png <https://www.drhleny.cz/bufferbloat/smokeping/irtt_smokeping2.png>

Maybe I’ll post another image after a while if something more exciting happens… :)

> On Feb 18, 2018, at 12:29 AM, Pete Heist <peteheist at gmail.com> wrote:
> I wrote a SmokePing (https://oss.oetiker.ch/smokeping/) probe for IRTT:
> Code: https://github.com/peteheist/SmokePing/blob/master/lib/Smokeping/probes/IRTT.pm
> Pull request: https://github.com/oetiker/SmokePing/pull/110
> I hope to use this in my ISP, which uses SmokePing for about 70 access points. Since ICMP is apparently being prioritized, I don’t think the current SmokePing graphs are telling much of a story about queueing delay.
> I’ve been mesmerized for the past couple hours watching one-way delay stats. The link I’m testing is 3km NLOS point-to-point WiFi, with trees about 100 meters from my side of the link. When there is delay or loss, it’s almost always on sending (from me). Median send IPDV (jitter) is around 5x that of the receive IPDV. Presumably, the scattering due to the trees is worse on the uplink because the signal hits the trees closer to the transmitter, when it still has a longer distance to travel. This may also explain my 10/30 asymmetric throughput. I thought about trimming these trees, but this is too much fun… :)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://flent.org/pipermail/flent-users_flent.org/attachments/20180218/e3cc7c44/attachment-0002.html>

More information about the Flent-users mailing list