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 20 and Version 21 of WindowRefresh


Ignore:
Timestamp:
06/21/13 16:10:49 (8 years ago)
Author:
Antoine Martin
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • WindowRefresh

    v20 v21  
    6262[[BR]]
    6363
    64 == The Factors ==
     64== The Batch Delay Factors ==
    6565Again, this is a simplified explanation, and the actual values used will make use of heuristics, weighted averages, etc. Recent vs average values, trends, etc.
    6666Please refer to the source for details.
     
    9898[[BR]]
    9999
     100== Speed and Quality auto tuning ==
     101Please refer to the code for accurate information.
     102
     103The auto-tuning code should:
     104* honour the minimum speed and quality settings set via {{{--min-quality}}} and {{{-min-speed}}}
     105* tune the speed so that encoding of one frame takes roughly as long as the batch delay (the time spent accumulating updates for the next frame), so that there is only one frame in the pipeline on average. The aim is to always keep the encoder busy, but without any backlog. (note: this does not necessarily lead to the best framerate, since a busy cpu may cause the batch delay to increase... and in turn lower the speed)
     106* client speed: if the client is struggling to decode frames, then we use a higher speed (which means less effort in decompressing the stream) - the target client decoding speed is 8 MPixels/s
     107* quality: we try to lower the quality if we find that the client has a backlog of frames to draw/acknowledge (usually a sign of network congestion), or if the measure client latency is higher than normal (also a sign of congestion)
     108
     109
     110[[BR]]
     111
    100112== Debugging ==
    101 "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).
     113"{{{xpra info}}}" provides a lot of details on the current values used for batch delay and encoding speed/quality calculations.
    102114A good start is:
    103115{{{
     
    106118}}}
    107119You should narrow down to the individual window you are interested in.
    108 
    109 [[BR]]
    110 
    111 === Batch Delay ===
    112 If "xpra info" is not enough, you can dump the change in "batch delay" to lof file by setting:
    113 {{{
    114 XPRA_DELAY_DEBUG=1
    115 }}}
    116 when starting the server. Then every 30 seconds, or every 1000 messages (whichever comes first), 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:
    117 {{{
    118 update_batch_delay: wid=5, last updated 249.50 ms ago, decay=1.00s, \
    119     change factor=9.8%, delay min=5, avg=5, max=6, cur=6.7, \
    120     w. average=6.0, tot wgt=227.2, hist_w=113.6, new delay=7.4
    121 }}}
    122 For more details, to get the actual factors used, set:
    123 {{{
    124 XPRA_DELAY_DEBUG=2
    125 }}}
    126 Then the output should be much more verbose:
    127 {{{
    128 Factors (change - weight - description):
    129   -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>
    130  +128      15  damage processing ratios 12 - 13 / 5
    131   -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>
    132   -65       8  damage network delay: avg delay=0.001 recent delay=0.002
    133   -65      23  client decode speed: avg=32.3, recent=32.3 (MPixels/s)
    134    +0       0  no damage events for 1.2 ms (highest latency is 100.0)
    135   -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>
    136   -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>
    137   -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>
    138  -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>
    139  -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>
    140   -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>
    141  -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>
    142 }}}
    143 Note: the change and weight are shown as percentages in the output (rather than floating point numbers in the implementation).
    144 
    145 [[BR]]
    146 
    147 === Auto speed and quality ===
    148 
    149 To dump the changes to video encoding speed and quality, set:
    150 {{{
    151 XPRA_VIDEO_DEBUG=1
    152 }}}
    153 when starting the server, you will then get messages like these when using fixed quality/speed settings:
    154 {{{
    155 video encoder using fixed speed: 10
    156 video encoder using fixed quality: 10
    157 }}}
    158 Or these when actually using the tuning code:
    159 {{{
    160 video encoder quality factors: wid=5, packets_bl=1.00, batch_q=0.31, \
    161     latency_q=94.44, target=30, new_quality=25
    162 video encoder speed factors: wid=4, low_limit=157684, min_damage_latency=0.03, \
    163     target_damage_latency=0.20, batch.delay=17.69, dam_lat=0.00, dec_lat=0.05, \
    164     target=4.00, new_speed=5.00
    165 }}}
    166 Please refer to the code for accurate information.
    167 
    168 The auto-tuning code:
    169 * honours the minimum speed and quality settings set via {{{--min-quality}}} and {{{-min-speed}}}
    170 * tunes the speed so that encoding of one frame takes roughly as long as the batch delay (the time spent accumulating updates for the next frame), so that there is only one frame in the pipeline on average. The aim is to always keep the encoder busy, but without any backlog. (note: this does not necessarily lead to the best framerate, since a busy cpu may cause the batch delay to increase... and in turn lower the speed)
    171 * client speed: if the client is struggling to decode frames, then we use a higher speed (which means less effort in decompressing the stream) - the target client decoding speed is 8 MPixels/s
    172 * quality: we try to lower the quality if we find that the client has a backlog of frames to draw/acknowledge (usually a sign of network congestion), or if the measure client latency is higher than normal (also a sign of congestion)