https://redmine.named-data.net/https://redmine.named-data.net/favicon.ico?14759811232016-03-04T11:54:25ZNDN project issue tracking systemndnrtc - Task #3508: [ndncon] Chronosync misconfiguration leads to extensive CPU usage for ndncon and NFDhttps://redmine.named-data.net/issues/3508?journal_id=147402016-03-04T11:54:25ZAnonymous
<ul></ul><blockquote>
<p>For example, in ChronoSync2013 in ndn-cpp's onData, if the update call does not cause update in root digest, the same interest gets issued again instantly.</p>
</blockquote>
<p>Zhehao or Peter: The update call returns false if it didn't update the digest tree. Should we simply change onData to delay re-sending the interest in this case? (Normally this shouldn't happen, so I think the delay is OK.)</p>
ndnrtc - Task #3508: [ndncon] Chronosync misconfiguration leads to extensive CPU usage for ndncon and NFDhttps://redmine.named-data.net/issues/3508?journal_id=147422016-03-04T12:04:07ZZhehao Wangwangzhehao410305@gmail.com
<ul></ul><p>Jeff Thompson wrote:</p>
<blockquote>
<blockquote>
<p>For example, in ChronoSync2013 in ndn-cpp's onData, if the update call does not cause update in root digest, the same interest gets issued again instantly.</p>
</blockquote>
<p>Zhehao or Peter: The update call returns false if it didn't update the digest tree. Should we simply change onData to delay re-sending the interest in this case? (Normally this shouldn't happen, so I think the delay is OK.)</p>
</blockquote>
<p>Makes sense to me as a quick fix for unintentional local NFD floods; <br>
We'll play without the change to test this issue, to make sure it's what we thought it is.</p>
ndnrtc - Task #3508: [ndncon] Chronosync misconfiguration leads to extensive CPU usage for ndncon and NFDhttps://redmine.named-data.net/issues/3508?journal_id=147442016-03-04T12:15:40ZAnonymous
<ul></ul><p>An obvious comment: Since we don't expect update() to return false, during testing you can update NDN-CPP to log a warning if it does.<br>
<a href="https://github.com/named-data/ndn-cpp/blob/60ea5ee1856c3b1c4eee8458325558aa2401ddb9/src/sync/chrono-sync2013.cpp#L225">https://github.com/named-data/ndn-cpp/blob/60ea5ee1856c3b1c4eee8458325558aa2401ddb9/src/sync/chrono-sync2013.cpp#L225</a></p>
ndnrtc - Task #3508: [ndncon] Chronosync misconfiguration leads to extensive CPU usage for ndncon and NFDhttps://redmine.named-data.net/issues/3508?journal_id=148242016-03-06T10:02:13ZZhehao Wangwangzhehao410305@gmail.com
<ul></ul><p>Peter and I tried to confirm and reproduce this issue on Friday, but we weren't able to using the scenario Peter described. This issue could be caused by people running an older version of NdnCon on Wed (0.7.4 or earlier), which still has the namespace collision.</p>
<p>Instead, we found that in the current version of NdnCon, users can't create chatroom if a chatroom's already discovered. This should be NdnCon specific, and could be limiting the tests that we can do for this issue.</p>
<p>Meanwhile, if anyone's running NdnCon 0.7.4 or earlier on Mar 2nd before the seminar, please let us know and upgrade NdnCon.</p>
ndnrtc - Task #3508: [ndncon] Chronosync misconfiguration leads to extensive CPU usage for ndncon and NFDhttps://redmine.named-data.net/issues/3508?journal_id=148402016-03-07T09:11:48ZPeter Gusevpeter@remap.ucla.edu
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Closed</i></li><li><strong>% Done</strong> changed from <i>50</i> to <i>100</i></li></ul><p>I'm closing this and tracking chat creation issues here <a class="issue tracker-3 status-5 priority-5 priority-highest closed" title="Task: [ndncon] A new chat can't be created is there is one already available by other user (Closed)" href="https://redmine.named-data.net/issues/3518">#3518</a>.</p>