xpra icon
Bug tracker and wiki

This bug tracker and wiki are being discontinued
please use https://github.com/Xpra-org/xpra instead.


Changes between Version 3 and Version 4 of WindowRefresh


Ignore:
Timestamp:
01/15/13 15:32:12 (8 years ago)
Author:
Antoine Martin
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • WindowRefresh

    v3 v4  
    77* the video quality (for the x264 video encoder only)
    88* the video speed (for the x264 video encoder only)
     9
     10[[BR]]
    911
    1012== Code Pointers ==
     
    2224Note also that many of these classes have a {{{add_stats}}} method which is used by {{{xpra info}}} to provide detailed statistics from the command line and is a good first step for debugging.
    2325
     26[[BR]]
    2427
    2528== Background on damage request processing ==
     
    3336* {{{process_damage_region}}} (called when the timer expires - or directly) will grab the window's pixels and queue a request to call "make a data packet" from it. This is done so that we minimize the amount of work done in the critical UI thread, another thread will pick items off this queue.
    3437
     38Note: delayed regions may get delayed more than originally intended if the client has an excessive packet or pixel backlog.
     39[[BR]]
    3540The damage thread will pick items from this queue, decide what compression to use, compress the pixels and make a data packet then queue this packet for sending. Note that the queue is in {{{ServerSource}}} and it is shared between all the windows..
    3641
     
    4146* callbacks recording performance statistics
    4247* callbacks between {{{ServerSource}}} and {{{WindowSource}}}
     48* calculating the backlog
    4349* error handling
    4450* cancelling requests
     
    4652* mmap
    4753
     54[[BR]]
    4855
    4956== The Factors ==
     57Again, this is a simplified explanation, and the actual values used will make use of heuristics, weighted averages, etc. Recent vs average values, trends, etc.
     58Please refer to the source for details.
     59[[BR]]
    5060
     61From {{{ServerSource}}}:
     62* {{{client latency}}}: the client latency measured during the processing of pixel data (when we get the echo back). We know the lowest latency observed, and we try to keep the latency as low as that
     63* {{{client ping latency}}}: as above, but measured from ping packets (client)
     64* {{{server ping latency}}}: as above, but measured from ping packets (server - if available, the client sends this information as part of ping echo packets)
     65* {{{damage data queue}}}: the number of damage frames waiting to be compressed, we want to keep this low - especially as this data is uncompressed at this point, so it can be quite large
     66* {{{damage packet queue size}}}: the number of packets waiting to be sent by the network layer - we want to keep this low, but sometimes many small packets can make it look worse than it is..
     67* {{{damage packet queue pixels}}}: the number of pixels in the packet queue, the target value depends on the current size of the window
     68* {{{mmap area % full}}}: only used with mmap
     69[[BR]]
    5170
     71From {{{WindowSource}}}:
     72* {{{damage processing latency}}}: how long frames take from the moment we receive the damage event until the packet is queued for sending. This value increases with the number of pixels that are encoded. We want to keep this low.
     73* {{{damage processing ratios}}}: as above, but based on the trend: this measure goes up when we queue more damage requests than we can encode.
     74* {{{damage send latency}}}: how long frames take from the moment the damage event until the packet containing it has made it out of the network layer (it may still be in the operating system's buffers though). Again, we want to keep this low. This value increases when the network becomes the bottleneck.
     75* {{{damage network delay}}}: the difference between {{{damage processing latency}}}} and {{{damage send latency}}}, this should equal to the network latency - but because the values are running averages, it is not very reliable.
     76* {{{network send speed}}}: we keep track of the socket's performance (in bytes per second)
     77* {{{client decode speed}}}: how quickly the client is decoding frames
     78* {{{no damage events for X ms}}}: when nothing happens for a while, this means that the window is not busy and therefore we ought to be able to lower the delay
    5279
     80[[BR]]
     81Each factor provides:
     82* a textual description which can be used for debugging
     83* a change factor (float number) ranging from 0.0 (lower the delay) to a small positive number (up to 10 - generally, but that is not enforced).. A value of 1.0 means no change.
     84* a weight value: this is to measure how confident this particular factor is about the change it requests.
    5385
     86ie:
     87* with a weight of 0.0, the factor is irrelevant as it won't be counted
     88* with a high enough weight, a factor can overrule others
    5489
     90[[BR]]
    5591
     92== Debugging ==
     93"xpra info" provides a good overview of the current values used for batch delay and encoding speed/quality, but very little in terms of the factors used to come up with those values (only some latency values are exposed).
     94
     95[[BR]]
     96
     97To dump the change in "batch delay", set:
     98{{{
     99XPRA_DELAY_DEBUG=1
     100}}}
     101when starting the server. Then every 30 seconds, or every 1000 messages, the delay factors will be dumped to the log (this is done to prevent the logging itself from affecting the system and the calculations - and it still does, but much more sparsely), the log messages look like this:
     102{{{
     103update_batch_delay: wid=5, last updated 249.50 ms ago, decay=1.00s, \
     104    change factor=9.8%, delay min=5, avg=5, max=6, cur=6.7, \
     105    w. average=6.0, tot wgt=227.2, hist_w=113.6, new delay=7.4
     106}}}
     107For more details, to get the actual factors used, set:
     108{{{
     109XPRA_DELAY_DEBUG=1
     110}}}
     111Then the output should be much more verbose:
     112{{{
     113Factors (change - weight - description):
     114  -14      38  damage processing latency: avg=0.013, recent=0.013, target=0.014, aim=0.800, aimed avg factor=0.729, div=1.000, s=<built-in function sqrt>
     115 +128      15  damage processing ratios 12 - 13 / 5
     116  -25      50  damage send latency: avg=0.014, recent=0.015, target=0.030, aim=0.800, aimed avg factor=0.557, div=1.000, s=<built-in function sqrt>
     117  -65       8  damage network delay: avg delay=0.001 recent delay=0.002
     118  -65      23  client decode speed: avg=32.3, recent=32.3 (MPixels/s)
     119   +0       0  no damage events for 1.2 ms (highest latency is 100.0)
     120  -49       8  client latency: avg=0.002, recent=0.002, target=0.006, aim=0.800, aimed avg factor=0.260, div=1.000, s=<built-in function sqrt>
     121  -40       4  client ping latency: avg=0.003, recent=0.003, target=0.007, aim=0.950, aimed avg factor=0.353, div=1.000, s=<built-in function sqrt>
     122  -54       4  server ping latency: avg=0.003, recent=0.002, target=0.006, aim=0.950, aimed avg factor=0.211, div=1.000, s=<built-in function sqrt>
     123 -100       0  damage packet queue size: avg=0.000, recent=0.000, target=1.000, aim=0.250, aimed avg factor=0.000, div=1.000, s=<built-in function sqrt>
     124 -100       0  damage packet queue pixels: avg=0.000, recent=0.000, target=1.000, aim=0.250, aimed avg factor=0.000, div=90000.000, s=<built-in function sqrt>
     125  -99      20  damage data queue: avg=0.346, recent=0.033, target=1.000, aim=0.250, aimed avg factor=0.019, div=1.000, s=<built-in function logp>
     126 -100       0  damage packet queue window pixels: avg=0.000, recent=0.000, target=1.000, aim=0.250, aimed avg factor=0.000, div=90000.000, s=<built-in function sqrt>
     127}}}
     128Note: the change and weight are shown as percentages in the output (rather than floating point numbers in the implementation).
     129
     130[[BR]]
     131
     132To dump the changes to video encoding speed and quality, set:
     133{{{
     134XPRA_VIDEO_DEBUG=1
     135}}}
     136when starting the server, you will then get messages like these when using fixed quality/speed settings:
     137{{{
     138video encoder using fixed speed: 10
     139video encoder using fixed quality: 10
     140}}}
     141Or these when actually using the tuning code:
     142{{{
     143video encoder quality factors: wid=5, packets_bl=1.00, batch_q=0.31, \
     144    latency_q=94.44, target=30, new_quality=25
     145video encoder speed factors: wid=4, low_limit=157684, min_damage_latency=0.03, \
     146    target_damage_latency=0.20, batch.delay=17.69, dam_lat=0.00, dec_lat=0.05, \
     147    target=4.00, new_speed=5.00
     148}}}
     149Please refer to the code for details.