Task #3485
open
Prep for March 2 seminar with NDN-RTC
100%
Description
Christos will give the next seminar on March 2. Anyone at ColoState that might be able to provide support to him in running both NDN-RTC and WebEx at the same time? Peter, can you follow up with Christos and Steve as a starting point, and try to push a new version of NDN-RTC with any things that we want to test? Suggest to provide only one bandwidth option for each stream, so we see uniform requests across all nodes.
Files
| ingest-res-usage.py (10.7 KB) ingest-res-usage.py | |||
| scr.png (1.51 MB) scr.png | |||
| seminar.jpg (86.5 KB) seminar.jpg | |||
| NDNRTC_seminar_Mar_02.png (339 KB) NDNRTC_seminar_Mar_02.png |
Updated by Jeff Burke over 8 years ago
- Assignee set to Peter Gusev
Peter, please update after the seminar, then close it... And, point to where open issues for March 2 are tracked.
Updated by Peter Gusev over 8 years ago
- Status changed from New to In Progress
Updates:
Susmit will try to publish using ndncon, conference bridge will be established with WebEX by me.
Initial plan is to have 4 hubs (CSU, WU, REMAP, UCLA) with at most 2 users per hub (spot can be reserved here).
Updated by Peter Gusev over 8 years ago
So based on our testing today w/ Chengyu I’d like to clarify these steps for publishing using ndncon with WebEX bridging:
Testbed connection:
should be UDP only (TCP connection performs unacceptably poorly for ndncon):
$ nfdc register / udp://<home hub hostname or IP>make sure your home hub has created a backroute towards your machine’s IP address, this makes you discoverable
to check this, go to your hub’s status webpage and look for your IP address in faces table; then, use located face ID to check it appears in FIB entries for /ndn/broadcast and <home hub prefix> routes
!!! if hub didn’t created a backroute - contact John DeHart or me immediately so that we can help fixing it
Configure ndncon to have 1 audio stream and 1 screen stream:
- remove all other streams by clicking on “X” for corresponding stream panel
your screen stream should have just one thread:
“mid” (700Kbps) thread is enough for demonstrating slides. remove all other threads by clicking on “X” for corresponding thread panel.
Make sure you see user “confbridge” and group chat “confbridge”
- if you don’t see them, check your Testbed connection (see above)
Join chat “confbridge”:
make sure that option “Auto-fetch media from joining users:” has at least audio selected (highlighted in blue)
this way, audio streams from the users who joins this chat will be fetched automatically
Start publishing your streams
You should be now accessible on ndncon and WebEX.
Updated by John DeHart over 8 years ago
Peter: After a user does the 'nfdc' they need to do an 'ndnping', right?
Updated by Peter Gusev over 8 years ago
John DeHart wrote:
Peter: After a user does the 'nfdc' they need to do an 'ndnping', right?
Not necessarily if the ndncon is running - it issues interests every two second for discovery.
But in general, yes - ndnping will ensure creating a backroute.
I'll create a checklist for ndncon publishers later and mention this.
Updated by Peter Gusev over 8 years ago
- File ingest-res-usage.py ingest-res-usage.py added
Here's the python script attached one can use to send ndncon and NFD CPU and memory usage to my "ndncon monitor&analysis server" that I plan to use for large scale tests in June.
- to run the script:
$ sudo pip install influxdb
$ python ingest-res-usage.py ingest-res-usage.py --host=ec2-52-91-190-26.compute-1.amazonaws.com \
--influx-adaptor --iuser=ingest --ipassword=1ng3st --idb=db_resources \
--username=<username> --hub=<home hub>
username and home hub should be set accordingly to the ndncon username and home hub used (for example, peter and remap)
- go to dashboard to observe current usage; user guest password ndnguest
Updated by Peter Gusev over 8 years ago
I sketched up a quick bootstrap checklist for ndncon user. Plan to publish it on ndncon's wiki soon. Let me know if I miss anyting.
- □ get the latest NFD
- □ configure NFD
- □ get the latest ndncon
- □ choose your home hub on NDN testbed, note your home hub's prefix (further: home prefix)
- □ start NFD
- □ start ndncon
- □ enter your ndncon username and your home prefix as a publishing prefix in ndncon's Preferences > General
□ register UDP tunnel to your home hub:
$ nfdc register / udp://<home hub ip or hostname>□ make sure a backroute was created on your home hub
go to your home hub status web page, look for your IP address in "Faces" and then lookup corresponding face id in FIB entries; this face id should be found at least in /ndn/broadcast and <home prefix> FIB entries
if backroute was not created, try running
$ ndnping <home prefix>and see if it helped; if it didn't help, contact Peter Gusev or John DeHart□ check that you see test producers (/ndn/edu/ucla/remap/freeculture and/or /ndn/edu/ucla/remap/test) in "Active users" of the main ndncon window; if you don't see any, contact Peter Gusev
□ test joining a group chat "freechat"; if you don't see a group chat, contact Peter Gusev
Updated by Peter Gusev over 8 years ago
- File scr.png scr.png added
- File seminar.jpg seminar.jpg added
- Status changed from In Progress to Closed
- % Done changed from 0 to 100
here's a brief summary on today’s test, some results I have gathered and my thoughts/ideas for the next week.
comments:
- Susmit didn’t present through ndncon today as was planned; the reason for that - CSU hub he supposed to be using stopped creating backroutes and we had very little time to fix it before seminar; he resorted to WebEX eventually
- even though Susmit was using WebEX, I still set up a conference bridge which published WebEX video using ndncon so that ndncon users could fetch it
- I counted about 5 active users today (maybe +1 is Josh was fetching) fetching audio+video from confbridge.
- not all of them were publishing their streams though; in fact just me and occasionally Alex, so these streams were also fetched by confbridge user (thus contributed to overall traffic) and audio was passed on to WebEX (when I talked today, it was through ndncon)
summary:
- I was connected to REMAP hub and in the beginning, audio was quite choppy. video was ok, but it’s mainly due to its’ static nature (slides) - i didn’t miss any slides nevertheless.
- few users on UCLA hub reported choppy audio as well (Haitao and Alex)
- JeffT (WU) was experiencing choppy audio often; @JeffT, please share your experience if you’d like
- once Alex dropped (around 10-15min from the beginning of the seminar) , Haitao reported much better audio for him; I noticed that audio improved for me as well
- till the rest of the seminar, I experienced few short audio interruptions (once in 1-2min for 0.5-1sec long); it didn’t prevent me from understanding the content
here is the gathered CPU and memory usage for the users participating in ndncon test - http://ec2-52-91-190-26.compute-1.amazonaws.com:3000/dashboard/db/seminar-3-2-2016-overview (use login: guest, pw: ndnguest if needed); feel free to explore.
- one can see that Alex was experiencing raging NFD CPU usage during his first 10-15min until he restarted NFD; ndncon CPU usage wasn’t that high though;
- NFD resident memory tends to be around 700-900Mb for all users
- one can notice ndncon memory grows slowly over time (~20Mb per hour); we’ll look at that (though priority isn’t high for now) 0 average ndncon CPU usage for fetching 1 audio and 1 video stream is around 40% (but depends on the machine of course)
next seminar:
- I’ll continue improving monitoring tool as my time allows (see real-time statistics here, login:guest pw:ndnguest) and will think of adding some internal core metrics for NDN-RTC (like number of streams fetched, chasing times, number of rebufferings, etc.)
- we should clarify for ourselves few things (please add any):
- why NFD CPU usage was raging or spiked sometimes (especially for Alex’s machine)?
- JeffT may have experienced problems due to changes in traffic routes (@JeffT, please confirm), should we test/confirm that?
- is there a correlation b/w degraded ndncon experience and metrics gathered by John DeHart?
Updated by John DeHart over 8 years ago
I was monitoring the bandwidth usage during the ndnrtc seminar yesterday.
I'd like to try to understand some of the things I saw.
I have included a screen shot of ndnmap to show a snapshot of what was going on.
What I am curious about is why, after Josh left we were still seeing
traffic going around the UCLA/UCI/CAIDA triangle and why we see the
traffic from WU-UM-MICH-CSU?
Is this because the strategy is searching for a new path?
Updated by Peter Gusev over 8 years ago
Just to confirm - John were you also fetching being connected to WU?
In that case, I think WU-UM-MICH-CSU traffic can be explained by NFD treating one of the consumer's Interests as retransmissions and trying other different faces: i.e. there's a default retransmission suppression of 10ms (Junxiao can confirm on whether it has been changed since the last time we talked at NDNComm 2015) - when multiple consumers are present and are in "fetching" mode (synchronized to the producer), they issue roughly same Interests, though these Interests can be easily timed with more than 10ms difference, thus NFD treats them as retransmissions and tries different faces.
I guess @Junxiao can shed more light on that.
Updated by Peter Gusev over 8 years ago
@John, @Junxiao asked (NFD call 3/3/2016) whether we have CPU usage info of UCLA hub for the period @Alex had raging NFD CPU usage during 3/2/2016 Seminar (it's time range b/w/ 2:03 and 2:15pm)?
Updated by Anonymous over 8 years ago
JeffT may have experienced problems due to changes in traffic routes.
I was connected to WU and watching the traffic map. Normally the traffic from REMAP went through CSU and UIUC. When the seminar audio dropped, I noticed this path was dark and I saw some traffic from CSU through MICH. I don't know how to test the cause of this (Interests not getting through or return Data blocked.)
Also, I never saw traffic through UA, even though it looks like it should be a good route to WU. Any idea why?
Updated by John DeHart over 8 years ago
Yes, I was connected to WU.
I also found it curious that UA was never used but it could be because the cost of the path from WU-UA-REMAP (58) is
higher than the cost on the path WU-UIUC-CSU-REMAP (39) and then on the way along that path it finds
the data at CSU.
But it seems like it should have tried that path sometimes. I'll check to see if there
is anything wrong with UA.
Updated by John DeHart over 8 years ago
Peter Gusev wrote:
@John, @Junxiao asked (NFD call 3/3/2016) whether we have CPU usage info of UCLA hub for the period @Alex had raging NFD CPU usage during 3/2/2016 Seminar (it's time range b/w/ 2:03 and 2:15pm)?
Unfortunately, I am not collecting CPU load data yet. I'll add that next.
Updated by Peter Gusev about 8 years ago
- Status changed from Feedback to Resolved