<div dir="ltr">Hi Davide<div><br></div><div><span style="color:rgb(38,50,56);font-family:Roboto,sans-serif;font-size:13px">Thank you for your response. I would like to share what I learned when doing this experiment about buffer size. When I increase the buffer size, the throughput does increase, but only after a certain value of buffer size (say 40MB buffer for a 100MB file). From this, I believe that the performance is dependent on the file size and buffer size. </span></div><div><span style="color:rgb(38,50,56);font-family:Roboto,sans-serif;font-size:13px"><br></span></div><div><span style="color:rgb(38,50,56);font-family:Roboto,sans-serif;font-size:13px">I also tried another experiment where I disabled tc in TCP/IP stack and transferred the same files. The throughput of TCP has decreased almost to the same amount as NFD. Does NFD use tc? Sorry if the question sounds silly, but I just want to be sure whether tc layer might be the cause?</span></div><div><span style="color:rgb(38,50,56);font-family:Roboto,sans-serif;font-size:13px"><br></span></div><div><span style="color:rgb(38,50,56);font-family:Roboto,sans-serif;font-size:13px">Thanks and regards</span></div><div><span style="color:rgb(38,50,56);font-family:Roboto,sans-serif;font-size:13px">Athreya H N</span></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 17, 2020 at 4:45 AM Davide Pesavento <<a href="mailto:davidepesa@gmail.com">davidepesa@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The buffer size used by ethernet faces was recently increased to 4<br>
MiB. You may want to play around with that number and see how it<br>
affects latency and throughput. The setting is currently hardcoded so<br>
you need to recompile NFD every time you change it:<br>
<a href="https://github.com/named-data/NFD/blob/fb034219ef91ecea6a104bbaaa9310b16c40c977/daemon/face/pcap-helper.cpp#L55" rel="noreferrer" target="_blank">https://github.com/named-data/NFD/blob/fb034219ef91ecea6a104bbaaa9310b16c40c977/daemon/face/pcap-helper.cpp#L55</a><br>
Note, however, that if the buffer is too small you will incur higher<br>
packet loss in case of, say, bursty traffic.<br>
<br>
Davide<br>
<br>
On Wed, Jan 8, 2020 at 11:47 AM Athreya Nagaraj <<a href="mailto:indiathreya92@gmail.com" target="_blank">indiathreya92@gmail.com</a>> wrote:<br>
><br>
> Hi<br>
><br>
> I'm not using fixed-size pipeline because it won't collect rtt information. So I changed the cubic class such that if cwnd value goes over 15, it won't increase further.<br>
><br>
> I'm using face type ethernet. I've pulled the latest code of ndn-cxx, NFD and ndn-tools from git just a few days back and built it.<br>
><br>
> On Wed, 8 Jan 2020 at 9:50 PM, Davide Pesavento <<a href="mailto:davidepesa@gmail.com" target="_blank">davidepesa@gmail.com</a>> wrote:<br>
>><br>
>> What do you mean by "limiting the value of interest pipeline"? Are you<br>
>> using the fixed-size pipeline with ndncatchunks?<br>
>><br>
>> Also, what is the type of the face between the Pis? Ethernet or UDP?<br>
>> And what versions of ndn-tools and NFD are you using?<br>
>><br>
>> Thanks,<br>
>> Davide<br>
>><br>
>> On Wed, Jan 8, 2020 at 7:45 AM Athreya Nagaraj <<a href="mailto:indiathreya92@gmail.com" target="_blank">indiathreya92@gmail.com</a>> wrote:<br>
>> ><br>
>> > Hello all<br>
>> ><br>
>> > I have got an update and another question on this topic. I have reduced the test-bed size to two RPis. one being the producer and the other being the consumer. I figured out that by limiting the value of interest pipeline to around 15, the RTT decreases substantially enough to match the performance of TCP (without reducing throughput). However, I'm curious as to why this might be happening and are there any changes I can do to the configuration to keep the interest pipeline value over 100 and still have the same performance.<br>
>> ><br>
>> > My wild guess about this might be due to the buffer size. So regarding this, I have a question. When the ndn-cxx library writes the segment to the NIC buffer, will it write the contents of the segment or does it store a pointer to it in the queue? It would be great if someone can point me towards where this is implemented in ndn-cxx library or NFD.<br>
>> ><br>
>> > Thanks in advance<br>
>> > Athreya H N<br>
>> ><br>
>> > On Thu, Jan 2, 2020 at 10:17 PM Athreya Nagaraj <<a href="mailto:indiathreya92@gmail.com" target="_blank">indiathreya92@gmail.com</a>> wrote:<br>
>> >><br>
>> >> No. I've not increased the interest lifetime. Is there any other possible cause of such a high max rtt value?<br>
>> >><br>
>> >> On Thu, 2 Jan 2020 at 10:07 PM, Davide Pesavento <<a href="mailto:davidepesa@gmail.com" target="_blank">davidepesa@gmail.com</a>> wrote:<br>
>> >>><br>
>> >>> Actually, ndncatchunks does not take RTT measurements for<br>
>> >>> retransmitted segments. So a max RTT of more than 27 seconds looks<br>
>> >>> very suspicious to me, unless you also increased the Interest<br>
>> >>> lifetime.<br>
>> >>><br>
>> >>> Davide<br>
>> >>><br>
>> >>> On Thu, Jan 2, 2020 at 11:09 AM Lan Wang (lanwang) <<a href="mailto:lanwang@memphis.edu" target="_blank">lanwang@memphis.edu</a>> wrote:<br>
>> >>> ><br>
>> >>> > I assume the min RTT 4.777ms is closer to the actual RTT.   The RTT measurements from catchunks include the timeouts and retransmissions, so you can see the average and max are much larger.<br>
>> >>> ><br>
>> >>> > Lan<br>
>> >>> ><br>
>> >>> > On Dec 30, 2019, at 11:25 PM, Athreya Nagaraj <<a href="mailto:indiathreya92@gmail.com" target="_blank">indiathreya92@gmail.com</a>> wrote:<br>
>> >>> ><br>
>> >>> > Hi Lan<br>
>> >>> ><br>
>> >>> > Thank you for your response.<br>
>> >>> ><br>
>> >>> > Please find below the output of ndncatchunks during one of the experiments-<br>
>> >>> ><br>
>> >>> > All segments have been received.<br>
>> >>> > Time elapsed: 55.1154 seconds<br>
>> >>> > Segments received: 23832<br>
>> >>> > Transferred size: 104858 kB<br>
>> >>> > Goodput: 15.220085 Mbit/s<br>
>> >>> > Congestion marks: 69 (caused 5 window decreases)<br>
>> >>> > Timeouts: 414 (caused 5 window decreases)<br>
>> >>> > Retransmitted segments: 347 (1.43513%), skipped: 67<br>
>> >>> > RTT min/avg/max = 4.777/144.127/27253.940 ms<br>
>> >>> ><br>
>> >>> > On Mon, Dec 30, 2019 at 11:50 PM Lan Wang (lanwang) <<a href="mailto:lanwang@memphis.edu" target="_blank">lanwang@memphis.edu</a>> wrote:<br>
>> >>> >><br>
>> >>> >> How did you measure the RTT during the catchunks transfer?  Maybe you can send the catchunks output (or at least part of it)?<br>
>> >>> >><br>
>> >>> >> Lan<br>
>> >>> >><br>
>> >>> >> On Dec 29, 2019, at 9:58 PM, Athreya Nagaraj via Ndn-interest <<a href="mailto:ndn-interest@lists.cs.ucla.edu" target="_blank">ndn-interest@lists.cs.ucla.edu</a>> wrote:<br>
>> >>> >><br>
>> >>> >> Hi all<br>
>> >>> >><br>
>> >>> >> I have used the term 'bus topology', which is wrong. The topology I have used is 4 raspberry pi devices connected via 3 point-to-point links in a linear fashion. I've attached a representative topology diagram. I apologize for my mistake.<br>
>> >>> >><br>
>> >>> >> Thanks and Regards<br>
>> >>> >> Athreya H N<br>
>> >>> >><br>
>> >>> >> On Sun, Dec 29, 2019 at 10:39 PM Athreya Nagaraj <<a href="mailto:indiathreya92@gmail.com" target="_blank">indiathreya92@gmail.com</a>> wrote:<br>
>> >>> >>><br>
>> >>> >>> Hi all<br>
>> >>> >>><br>
>> >>> >>> I'm a student working on a testbed of NDN. The testbed consists of four raspberry pi connected in a bus topology. The two end devices act as producers and consumers for NDN data. The middle two devices act as routers. I use ndncatchunks to send a 100 MB file through the testbed. I observe that the RTT for this is significantly more (around 10 times more) than that for an FTP application on the same testbed. The throughput is also lesser compared to FTP (around 20% lesser for NDN). I was wondering what could cause this difference.<br>
>> >>> >>><br>
>> >>> >>> Also, another observation I made was that when I was testing the testbed setup with ndnping, the RTT was not so high.<br>
>> >>> >>><br>
>> >>> >>> I have also previously worked on similar topology with NDN and the machines used were desktop machines. In this case, NDN was better than FTP.<br>
>> >>> >>><br>
>> >>> >>> Any thoughts on what could be causing this?<br>
>> >>> >>><br>
>> >>> >>> Thanks and Regards<br>
>> >>> >>> Athreya H N<br>
>> >>> >><br>
>> >>> >> <Untitled Diagram.png>_______________________________________________<br>
>> >>> >> Ndn-interest mailing list<br>
>> >>> >> <a href="mailto:Ndn-interest@lists.cs.ucla.edu" target="_blank">Ndn-interest@lists.cs.ucla.edu</a><br>
>> >>> >> <a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" rel="noreferrer" target="_blank">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a><br>
>> >>> >><br>
>> >>> >><br>
>> >>> ><br>
>> >>> > _______________________________________________<br>
>> >>> > Ndn-interest mailing list<br>
>> >>> > <a href="mailto:Ndn-interest@lists.cs.ucla.edu" target="_blank">Ndn-interest@lists.cs.ucla.edu</a><br>
>> >>> > <a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" rel="noreferrer" target="_blank">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a><br>
>> >><br>
>> >> --<br>
>> >> Regards,<br>
>> >> Athreya H N<br>
><br>
> --<br>
> Regards,<br>
> Athreya H N<br>
</blockquote></div>