TaskQueuePacedSender::MaybeUpdateStats() is intended to be called when
packets are sent or by a sequence of "scheduled" calls. There should
only be one scheduled call in flight at a time - and that one
reschedules itself if needed when it runs.
A bug however caused the "schedules task in flight" flag to
incorrectly be set to false, leading to more and more schedules tasks
being alive - eating CPU cycles.
This CL fixes that and also makes sure the queue time properly goes
down to zero before the next idle interval check, even if there are no
more packets to send.
Bug: webrtc:10809
Change-Id: I4e13fcf95619a43dcaf0ed38bce9684a5b0d8d5e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/176330
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31390}
Since locking model has been cleaned up, PacingController can now call
PacketRouter directly - without having to go via PacedSender or
TaskQueuePacedSender.
Bug: webrtc:10809
Change-Id: I181f04167d677c35395286f8b246aefb4c3e7ec7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175909
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31342}
With an optional parameter this allows the task-queue based paced
sender to mimic the old behavior and coalesce sending of packets in
order to reduce thread wakeups and provide opportunity for batching.
This is done by simply overriding the minimum time the thread should
sleep. The pacing controller will already handle the "late wakup" case
and send any packets as if it had been woken at the optimal time.
Bug: webrtc:10809
Change-Id: Iceea00693a4e87d39b0e0ee8bdabca081dff2cba
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175648
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31328}
The TaskQueuePacedSender today has some inefficiencies:
* Enqueuing a packet will trigger a MaybeProcessPackets() call, but it
won't actually run immediately even if it should - instead it will
schedule a new call in at least 1ms. This incurs delays and extra
CPU overhead.
* Sometimes thread wakeups are scheduled simply in order to do
book-keeping: ProcessPackets() will be called when the media debt has
gone down to 0 even if there is no packet in the queue, in order to
check if we should send padding.
This CL fixes that by called ProcessPackets() immediately if it is
actually time to do so, and by immediately determining when padding
should be sent without having a separate call to drain media debt.
Bug: webrtc:10809
Change-Id: I4870e86e6de2ce4197463fd5b788ad4717fc7177
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/172842
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31010}
This is in preparation of an upcoming CL that will propagate this
information through the TransportFeedbackAdapter.
Bug: webrtc:10932
Change-Id: Ic2a026b5ef72d6bf01e698e7634864fedc659b4e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168220
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30476}
This change renames TimeController's Sleep method to AdvanceTime, unifying
the same name with the same semantic as for downstream projects.
Bug: webrtc:11154
Change-Id: Id79bcf0eafcd0b47a76407ba220479d84df5a736
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/161092
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29989}