From nfd-call-notification at mail1.yoursunny.com Thu Dec 2 17:07:03 2021 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Thu, 2 Dec 2021 18:07:03 -0700 Subject: [Nfd-dev] NFD call 20211202 Message-ID: <202112030107.1B31730L031772@york.cs.arizona.edu> An HTML attachment was scrubbed... URL: From nfd-call-notification at mail1.yoursunny.com Thu Dec 9 17:07:02 2021 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Thu, 9 Dec 2021 18:07:02 -0700 Subject: [Nfd-dev] NFD call 20211209 Message-ID: <202112100107.1BA172qc002374@york.cs.arizona.edu> An HTML attachment was scrubbed... URL: From lixia at cs.ucla.edu Sun Dec 12 10:49:41 2021 From: lixia at cs.ucla.edu (Lixia Zhang) Date: Sun, 12 Dec 2021 10:49:41 -0800 Subject: [Nfd-dev] Coming Friday: next hackathon topic discussion Message-ID: (not sure which list to use to reach all, this list reached way more people than needed) This msg is just a friendly reminder that we've scheduled for this coming Friday to discuss potential project topics for next NDN Hackathon. Doing a most productive hackathon requires lots thinking. As a suggestion, lets think what are the most urgent needs that have been blocking NDN progress, and focus next hackathon on those topics. Lixia From nfd-call-notification at mail1.yoursunny.com Thu Dec 16 17:07:02 2021 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Thu, 16 Dec 2021 18:07:02 -0700 Subject: [Nfd-dev] NFD call 20211216 Message-ID: <202112170107.1BH172Kn023446@york.cs.arizona.edu> An HTML attachment was scrubbed... URL: From a.taffal96 at gmail.com Thu Dec 23 04:46:02 2021 From: a.taffal96 at gmail.com (Ahmed Taffal) Date: Thu, 23 Dec 2021 13:46:02 +0100 Subject: [Nfd-dev] NFD Profiling tool Message-ID: Hi everyone, Is there any profiling tool that I can use to see how much time is consumed by the functions in NFD for processing Interest and Data packets? Because while using the NDNchunk tool, I am getting a throughput of around 40-50 Mbps, which is far from the 1Gbps speed of the line. (knowing that I am using the NFD v. 0.7.0 and I am running NDN over Ethernet) I will be grateful for your help, Regards, Ahmed -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Thu Dec 23 05:06:36 2021 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Thu, 23 Dec 2021 08:06:36 -0500 Subject: [Nfd-dev] [EXT] NFD Profiling tool In-Reply-To: References: Message-ID: Hi Ahmed Rebuild ndn-cxx and NFD with code coverage: ./waf configure --with-coverage When you run NFD, it will generate coverage files. You can then analyze them with lcov. See also https://redmine.named-data.net/issues/1621 Forwarding performance is measured in terms of packets per second, not Gbps. NFD is capable of 4800 Data packets per second, as reported on https://redmine.named-data.net/issues/1819#note-2 . If you need higher speeds, use YaNFD or NDN-DPDK. Yours, Junxiao On Thu, Dec 23, 2021 at 07:46 Ahmed Taffal via Nfd-dev < nfd-dev at lists.cs.ucla.edu> wrote: > *External Email* > Hi everyone, > > Is there any profiling tool that I can use to see how much time is > consumed by the functions in NFD for processing Interest and Data packets? > Because while using the NDNchunk tool, I am getting a throughput of around > 40-50 Mbps, which is far from the 1Gbps speed of the line. > (knowing that I am using the NFD v. 0.7.0 and I am running NDN over > Ethernet) > > I will be grateful for your help, > Regards, > Ahmed > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.taffal96 at gmail.com Thu Dec 23 08:31:19 2021 From: a.taffal96 at gmail.com (Ahmed Taffal) Date: Thu, 23 Dec 2021 17:31:19 +0100 Subject: [Nfd-dev] [EXT] NFD Profiling tool In-Reply-To: References: Message-ID: Thanks a lot for your reply, I rebuilt ndn-cxx and NFD with code coverage, but I am missing where the coverage files are located. Are they generated automatically in a specific path? or do I need to run some commands to get them (CodeCoverage - NFD - NDN project issue tracking system (named-data.net) )? Regards, Ahmed On Thu, 23 Dec 2021 at 14:06, Junxiao Shi wrote: > Hi Ahmed > > Rebuild ndn-cxx and NFD with code coverage: ./waf configure --with-coverage > When you run NFD, it will generate coverage files. > You can then analyze them with lcov. > See also > https://redmine.named-data.net/issues/1621 > > > Forwarding performance is measured in terms of packets per second, not > Gbps. > NFD is capable of 4800 Data packets per second, as reported on > https://redmine.named-data.net/issues/1819#note-2 . > If you need higher speeds, use YaNFD or NDN-DPDK. > > Yours, Junxiao > > On Thu, Dec 23, 2021 at 07:46 Ahmed Taffal via Nfd-dev < > nfd-dev at lists.cs.ucla.edu> wrote: > >> *External Email* >> Hi everyone, >> >> Is there any profiling tool that I can use to see how much time is >> consumed by the functions in NFD for processing Interest and Data packets? >> Because while using the NDNchunk tool, I am getting a throughput of around >> 40-50 Mbps, which is far from the 1Gbps speed of the line. >> (knowing that I am using the NFD v. 0.7.0 and I am running NDN over >> Ethernet) >> >> I will be grateful for your help, >> Regards, >> Ahmed >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nfd-call-notification at mail1.yoursunny.com Thu Dec 23 17:07:03 2021 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Thu, 23 Dec 2021 18:07:03 -0700 Subject: [Nfd-dev] NFD call 20211223 Message-ID: <202112240107.1BO173Co005426@york.cs.arizona.edu> An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Thu Dec 23 17:18:01 2021 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Thu, 23 Dec 2021 20:18:01 -0500 Subject: [Nfd-dev] [EXT] NFD Profiling tool In-Reply-To: References: Message-ID: Hi Ahmed Code coverage files are usually in the same place as the compiled object files, inside the "build" directory. You should see both *.gcno and ".gcda files there. They will be generated when NFD exits normally (not crashed). Yours, Junxiao On Thu, Dec 23, 2021 at 11:31 Ahmed Taffal wrote: > *External Email* > Thanks a lot for your reply, > I rebuilt ndn-cxx and NFD with code coverage, but I am missing where the > coverage files are located. > Are they generated automatically in a specific path? or do I need to run > some commands to get them (CodeCoverage - NFD - NDN project issue > tracking system (named-data.net) > )? > > Regards, > Ahmed > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.taffal96 at gmail.com Fri Dec 24 02:55:49 2021 From: a.taffal96 at gmail.com (Ahmed Taffal) Date: Fri, 24 Dec 2021 11:55:49 +0100 Subject: [Nfd-dev] [EXT] NFD Profiling tool In-Reply-To: References: Message-ID: Thank you very much, Regards, Ahmed On Fri, 24 Dec 2021 at 02:18, Junxiao Shi wrote: > Hi Ahmed > > Code coverage files are usually in the same place as the compiled object > files, inside the "build" directory. > You should see both *.gcno and ".gcda files there. > They will be generated when NFD exits normally (not crashed). > > Yours, Junxiao > > On Thu, Dec 23, 2021 at 11:31 Ahmed Taffal wrote: > >> *External Email* >> Thanks a lot for your reply, >> I rebuilt ndn-cxx and NFD with code coverage, but I am missing where the >> coverage files are located. >> Are they generated automatically in a specific path? or do I need to run >> some commands to get them (CodeCoverage - NFD - NDN project issue >> tracking system (named-data.net) >> )? >> >> Regards, >> Ahmed >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.taffal96 at gmail.com Fri Dec 24 04:47:58 2021 From: a.taffal96 at gmail.com (Ahmed Taffal) Date: Fri, 24 Dec 2021 13:47:58 +0100 Subject: [Nfd-dev] [EXT] NFD Profiling tool In-Reply-To: References: Message-ID: >From the coverage code report, I can see which functions and lines are executed in each hpp or cpp file, But there is no information about the time each function consumed. So I tried to use the gprof and I rebuilt the ndn-cxx and the NFD using this command *CXXFLAGS="-o2 -g -pg -pedantic -Wall" ./waf configure*. After terminating the NFD with nfd-stop I am not getting the gmon.out file. Should I use another method to terminate the NFD in order to get that file? *Regards,* *Ahmed* On Fri, 24 Dec 2021 at 11:55, Ahmed Taffal wrote: > Thank you very much, > > Regards, > Ahmed > > On Fri, 24 Dec 2021 at 02:18, Junxiao Shi > wrote: > >> Hi Ahmed >> >> Code coverage files are usually in the same place as the compiled object >> files, inside the "build" directory. >> You should see both *.gcno and ".gcda files there. >> They will be generated when NFD exits normally (not crashed). >> >> Yours, Junxiao >> >> On Thu, Dec 23, 2021 at 11:31 Ahmed Taffal wrote: >> >>> *External Email* >>> Thanks a lot for your reply, >>> I rebuilt ndn-cxx and NFD with code coverage, but I am missing where >>> the coverage files are located. >>> Are they generated automatically in a specific path? or do I need to run >>> some commands to get them (CodeCoverage - NFD - NDN project issue >>> tracking system (named-data.net) >>> )? >>> >>> Regards, >>> Ahmed >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidepesa at gmail.com Fri Dec 24 11:21:44 2021 From: davidepesa at gmail.com (Davide Pesavento) Date: Fri, 24 Dec 2021 14:21:44 -0500 Subject: [Nfd-dev] NFD Profiling tool In-Reply-To: References: Message-ID: Hi Ahmed, NFD is just a normal application, so, assuming you're on Linux, you can use any regular Linux profiling tool, such as gprof, callgrind (+ kcachegrind), or something more modern like perf. Best regards, Davide On Thu, Dec 23, 2021 at 7:46 AM Ahmed Taffal via Nfd-dev wrote: > > Hi everyone, > > Is there any profiling tool that I can use to see how much time is consumed by the functions in NFD for processing Interest and Data packets? Because while using the NDNchunk tool, I am getting a throughput of around 40-50 Mbps, which is far from the 1Gbps speed of the line. > (knowing that I am using the NFD v. 0.7.0 and I am running NDN over Ethernet) > > I will be grateful for your help, > Regards, > Ahmed > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev From davidepesa at gmail.com Fri Dec 24 11:29:23 2021 From: davidepesa at gmail.com (Davide Pesavento) Date: Fri, 24 Dec 2021 14:29:23 -0500 Subject: [Nfd-dev] [EXT] NFD Profiling tool In-Reply-To: References: Message-ID: Junxiao, On Thu, Dec 23, 2021 at 8:06 AM Junxiao Shi via Nfd-dev wrote: > > Hi Ahmed > > Rebuild ndn-cxx and NFD with code coverage: ./waf configure --with-coverage > When you run NFD, it will generate coverage files. > You can then analyze them with lcov. lcov is a code coverage tool, I'm not sure why you're suggesting it for profiling. > See also > https://redmine.named-data.net/issues/1621 > > > Forwarding performance is measured in terms of packets per second, not Gbps. > NFD is capable of 4800 Data packets per second, as reported on https://redmine.named-data.net/issues/1819#note-2 . Those numbers are not/no longer relevant, you should stop citing them. First of all, the benchmark uses UDP, not Ethernet faces. Second, they're over 7 years old. Finally, NFD is CPU bound, so the results are highly dependent on your hardware. Davide From davidepesa at gmail.com Fri Dec 24 11:36:01 2021 From: davidepesa at gmail.com (Davide Pesavento) Date: Fri, 24 Dec 2021 14:36:01 -0500 Subject: [Nfd-dev] [EXT] NFD Profiling tool In-Reply-To: References: Message-ID: On Fri, Dec 24, 2021 at 7:48 AM Ahmed Taffal via Nfd-dev wrote: > > So I tried to use the gprof and I rebuilt the ndn-cxx and the NFD using this command CXXFLAGS="-o2 -g -pg -pedantic -Wall" ./waf configure. After terminating the NFD with nfd-stop I am not getting the gmon.out file. Should I use another method to terminate the NFD in order to get that file? Make sure you add "-pg" to the LINKFLAGS as well. Also please note that the optimization flag is "-O2" with a capital "O". Davide From a.taffal96 at gmail.com Fri Dec 24 17:15:48 2021 From: a.taffal96 at gmail.com (Ahmed Taffal) Date: Sat, 25 Dec 2021 02:15:48 +0100 Subject: [Nfd-dev] [EXT] NFD Profiling tool In-Reply-To: References: Message-ID: Thank you! it worked now. Regarding NFD performance, you said it depends on the CPU, but in my experiment when I used the NDNchunk tool to fetch a 100MB file (packet size to 8KB), I got a goodput of 43Mbps (it is calculated using the ndncatchunk), and the CPU usage of the NFD was not more than 15%. So, in this case, can I say that the reason for having this goodput is related to the NFD implementation? or there is a way to get better performance? Thanks in advance, Regards, Ahmed On Fri, 24 Dec 2021 at 20:36, Davide Pesavento wrote: > On Fri, Dec 24, 2021 at 7:48 AM Ahmed Taffal via Nfd-dev > wrote: > > > > So I tried to use the gprof and I rebuilt the ndn-cxx and the NFD using > this command CXXFLAGS="-o2 -g -pg -pedantic -Wall" ./waf configure. After > terminating the NFD with nfd-stop I am not getting the gmon.out file. > Should I use another method to terminate the NFD in order to get that file? > > Make sure you add "-pg" to the LINKFLAGS as well. Also please note > that the optimization flag is "-O2" with a capital "O". > > Davide > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Mon Dec 27 09:42:15 2021 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Mon, 27 Dec 2021 12:42:15 -0500 Subject: [Nfd-dev] [EXT] NFD Profiling tool In-Reply-To: References: Message-ID: Hi Ahmed Code coverage options allow you to gain insights on how often each part of code is called and how long it takes to execute, but does not represent the performance. You must use a production build, such as those available on https://nfd-nightly.ndn.today or built without any flags, for performance measurements. The goodput of ndnchunks is indeed CPU dependent. You need a CPU with high single-core performance to get good speeds. Below results were from a recent NFD-nightly build, tested with the following commands: dd if=/dev/urandom bs=1MiB count=100 | ndnputchunks /A ndncatchunks /A >/dev/null Each test was executed only once, but you can see the order of magnitude. BeagleBone Black, AM335x ARMv7 @ 1.00GHz All segments have been received. Time elapsed: 52.4614 seconds Segments received: 13108 Transferred size: 104858 kB Goodput: 15.990046 Mbit/s Congestion marks: 19 (caused 8 window decreases) Timeouts: 18 (caused 2 window decreases) Retransmitted segments: 17 (0.129524%), skipped: 1 RTT min/avg/max = 5.158/697.682/1218.870 ms Dedicated server, Intel Xeon Gold 6240 @ 2.60GHz All segments have been received. Time elapsed: 1.44266 seconds Segments received: 13108 Transferred size: 104858 kB Goodput: 581.468758 Mbit/s Congestion marks: 46 (caused 26 window decreases) Timeouts: 2895 (caused 1 window decreases) Retransmitted segments: 2895 (18.0904%), skipped: 0 RTT min/avg/max = 0.214/25.518/250.909 ms KVM server, AMD Ryzen 9 3950X @ 3.50GHz All segments have been received. Time elapsed: 3.25011 seconds Segments received: 13108 Transferred size: 104858 kB Goodput: 258.102087 Mbit/s Congestion marks: 28 (caused 12 window decreases) Timeouts: 212 (caused 1 window decreases) Retransmitted segments: 48 (0.364853%), skipped: 164 RTT min/avg/max = 0.726/43.642/295.405 ms KVM server, Intel Xeon E-2288G @ 3.70GHz All segments have been received. Time elapsed: 10.1643 seconds Segments received: 13108 Transferred size: 104858 kB Goodput: 82.529791 Mbit/s Congestion marks: 59 (caused 14 window decreases) Timeouts: 1750 (caused 8 window decreases) Retransmitted segments: 1641 (11.1262%), skipped: 109 RTT min/avg/max = 0.197/23.531/908.446 ms Yours, Junxiao On Fri, Dec 24, 2021 at 8:16 PM Ahmed Taffal via Nfd-dev < nfd-dev at lists.cs.ucla.edu> wrote: > *External Email* > Thank you! it worked now. > > Regarding NFD performance, you said it depends on the CPU, but in my > experiment when I used the NDNchunk tool to fetch a 100MB file (packet size > to 8KB), I got a goodput of 43Mbps (it is calculated using the > ndncatchunk), and the CPU usage of the NFD was not more than 15%. So, in > this case, can I say that the reason for having this goodput is related to > the NFD implementation? or there is a way to get better performance? > > Thanks in advance, > Regards, > Ahmed > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidepesa at gmail.com Mon Dec 27 10:29:36 2021 From: davidepesa at gmail.com (Davide Pesavento) Date: Mon, 27 Dec 2021 13:29:36 -0500 Subject: [Nfd-dev] [EXT] NFD Profiling tool In-Reply-To: References: Message-ID: Ahmed, I was referring specifically to those obsolete benchmark results on redmine. Those tests were run over UDP, not Ethernet. As for Ethernet faces, their implementation is substantially different from UDP faces (libpcap vs sockets), and I really cannot say what the bottleneck is, I've never profiled that part of NFD. Please let us know if you find any issues in the code! Regards, Davide On Fri, Dec 24, 2021 at 8:15 PM Ahmed Taffal wrote: > > Thank you! it worked now. > > Regarding NFD performance, you said it depends on the CPU, but in my experiment when I used the NDNchunk tool to fetch a 100MB file (packet size to 8KB), I got a goodput of 43Mbps (it is calculated using the ndncatchunk), and the CPU usage of the NFD was not more than 15%. So, in this case, can I say that the reason for having this goodput is related to the NFD implementation? or there is a way to get better performance? > > Thanks in advance, > Regards, > Ahmed > > On Fri, 24 Dec 2021 at 20:36, Davide Pesavento wrote: >> >> On Fri, Dec 24, 2021 at 7:48 AM Ahmed Taffal via Nfd-dev >> wrote: >> > >> > So I tried to use the gprof and I rebuilt the ndn-cxx and the NFD using this command CXXFLAGS="-o2 -g -pg -pedantic -Wall" ./waf configure. After terminating the NFD with nfd-stop I am not getting the gmon.out file. Should I use another method to terminate the NFD in order to get that file? >> >> Make sure you add "-pg" to the LINKFLAGS as well. Also please note >> that the optimization flag is "-O2" with a capital "O". >> >> Davide From davidepesa at gmail.com Mon Dec 27 10:39:35 2021 From: davidepesa at gmail.com (Davide Pesavento) Date: Mon, 27 Dec 2021 13:39:35 -0500 Subject: [Nfd-dev] [EXT] NFD Profiling tool In-Reply-To: References: Message-ID: On Mon, Dec 27, 2021 at 12:42 PM Junxiao Shi wrote: > > Below results were from a recent NFD-nightly build, tested with the following commands: > dd if=/dev/urandom bs=1MiB count=100 | ndnputchunks /A > ndncatchunks /A >/dev/null > Each test was executed only once, but you can see the order of magnitude. Did you run these tests over Ethernet, or UDP, or something else? Thanks, Davide From shijunxiao at email.arizona.edu Mon Dec 27 10:48:46 2021 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Mon, 27 Dec 2021 13:48:46 -0500 Subject: [Nfd-dev] [EXT] NFD Profiling tool In-Reply-To: References: Message-ID: Hi Davide I used local Unix sockets only. OP never mentioned anything regarding Ethernet or UDP, so I assume it's local too. Yours, Junxiao On Mon, Dec 27, 2021 at 1:39 PM Davide Pesavento wrote: > External Email > > On Mon, Dec 27, 2021 at 12:42 PM Junxiao Shi > wrote: > > > > Below results were from a recent NFD-nightly build, tested with the > following commands: > > dd if=/dev/urandom bs=1MiB count=100 | ndnputchunks /A > > ndncatchunks /A >/dev/null > > Each test was executed only once, but you can see the order of magnitude. > > Did you run these tests over Ethernet, or UDP, or something else? > > Thanks, > Davide > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidepesa at gmail.com Mon Dec 27 11:00:42 2021 From: davidepesa at gmail.com (Davide Pesavento) Date: Mon, 27 Dec 2021 14:00:42 -0500 Subject: [Nfd-dev] [EXT] NFD Profiling tool In-Reply-To: References: Message-ID: I believe Ahmed said they're running NDN over Ethernet in the first email. Btw... Ahmed, you can quickly check if the Ethernet face implementation is a bottleneck in your scenario by re-running the same tests over UDP and comparing the results. Best regards, Davide On Mon, Dec 27, 2021 at 1:49 PM Junxiao Shi wrote: > > Hi Davide > > I used local Unix sockets only. > OP never mentioned anything regarding Ethernet or UDP, so I assume it's local too. > > Yours, Junxiao > > On Mon, Dec 27, 2021 at 1:39 PM Davide Pesavento wrote: >> >> External Email >> >> On Mon, Dec 27, 2021 at 12:42 PM Junxiao Shi >> wrote: >> > >> > Below results were from a recent NFD-nightly build, tested with the following commands: >> > dd if=/dev/urandom bs=1MiB count=100 | ndnputchunks /A >> > ndncatchunks /A >/dev/null >> > Each test was executed only once, but you can see the order of magnitude. >> >> Did you run these tests over Ethernet, or UDP, or something else? >> >> Thanks, >> Davide From a.taffal96 at gmail.com Mon Dec 27 12:01:17 2021 From: a.taffal96 at gmail.com (Ahmed Taffal) Date: Mon, 27 Dec 2021 21:01:17 +0100 Subject: [Nfd-dev] [EXT] NFD Profiling tool In-Reply-To: References: Message-ID: Thank you all for your help. Yes, I am running NFD over ethernet as I mentioned earlier. In particular, I am building a network containing a set of Raspberry pi 400. In my network, I don't want to rely on the IP protocol, so I am running NDN over Ethernet. I am not using any routing protocol, instead, I am using the self-learning strategy for creating routes and faces which I think will increase a bit the latency for getting the data packets and so affecting the goodput. But regarding the comparison between UDP and Ethernet faces, I did some experiments using virtual machines and as I remember, there was no big difference between the goodput values in both cases. Actually, there was no consistency, sometimes the goodput using Ethernet is higher and sometimes the reverse. Kind regards, Ahmed On Mon, 27 Dec 2021 at 20:00, Davide Pesavento wrote: > I believe Ahmed said they're running NDN over Ethernet in the first email. > > Btw... Ahmed, you can quickly check if the Ethernet face > implementation is a bottleneck in your scenario by re-running the same > tests over UDP and comparing the results. > > Best regards, > Davide > > On Mon, Dec 27, 2021 at 1:49 PM Junxiao Shi > wrote: > > > > Hi Davide > > > > I used local Unix sockets only. > > OP never mentioned anything regarding Ethernet or UDP, so I assume it's > local too. > > > > Yours, Junxiao > > > > On Mon, Dec 27, 2021 at 1:39 PM Davide Pesavento > wrote: > >> > >> External Email > >> > >> On Mon, Dec 27, 2021 at 12:42 PM Junxiao Shi > >> wrote: > >> > > >> > Below results were from a recent NFD-nightly build, tested with the > following commands: > >> > dd if=/dev/urandom bs=1MiB count=100 | ndnputchunks /A > >> > ndncatchunks /A >/dev/null > >> > Each test was executed only once, but you can see the order of > magnitude. > >> > >> Did you run these tests over Ethernet, or UDP, or something else? > >> > >> Thanks, > >> Davide > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.taffal96 at gmail.com Mon Dec 27 12:25:17 2021 From: a.taffal96 at gmail.com (Ahmed Taffal) Date: Mon, 27 Dec 2021 21:25:17 +0100 Subject: [Nfd-dev] [EXT] NFD Profiling tool In-Reply-To: References: Message-ID: And for NFD profiling, I used gprof and as you can see in the picture below, the ndn::Block::~Block() function is the highest time consuming which is used to create an invalid block as mentioned in the ndn-cxx documentation, so I wonder what exactly they mean by invalid block. Regards, On Mon, 27 Dec 2021 at 21:01, Ahmed Taffal wrote: > Thank you all for your help. > > Yes, I am running NFD over ethernet as I mentioned earlier. In particular, > I am building a network containing a set of Raspberry pi 400. In my > network, I don't want to rely on the IP protocol, so I am running NDN over > Ethernet. I am not using any routing protocol, instead, I am using the > self-learning strategy for creating routes and faces which I think will > increase a bit the latency for getting the data packets and so affecting > the goodput. > But regarding the comparison between UDP and Ethernet faces, I did some > experiments using virtual machines and as I remember, there was no big > difference between the goodput values in both cases. Actually, there was no > consistency, sometimes the goodput using Ethernet is higher and sometimes > the reverse. > > Kind regards, > Ahmed > > On Mon, 27 Dec 2021 at 20:00, Davide Pesavento > wrote: > >> I believe Ahmed said they're running NDN over Ethernet in the first email. >> >> Btw... Ahmed, you can quickly check if the Ethernet face >> implementation is a bottleneck in your scenario by re-running the same >> tests over UDP and comparing the results. >> >> Best regards, >> Davide >> >> On Mon, Dec 27, 2021 at 1:49 PM Junxiao Shi >> wrote: >> > >> > Hi Davide >> > >> > I used local Unix sockets only. >> > OP never mentioned anything regarding Ethernet or UDP, so I assume it's >> local too. >> > >> > Yours, Junxiao >> > >> > On Mon, Dec 27, 2021 at 1:39 PM Davide Pesavento >> wrote: >> >> >> >> External Email >> >> >> >> On Mon, Dec 27, 2021 at 12:42 PM Junxiao Shi >> >> wrote: >> >> > >> >> > Below results were from a recent NFD-nightly build, tested with the >> following commands: >> >> > dd if=/dev/urandom bs=1MiB count=100 | ndnputchunks /A >> >> > ndncatchunks /A >/dev/null >> >> > Each test was executed only once, but you can see the order of >> magnitude. >> >> >> >> Did you run these tests over Ethernet, or UDP, or something else? >> >> >> >> Thanks, >> >> Davide >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: flat_report.png Type: image/png Size: 217174 bytes Desc: not available URL: From davidepesa at gmail.com Thu Dec 30 15:45:16 2021 From: davidepesa at gmail.com (Davide Pesavento) Date: Thu, 30 Dec 2021 18:45:16 -0500 Subject: [Nfd-dev] [EXT] NFD Profiling tool In-Reply-To: References: Message-ID: Ahmed, Block::~Block() doesn't create anything. It's the destructor of the C++ class "Block", which represents a TLV element in memory. The time spent in the destructor probably includes memory deallocation. Memory management in the ndn-cxx library has never been seriously optimized, so I'm not surprised that this shows up in the profiling results. Best regards, Davide On Mon, Dec 27, 2021 at 3:25 PM Ahmed Taffal wrote: > > And for NFD profiling, I used gprof and as you can see in the picture below, the ndn::Block::~Block() function is the highest time consuming which is used to create an invalid block as mentioned in the ndn-cxx documentation, so I wonder what exactly they mean by invalid block. > > Regards, > From nfd-call-notification at mail1.yoursunny.com Thu Dec 30 17:07:02 2021 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Thu, 30 Dec 2021 18:07:02 -0700 Subject: [Nfd-dev] NFD call 20211230 Message-ID: <202112310107.1BV172GB021780@york.cs.arizona.edu> An HTML attachment was scrubbed... URL: