UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/603.2.4 (KHTML, like Gecko) Version/10.1.1 Safari/603.2.4

Steps to reproduce the problem:
1. I have customized dash.js that is reporting observed bandwidth inside dash.js during playing the video.
2. I tried two things. One is throttling bandwidth through chrome-remote-interface (Network.emulateNetworkConditions) and another is manual throttling setting through DevTools.  
3. From the DevTools, If I set latency 0 and download video from local host, measured bandwidth is very precise (with in +-80kbps)
4. From chrome-remote-interface, gap is very large.. for example, If i set 800kbps, measured bandwidth from dash.js player is around 650kbps. If i set 5500Kbps, measured bandwidth is under 4500Kbps. Gap between what i set and what dash.js measured seems getting larger when I set higher bandwidth. 

*Note*
Way to measure the bandwidth from dash.js
HTTP request start time/end time and size of chunk.
From this way, I got very precise bandwidth what i set from DevTools throttling.

What is the expected behavior?
I expected exact bandwidth what i set from Network.emulateNetworkConditions.
1. Is there any fundamental difference between throttling menu in DevTools and API from chrome-remote-interface?
2. Can you please explain a bit about the logic behind the seen about bandwidth throttling in Chrome? Normally server side throttling is just sending the packeting slowly. But I have no idea about application side throttling like Chrome.

What went wrong?
If Network.emulateNetworkConditions is not accurate, then it might hard to see the application's expected behavior with given bandwidth.

Did this work before? N/A 

Chrome version: 58.0.3029.110 (64-bit)  Channel: n/a
OS Version: OS X 10.12.5
Flash Version:
 

Deleted: bandwidth-compare-trace-1-chrome.png 32.6 KB

	bandwidth-compare-trace-1-chrome.png 32.6 KB View Download