Hi Pete,
you could also try different packet sizes for you probes. The size ratio should
give you an idea about the RTT difference explained by simple transit times and
anything on top of that might be related to queueing. I am probably severely
underestimating the scope of your question, but I believe that that also has
the advantage that, unlike packet-tuples, will not be as sensitive to bonded
path segments (which probably do not exist in your environment in the first
place).
Best Regards
Sebastian
> On May 6, 2018, at 20:28, Pete Heist <p...@eventide.io> wrote:
>
>
>> On May 6, 2018, at 5:54 PM, Toke Høiland-Jørgensen <t...@toke.dk> wrote:
>>
>> Pete Heist <p...@eventide.io> writes:
>>
>>> Channel contention delay may be estimated by the difference between
>>> the round-trip times for the strict priority VO and BE packets (0x01
>>> and 0xb9), and queueing delay between the regular vs strict priority
>>> VO packets (0xb8 and 0xb9), right?
>>
>> I like the idea, but is there any equipment that actually implements
>> strict priority queueing within a single QoS level? Or how are you
>> planning to elicit this behavior?
>
> The backhaul I’d like to test it on uses mostly NSM5s as the wireless devices
> and APUs for routing, QoS, etc. The QoS scripts use the htb, sfq and prio
> qdiscs. I’m hoping I can just add a prio qdisc / tc filter somewhere in the
> existing rules.
>
>>> Lastly, I’ll need to find out for sure how much impact the use of UDP
>>> with a userspace client/server (in Go) is having vs ICMP. I find it hard to
>>> believe that I’m seeing tens of
>>> milliseconds going into userspace.
>>
>> That does seem a bit much. Hard to tell what is the cause without a more
>> controlled experiment, though...
>
> Actually, I think it’s impossible that userspace overhead is the problem
> here. The irtt client and server devices are completely independent of the
> network routing/firewalling hardware, so the CPU load on them is identical at
> times of low and high network load.
>
> I now added SmokePing ICMP and IRTT targets for the same LAN host, and can
> look at that distribution after a day to judge the overhead.
>
> I guess it’s possible that ICMP may route faster over the Internet than UDP
> even if it isn’t being prioritized, but I would be surprised if that much
> faster. Not quite related, but I also find this interesting:
>
> https://perso.uclouvain.be/olivier.bonaventure/blog/html/2013/05/22/don_t_use_ping_for_delay_measurements.html
>
>
> _______________________________________________
> Flent-users mailing list
> Flent-users@flent.org
> http://flent.org/mailman/listinfo/flent-users_flent.org
_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org
