Bug #4179
closedChronoSync performs better without an exclude mechanism as publishing frequency increases
0%
Description
With exclude mechanism, the performance seems worse with 5 nodes and an update rate of 13/second on average across the nodes.
ChronoSync with just recovery performs better.
Few observations:
1) Exclude interest go above the Interest size (the error is caught so ChronoSync starts recovery after this) - causing delays. This should not happen for 5 nodes. This is because onSyncData sends an exclude interest indiscriminately.
2) Exclude interest have the same life time as sync interest life time (contrary to the paper)
Seems like it would it be a good idea to:
1) Not send an exclude interest if the data we got from contains nothing new
2) Shorten the exclude interest lifetime to 10s of ms
I have made the above changes in our experiment and the result then are slightly better than just recovery (without exclude mechanism)
Files
Updated by Ashlesh Gawande over 7 years ago
- File dfd.png dfd.png added
- File modified_exclude.png modified_exclude.png added
- File noexclude.png noexclude.png added
Updated by Ashlesh Gawande over 7 years ago
With exclude: https://redmine.named-data.net/attachments/751/dfd.png
With no exclude: https://redmine.named-data.net/attachments/753/noexclude.png
With modified exclude: https://redmine.named-data.net/attachments/752/modified_exclude.png
Updated by Ashlesh Gawande over 7 years ago
- File exclude_bug_fix.png exclude_bug_fix.png added
After discussion on NFD call (07/10/17), Alex suggested that bug is that ChronoSync should not process exclude interest. Exclude interests are meant to get data from caches. After disabling processing of a received interest if it has an exclude filter the results are better than the one without exclude.
I no longer observe exclude interests going above max size.
Updated by Ashlesh Gawande over 7 years ago
- Related to Bug #4209: ChronoSync should not process exclude interests added