[Mini-NDN] [EXT] About the Traffic Generator, nHits, nMissed and nEntries

[Leanna Vidya Yovita]

Dear Junxiao,
thank you for the explanation.
I understand now.
Related to my question no.4, ndn-traffic-client appends a sequence number,
so that the content is actually different.
Is it possible sometimes the client request the same content? how to
control it? I mean, can we control the distribution of client's request?
such as follow Zipf for exactly total X number of content/document?
it is needed to analyze the result.

Thank you in advance.

regards,
Leanna


On Mon, Mar 1, 2021 at 12:37 PM Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

> Hi Leanna
>
> I am a newbie in mini-NDN and now still try to understand it.
>> I have some question about the traffic generator and the log.
>>
>> 1. Before I generated the interest traffic in mini-NDN, I check the
>> status of CS using "nfdc cs". The nHits and nMissed is not 0. Why? I think
>> the nHits and nMissed should be 0 before any interest traffic produced.
>>
>
> NFD uses Interest-Data for internal management functionality, such as face
> creation and FIB updates. These would cause Data packets to be created and
> cached in the Content Store.
>
> 2. What is nEntries refers to? Why is the value is smaller than
>> nHits+nMissed?
>>
>
> nEntries is the number of cached packets. It cannot exceed the Content
> Store capacity.
>
> 3. I have used the traffic generator in mini-NDN (using "
>> ndn-traffic-client.conf.sample and  ndn-traffic-server.conf.sample ").  Is
>> the sample file generated the CBR request?
>>
>
> Yes, ndn-traffic-client is only capable of sending Interests at a fixed
> rate.
>
> 4. I have tried to produce interest request for 2 type of content. But
>> still, there is a lot of missed in router's Content Store. I imagine that
>> the number of missed request should be very small because the same content
>> is repeatedly requested, and it already cached in the content store (?)
>>
>
> ndn-traffic-client appends a sequence number to the end of every Interest
> name, so that each Data packet is unique and cannot have cache hit.
>
> Yours, Junxiao
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/mini-ndn/attachments/20210301/ea5ff46c/attachment.html>