* [Bloat] Measuring CoDel
@ 2021-01-22 23:37 Hal Murray
2021-01-23 0:34 ` Toke Høiland-Jørgensen
0 siblings, 1 reply; 3+ messages in thread
From: Hal Murray @ 2021-01-22 23:37 UTC (permalink / raw)
To: bloat; +Cc: Hal Murray
Toke said:
> Yeah, the overhead of CoDel itself (and even FQ-CoDel) is basically nil (as
> in, we have not been able to measure it), when otherwise doing forwarding
> using the regular Linux stack.
I may be able to help with that.
Are you familiar with Dick Sites' KUtrace?
Stanford Seminar - KUtrace 2020
https://www.youtube.com/watch?v=2HE7tSZGna0
The catch is that I've never used CoDel so somebody will have to teach me how
to setup a test environment, and then show me the chunks in the kernel you
want to measure.
--
These are my opinions. I hate spam.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Bloat] Measuring CoDel
2021-01-22 23:37 [Bloat] Measuring CoDel Hal Murray
@ 2021-01-23 0:34 ` Toke Høiland-Jørgensen
2021-01-25 9:31 ` Jesper Dangaard Brouer
0 siblings, 1 reply; 3+ messages in thread
From: Toke Høiland-Jørgensen @ 2021-01-23 0:34 UTC (permalink / raw)
To: Hal Murray, bloat; +Cc: Hal Murray
Hal Murray <hmurray@megapathdsl.net> writes:
> Toke said:
>> Yeah, the overhead of CoDel itself (and even FQ-CoDel) is basically nil (as
>> in, we have not been able to measure it), when otherwise doing forwarding
>> using the regular Linux stack.
>
> I may be able to help with that.
>
> Are you familiar with Dick Sites' KUtrace?
> Stanford Seminar - KUtrace 2020
> https://www.youtube.com/watch?v=2HE7tSZGna0
Nope - but from a quick glance it looks similar to what you can do with
'perf'? :)
> The catch is that I've never used CoDel so somebody will have to teach
> me how to setup a test environment, and then show me the chunks in the
> kernel you want to measure.
To measure the CoDel algorithm, I guess the thing to measure would be
codel_dequeue():
https://elixir.bootlin.com/linux/latest/source/include/net/codel_impl.h#L142
However, that has loops in it that depend on flow state, so its
execution time will vary some. For fq_codel it would be the
fq_codel_enqueue() and fq_codel_dequeue() functions, but they have a
similar problem:
https://elixir.bootlin.com/linux/latest/source/net/sched/sch_fq_codel.c
Also, the larger problem is that the overhead of these drown in all the
other processing the kernel does for each packet (none of the
queueing-related functions even register on a 'perf' report when
forwarding packets. Still, might be interesting to see, who knows? So
feel free to take a stab at it :)
-Toke
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Bloat] Measuring CoDel
2021-01-23 0:34 ` Toke Høiland-Jørgensen
@ 2021-01-25 9:31 ` Jesper Dangaard Brouer
0 siblings, 0 replies; 3+ messages in thread
From: Jesper Dangaard Brouer @ 2021-01-25 9:31 UTC (permalink / raw)
To: Toke Høiland-Jørgensen via Bloat
Cc: Toke Høiland-Jørgensen, Hal Murray
On Sat, 23 Jan 2021 01:34:19 +0100
Toke Høiland-Jørgensen via Bloat <bloat@lists.bufferbloat.net> wrote:
> Hal Murray <hmurray@megapathdsl.net> writes:
>
> > Toke said:
> >> Yeah, the overhead of CoDel itself (and even FQ-CoDel) is basically nil (as
> >> in, we have not been able to measure it), when otherwise doing forwarding
> >> using the regular Linux stack.
> >
> > I may be able to help with that.
> >
> > Are you familiar with Dick Sites' KUtrace?
> > Stanford Seminar - KUtrace 2020
> > https://www.youtube.com/watch?v=2HE7tSZGna0
>
> Nope - but from a quick glance it looks similar to what you can do with
> 'perf'? :)
Yes, but the 'perf' tool (mostly) uses sampling.
I assume you want to catch latency outliers, right?
I would probably recommend that you play with bpftrace[1], for
processing all the events to catch the outliers.
[1] https://github.com/iovisor/bpftrace
As an example look at this bpftrace script[2], that I used for
detecting latency issues, network hardIRQ-to-softirq latency.
[2] https://github.com/xdp-project/xdp-project/blob/master/areas/latency/softirq_net_latency.bt
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-01-25 9:31 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-22 23:37 [Bloat] Measuring CoDel Hal Murray
2021-01-23 0:34 ` Toke Høiland-Jørgensen
2021-01-25 9:31 ` Jesper Dangaard Brouer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox