> On May 6, 2018, at 21:27, Toke Høiland-Jørgensen <t...@toke.dk> wrote:
>
> 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...
But that "should" only affect the ICMP reflector, no? I always assumed
that routers will treat ICMP packets that they only pass though just like any
other IP packet...
> Also, ICMP is often subject to
> rate limiting... etc, etc...
>
If I understand posts in the nanog list correctly thee is also a trend
towards limiting UDP as well.
> -Toke
>
> _______________________________________________
> 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
