Background:
https://crrev.com/c/978607 updated TaskManager to get network traffic info from WebContentsObserver, which may be helpful for tracking resource load start and end time.
See nick@'s comments:
https://crrev.com/c/978607/11/chrome/browser/task_manager/providers/web_contents/web_contents_task_provider.cc#268
```
Would it be possible to get from the network service a start and end time (or a duration) for the resource load? (addressing this comment can definitely be a follow-on CL, or we can just file a bug, but given that you're working on this right now, it seems like a good idea to come up with a plan to fix the following issue)
The code as implemented now basically credits the entire transaction to the 1-second interval containing the moment it completes. That makes sense when we are recording progress at the packet granularity, but it can result in pretty spiky statistics if the duration is much longer than 1 second. (full disclosure: IIUC, we already have this bug at TOT for uploads, per my last comment at https://bugs.chromium.org/p/chromium/issues/detail?id=125205 . The TM code assumes it's getting notified per-packet, but it's not clear to me if that's actually ever been the case. We only noticed this in testing last year.)
Let's say that the user downloads 4MB over 4 seconds in a single request, and the task manager refreshes every 1sec.
If we had continuous reporting, we could show an accurate instantaneous rate: the refreshes would show, over time, [1MB/sec, 1MB/sec, 1MB/sec, 1MB/sec, 0MB/sec]. Without it, our options are:
- report an accurate rate, but at some time-shifted delay to allow accumulation. So this would mean the Task Manager shows, over the 8 seconds from the beginning of the request, [0MB/sec, 0MB/sec, 0MB/sec, 1MB/sec, 1MB/sec, 1MB/sec, 1MB/sec, 0MB/sec].
- do what we're doing now (which gives a correct average cell value over time, but the catch-up to the average is achieved by intense spikes to rate values that may exceed the peak capacity of the network connection). The Task Manager
- do some truncation operation so that we flash the average rate for a single refresh interval [0MB/sec, 0MB/sec, 0MB/sec, 1MB/sec, 0MB/sec, 0MB/sec]). We could smear this out over a fixed number of refresh intervals -- we could attempt to show the peak data rate over the past 10 seconds.
- Just change our approach, and show a cumulative value in bytes, dropping the inaccurate time dimension.
```
Comment 1 by ant.pls...@gmail.com
, Oct 17