Feature #4219
closedContentStore hit/miss counters
100%
Description
Provide counters for CS hits and CS misses.
They are useful for understanding the effectiveness of in-network caching for deployed applications.
This issue includes:
- Determine whether these counters belong to ForwarderStatus or Content Store manager (#4050).
- Update Management protocol.
- Modify ndn-cxx and NFD according to protocol.
Updated by Alex Afanasyev over 7 years ago
The first commit should simply introduce the corresponding signals, which will allow ndnSIM to finally implement CS stats.
I will (minor) vote for a separate CS status dataset, as it may be not just a number, but a number per different prefixes (e.g., if someone requested per-prefix tracking; either run-time or config-time setting). This feature was requested several times, but we never implemented in ndnSIM.
Updated by Davide Pesavento over 7 years ago
- Related to Feature #4050: Content Store Manager added
Updated by Junxiao Shi about 7 years ago
- Status changed from New to In Progress
- Assignee set to Junxiao Shi
- Target version set to v0.6
- % Done changed from 0 to 20
https://gerrit.named-data.net/4166 exports the counters from Forwarder
.
Updated by Junxiao Shi about 7 years ago
- % Done changed from 20 to 30
CsMgmt rev1 has the protocol design for exposing the counters in management.
Updated by Davide Pesavento about 7 years ago
ControlCommand management-module: fib
Is "fib" intended or a typo?
Updated by Junxiao Shi about 7 years ago
- Target version changed from v0.6 to v0.7
Is "fib" intended or a typo?
Corrected in CsMgmt rev2. TLV-TYPE numbers are assigned as well.
Updated by Junxiao Shi almost 7 years ago
- % Done changed from 30 to 40
https://gerrit.named-data.net/4362 encode/decode CS Information dataset
Updated by Junxiao Shi almost 7 years ago
I renamed CsStatus
to CsInfo
in CsMgmt to better match the dataset name.
Updated by Davide Pesavento almost 7 years ago
Junxiao Shi wrote:
I renamed
CsStatus
toCsInfo
in CsMgmt to better match the dataset name.
It would be more sensible to do the reverse and call everything *Status
for consistency.
Updated by Junxiao Shi almost 7 years ago
Updated by Davide Pesavento almost 7 years ago
Junxiao Shi wrote:
It would be more sensible to do the reverse and call everything
*Status
for consistency.No. CS behavior configuration, to be added in #4050, is not "status".
Seems like a completely arbitrary distinction to me. I don't see any practical differences between "status" and "info" in this context.
Updated by Junxiao Shi almost 7 years ago
"status" is more dynamic. "info" is more static. The planned fields are mostly dynamic, so I'd use "info" as the majority of this dataset belong to "info".
Updated by Junxiao Shi almost 7 years ago
- % Done changed from 40 to 70
https://gerrit.named-data.net/4423 implements NFD management side of the protocol.
4423,1 test log:
$ nfd-start
$ ndnpingserver /A &
$ ndnping -i 1 -c 1000 -n 20000 /A
$ ndnping -a -i 1 -c 1000 -n 20000 /A
$ ndnping -a -i 1 -c 1000 -n 20000 /A
$ ndnpeek -fp /localhost/nfd/cs/info | hexdump -C
00000000 80 08 81 02 07 d0 82 02 03 f8 |..........|
0000000a
Explanation:
- First
ndnping
command causes 20000 CS misses, and makes the CS cache 1000 Data. - Second and third
ndnping
commands send Interest with same name (specified through-n
argument), and cause 2000 CS hits. ndnpeek
command retrieves the dataset, which indicates 2000 hits and 1016 misses. The additional 16 misses come from management commands.
Updated by Junxiao Shi almost 7 years ago
- Status changed from In Progress to Code review
- % Done changed from 70 to 100
https://gerrit.named-data.net/4428 nfdc cs info
command.
The dataset is also included in nfdc status report
.
Updated by Junxiao Shi almost 7 years ago
- Status changed from Code review to Closed