Pete Heist <p...@eventide.io> writes: >> 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.
Ah, so this is a wired connection? And you are only targeting a particular setup? If you are running sfq you are probably not going to measure a lot of queueing delay, though, as the UDP flow will just get its own queue... >>> 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 Yeah, ICMP is definitely treated differently in many places... Another example is routers and switches that have a data plane implemented in hardware will reply to ICMP from the software control plane, which is way *slower* than regular forwarding... Also, ICMP is often subject to rate limiting... etc, etc... -Toke _______________________________________________ Flent-users mailing list Flent-users@flent.org http://flent.org/mailman/listinfo/flent-users_flent.org
