Feature #3478
closedBandwidth breakdown and UI update
0%
Description
Significantly higher bandwidth than expected has been observed for streams. Please documented what to expect for a given stream (in both directions), and breakdown in percentages with its major contributions from components like packet overhead, etc. Also, you may wish to change the menu options to reflect both the media bitrate and the estimated total network traffic so people know what to expect.
Files
Updated by Peter Gusev about 9 years ago
- File a.pcapng.gz a.pcapng.gz added
Stream bandwidths¶
I ran some tests with Wireshark and OSX activity monitor. In general, OSX activity monitor isn't accurate enough and varies greatly. Here are the results:
Audio:¶
OSX:¶
- in: ~32KB/s (+/- 10 KB/s) = 256 Kbps
- out: ~8KB/s (+/- 4 KB/s)= 64 Kbps
Wireshark (ndn traffic only):¶
- in: 206 Kbps
- out: 31 Kbps
NDN-RTC statistics:¶
- i-rate (interest rate): 25
- d-rate (data segment rate): 25
- raw incoming data rate: 213 Kbps
Video (1000 Kbps video stream as configured in ndncon, 1280x720 resolution):¶
OSX:¶
- in: ~200KB/s (+/- 60 KB/s) = 1600 Kbps
- out: ~32KB/s (+/- 10 KB/s)= 64 Kbps
Wireshark (ndn traffic only):¶
- in: 1462 Kbps
- out: 232 Kbps
NDN-RTC statistics:¶
- i-rate (interest rate): 192
- d-rate (data segment rate): 150
- raw incoming data rate: 1527 Kbps
Packet anatomy¶
I took one sample Interest and one sample Data packet from the streams (see wireshark pcaps attached) and analyzed them for protocol headers.
Audio¶
Interest¶
- Eth2: 151 bytes
- NDN: 109 bytes (-42 Eth2+IP+UDP headers)
Data:¶
- Eth2: 1111 bytes
- NDN: 1069 bytes (-42 Eth2+IP+UDP headers)
- Payload: 723 bytes (2 audio samples + meta) => 346 bytes or 47.8% NDN overhead
Video¶
Interest¶
- Eth2: 156 bytes
- NDN: 114 bytes (-42 Eth2+IP+UDP headers)
Data:¶
- Eth2: 1410 bytes
- NDN: 1368 bytes (-42 Eth2+IP+UDP headers)
- Payload: 1000 bytes (video segment + meta) => 368 bytes or 36.8% NDN overhead
Updated by Jeff Burke about 9 years ago
Peter, did bandwidth usage in the March 2 test (#3485) perform as expected?
Updated by Peter Gusev about 9 years ago
We didn't have means to measure it on client sides. This will be available with #3510
Updated by Jeff Burke about 9 years ago
Ok, so we are tracking this now, right? (Can we close this issue?)