> 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
