Webrtc datachannels have >1000ms roundtrips sometimes
Reported by
danielva...@gmail.com,
May 9 2016
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0 Example URL: Steps to reproduce the problem: 1. Setup a webrtc connection between two separate devices 2. Let one device start with sending a message 3. Let the other device send a reply as soon as it receives the message and at least 70ms passed. 4. Do the same as step 3 for the first device 5. Keep repeating step 3 and 4. I tested it on two chrome browsers on two laptops connected to the same network using wifi. What is the expected behavior? Since each device will send a packet every ~70ms, the time between receiving every two packets is expected to be ~70ms. What went wrong? Sometimes the time between two received packets is more than 1000ms. When logging the timings for 2100 received packets, these were the 26 timings that were longer than 900ms: [1762.6050000000014, 1179.7200000000012, 1765.375, 1149.945000000007, 1180.1399999999994, 1180.9550000000017, 1246.2450000000026, 1750.2649999999994, 1388.0149999999994, 1100.7499999999854, 4130.475000000006, 1160.1150000000052, 1082.4399999999878, 1055.2300000000105, 1498.715000000011, 1105.8850000000093, 1478.1600000000035, 2948.649999999994, 1538.2549999999756, 1839.9099999999744, 1768.6449999999895, 1167.929999999993, 1139.1750000000175, 1173.8850000000093, 1245.6600000000035, 1075.375] Attached is a PacketsSentPerSecond graph for this test for one of the devices. Did this work before? N/A Chrome version: 50.0.2661.94 (Official Build) m (32-bit) Channel: n/a OS Version: 10.0 Flash Version: Shockwave Flash 21.0 r0 * I kept the tab in both browsers open for the whole test, so this has nothing to do with the extra delay for window.setTimeout for inactive tabs. * Similar behavior is found in Firefox * When doing the same test in 2 browser windows on the same device, there are no delayed packets. So it doesn't seem to have anything to do with garbage collection. * When sending packets without waiting for received packets, the >1000ms delays are NOT measured.
,
May 10 2016
Thanks for your reply. I have been testing it with both devices on a different network using tethering on my phone, where I had the same >1000ms drops, although less often. So I don't think it has anything to do with the network. For now I have a workaround. My application requires the peers to send messages in turn, but as said the problem does not occur when continuously sending each other packets. So I now simply send packets at a steady rate, EVEN when they are empty. This works. My best guess for the cause of the problem is that when I let the peers wait for each other, the rate of packets is not always steady, causing some flow control to make things even slower?
,
May 11 2016
Thank you for providing more feedback. Adding requester "mattm@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 13 2016
Assigning to pthatcher, though I'm not sure he or his team will be able to make much progress without a packet capture or access to the application in question.
,
Jul 18 2016
,
Nov 8 2016
,
Apr 3 2018
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by mattm@chromium.org
, May 9 2016Labels: Needs-Feedback