Using nethogs to monitor bandwidth usage, and using epiphany to display the main page of YouTube
-- with no video playing.
Placing the mouse cursor in the browser address bar causes a normal surge in bandwidth, that quickly calms down to less than 100KB. Placing the cursor in the search bar causes a surge to 1M or more, and the bandwidth does not subside.
Here is a grid of the various ways I tested the bug.
Client Server OpenGL Encoding Bug reproduced ------ ------ ------ -------- -------------- 0.15.0 Windows 8.1 VM 0.14.7 Fedora 20 VM no jpeg yes 0.15.0 Windows 8.1 VM 0.14.7 Fedora 20 VM no h264 no 0.14.7 Fedora 20 VM 0.14.7 Fedora 20 VM no jpeg yes 0.14.9 Fedora 20 VM 0.14.9 Fedora 20 VM no jpeg yes 0.14.9 Fedora 20 VM 0.14.9 Fedora 20 VM no h264 yes 0.14.9 Fedora 20 VM 0.14.9 Fedora 20 VM yes jpeg client crashes - cannot test 0.14.9 Fedora 20 VM 0.14.9 Fedora 20 VM yes h264 yes (transparency issues, cursor doesn't display) 0.15.0 Fedora 20 VM 0.15.0 Fedora 20 VM no jpeg yes 0.15.0 Fedora 20 VM 0.15.0 Fedora 20 VM no h264 yes 0.15.0 Fedora 20 VM 0.15.0 Fedora 20 VM yes jpeg client crashes - cannot test 0.15.0 Fedora 20 VM 0.15.0 Fedora 20 VM yes h264 yes (transparency issues, cursor doesn't display) 0.14.9 Fedora 20 0.14.9 Fedora 20 no jpeg no 0.14.9 Fedora 20 0.14.9 Fedora 20 no h264 no 0.14.9 Fedora 20 0.14.9 Fedora 20 yes jpeg no 0.14.9 Fedora 20 0.14.9 Fedora 20 yes h264 no 0.15.0 Fedora 20 0.15.0 Fedora 20 no jpeg no 0.15.0 Fedora 20 0.15.0 Fedora 20 no h264 no
client crashes - cannot test
Please create a blocker ticket for this one.
Using nethogs to monitor bandwidth usage
BTW, does that match (more or less) the bandwidth information shown on session info?
Placing the cursor in the search bar causes a surge to 1M or more, and the bandwidth does not subside
Please provide -d encoding
debug output so we can see what it is encoding. It could also be auto-refresh related, so -d refresh
is also worth trying.
And try to narrow it down by changing the encodings
list and figuring out what is different between the Fedora 20 and the VM case. (which one matters: server or client?)
FWIW: I've briefly tried it, I had to use vglrun to be able to launch epiphany on my system, so it looks like it uses opengl for rendering to the vfb. No sign of the bug.
client crashes - cannot test
Please create a blocker ticket for this one.
Blocker bug #717 has been created.
Using nethogs to monitor bandwidth usage
BTW, does that match (more or less) the bandwidth information shown on session info?
The "SENT KB/s" output of nethogs (monitoring the loopback interface) appears to match the average value shown in Session Info Graphs "recv KB/s" output. Does that sound correct?
However I did notice that the nethogs value is always about 500 or 600 KB/s higher in all cases, when the Session Info Graph window is open. Could the graph window itself be adding to the overall bandwidth?
Placing the cursor in the search bar causes a surge to 1M or more, and the bandwidth does not subside
Please provide-d encoding
debug output so we can see what it is encoding. It could also be auto-refresh related, so-d refresh
is also worth trying.
The attached encoding.log
captures the encoding filter, for a period of time from the top of the file down to about the 13:59:00 timestamp, where the cursor was in the search bar. The output after that point is all in the address bar.
I did notice that when the cursor is in the address bar, these logs stop after a while. But when the cursor is in the search bar, the logs just keep rolling and rolling.
The refresh.log
captures a few seconds in the address bar, where the screen output is png or rgb32, then a good stretch of time in the search bar when the output changes to wepb, then a short period of time back in the address bar, at the end of the output.
And try to narrow it down by changing the
encodings
list and figuring out what is different between the Fedora 20 and the VM case. (which one matters: server or client?)
The one thing I noticed between the full and VM versions of Fedora, is that on the VM, the encodings in the refresh output show that png is used while in the address bar, and changes to webp in the search bar. At least when I captured the log that was the case. The next time I tried it, using the same encodings list, it was always png, regardless of the position of the cursor.
But in full Fedora where the bug can't be reproduced, webp is used when the cursor is in the address bar, and rgb32 is used in the search bar.
One other possible clue, is that on the machine where I could repro the bug, the bandwidth increase occurs when the cursor is blinking, but if I put text in the search bar then select the text, the bandwidth goes down (possibly because selecting text causes the blinking cursor to disappear).
The "SENT KB/s" output of nethogs (monitoring the loopback interface) appears to match the average value shown in Session Info Graphs "recv KB/s" output. Does that sound correct?
Yes.
However I did notice that the nethogs value is always about 500 or 600 KB/s higher in all cases, when the Session Info Graph window is open. Could the graph window itself be adding to the overall bandwidth?
Yes it does. It requests information from the server, which uses more bandwidth. It could be trimmed a little I suppose.
Now, from the log I am reading, it looks like epiphany is repainting most of the window 4 times per second, in pairs of events about 40ms apart:
damage(0, 45, 748, 312, {}) wid=3, sending now with sequence 8794
That's a pretty big update: 748x312 pixels, especially if the window contents haven't actually changed. There isn't much we can do to prevent applications from telling us to repaint when it isn't needed. I guess that what we could do is raise the maximum size used for delta compression. As doing a delta between those unchanged screen updates should give us an empty result, which we can either skip (would require some new code to detect) or just send empty (as it will compress extremely well).
A better solution would be to fix epiphany so it doesn't repaint when it isn't needed.
I am lowering the priority of this ticket and changing it to an enhancement, because it doesn't look like a bug on our side. Maybe just a sub-optimal automatic encoding selection for a corner case.
#756 should help with this.
Can you reduce the bandwidth by using:
XPRA_MAX_DELTA_SIZE=4000000 xpra start
We could raise the default (10000), or make it more dynamic so we only allow large deltas when the framerate is low (framerate being a difficult value to extract... video regions and all)
Unless we're sending updates that aren't coming as damage
events from the application, maybe we should just close this ticket as invalid and follow up in #756. Thoughts?
My latest attempt to reproduce this bug, using the same conditions as the test case 4 and 5 from the table at the head of this ticket, was unsuccessful. Either YouTube? has changed, or we have, or it's intermittent.
I'm closing this until further notice.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/715