Thank you, Liz Rice! This was very informative. Similar to your "Containers From Scratch" talk, this was very beginner-friendly, yet somewhat low-level.
Great demostration Liz. Quick question: compare time for ping in both cases. without traffic control (tc) 00:15:43 time=0.095 with traffic control(tc) 00:21:46 time=0.230 with tc it should have been quicker as we skip network stack in container, but it was other way around. My take would be trace messages printing may have added delay but not sure about it. Will recreate the setup and validate my claim. Would like to know form others what they think about this ?
Took 6 months to get to me, but anyways. First, to answer your question I'm going to ignore the fact that it's just one ping, so there's no standard dev. This would mean that you can't really say if the values are different or not. So, just for the fun of commenting on code, here we go: I would say that the major contributor is overhead from the ping reply. Didn't look at the source code, but that clone might be the guy you're looking for. Running with an operf and then a opannotate should give you the answer. Ping, if I'm not mistaken, is answered by the ICMP module in the kernel. So it's pretty darn fast. In fact, you can disable it with ```sysctl -w net.ipv4.icmp_echo_ignore_all=1```. Gonna need sudo for that. If you hit a ping localhost after that you'll see that your ping doesn't get any answers. The printing might cause some delay, yes, but you have printing in both cases.
![CNCF [Cloud Native Computing Foundation]](http://yt3.ggpht.com/txe66EjpkDQQlx_4jDV0yA0PPsww0rqQrFhMpDqagLWN2-EUBBO65IuIyy5tEFVmpI4_RRduzXc=s48-c-k-c0x00ffffff-no-rj)
Thank you, Liz Rice! This was very informative.
Similar to your "Containers From Scratch" talk, this was very beginner-friendly, yet somewhat low-level.
Perfect demonstration..! I know a lot more and a lot better now! Thanks.
super video
Wow awesome
Great demostration Liz.
Quick question:
compare time for ping in both cases.
without traffic control (tc) 00:15:43 time=0.095
with traffic control(tc) 00:21:46 time=0.230
with tc it should have been quicker as we skip network stack in container, but it was other way around.
My take would be trace messages printing may have added delay but not sure about it.
Will recreate the setup and validate my claim.
Would like to know form others what they think about this ?
Took 6 months to get to me, but anyways.
First, to answer your question I'm going to ignore the fact that it's just one ping, so there's no standard dev. This would mean that you can't really say if the values are different or not. So, just for the fun of commenting on code, here we go:
I would say that the major contributor is overhead from the ping reply. Didn't look at the source code, but that clone might be the guy you're looking for. Running with an operf and then a opannotate should give you the answer.
Ping, if I'm not mistaken, is answered by the ICMP module in the kernel. So it's pretty darn fast. In fact, you can disable it with ```sysctl -w net.ipv4.icmp_echo_ignore_all=1```. Gonna need sudo for that. If you hit a ping localhost after that you'll see that your ping doesn't get any answers.
The printing might cause some delay, yes, but you have printing in both cases.
where can we get the demo codes?
Get the book learning eBPF under O'Reilly publication
It's free officially I think
This lady is the author there if I remember right