Project

General

Profile

Actions
Copy link

Task #3508

closed

[ndncon] Chronosync misconfiguration leads to extensive CPU usage for ndncon and NFD

Added by Peter Gusev about 8 years ago. Updated about 8 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Start date:
03/04/2016
Due date:
% Done:

100%

Estimated time:

Description

Observed behavior:

  1. Start producer(s) on REMAP hub
  2. Start ndncon connected to REMAP
  3. Create chat
  4. Wait for some time

Result:
NFD and ndncon CPU usage ramps up to 80% and 100% accordingly.

Problem description by Zhehao:

Given the current implementation, a problematic case could be when sync broadcast interest brings back data that does not result in digest root update (though this, by design, should not happen), and the same interest would be sent again, bringing back the same data thus causing the same interest to be sent again with no interval, and quickly flooding (only) the local NFD. The spike would go away after one sync data times out.
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. Similar logic exists in my discovery.
Our previous (deterministic) spike issue, caused by unintended namespace conflict, is the same thing: essentially a different application is able to answer a sync interest with data that does not make sense, thus causing the sync interest sender to instantly retransmit the same interest, and floods its local NFD.
(So as a side note, if anyone in the call today's using a version of NdnCon before your update, this spike should happen for someone else in the call; assuming that everyone has the update, I'll still need to figure out the exact scenario that can cause this.)

The issue was considered to be resolved with this commit. Though it was observed again right before the 3/2/2016 seminar. Need to check again.

Actions
Copy link

Also available in: Atom PDF