On 5/10/11 9:02 AM, Arthur Huillet wrote: > TigerVNC computes a "max bandwidth" for the link. Perhaps we can try the > following > approach : > > (with a 2 second sampling interval or so) > - dynamically BWmax = evaluate maximal bandwidth over one minute or something > (size/wait > time when we know we expect a rectangle) > - evaluate BW = average bandwidth (size / total interval time) > > - if BW <= 10% BWmax > then the link is idle > (dramatically) increase quality (as a special case, this is > your ALR) > - if BW >= 95% BWmax > then the link is highly loaded > decrease quality (until 90% is reached) > - else > try to increase quality slowly until we are in the 90%-95% band > > This makes one huge assumption: that the bottleneck is the network. In the > case I am > interested in, it most definitely is. > > Advantages : > > - idle applications are properly detected, to the point of possibly doing ALR > - overloaded link is efficiently detected and quality is decreased
I don't think this obviates ALR. The reason is that ALR is specifically asking the server to re-send lossy tiles. It is designed for 3D applications, in which a user would rotate/pan/zoom a model and then stop and stare at it for a while. If you are, for instance, rotating a 3D model, the motion will stop instantly, and even though the algorithm above would eventually detect this and raise the JPEG quality, it wouldn't affect the tiles that were already on the screen, and those are the ones that the user wants to analyze. > Disadvantages : > > - relies on a BWmax which isn't always well estimated (but in some cases as a > workaround > could be input by the user) > - does not consume 100% of the link's BW > > Is there anything obviously wrong with this "bandwidth-based" approach? I > think UPS had too > many pitfalls, but assuming BWmax can be computed correctly I feel this could > work. > Obviously the actual thresholds have to be tweaked. > (TigerVNC does something much more simple and that doesn't really work > because it's not > truly a *dynamic* quality algorithm.) You hit the nail on the head, which is that it's impossible to tell whether the bandwidth is constrained by the network. If running on a 100 Mbit connection, for instance, it will more likely be constrained by the server CPUs, so BW/BWmax may only be 50%, but we don't want to reduce or increase the quality in that case. If running on a low-bandwidth network, the bandwidth is always constrained by the network. I don't think idle detection is important, because per above, ALR needs to be implemented as a separate and independent feature. The most important thing is to detect when the link is more than, say, 95% saturated so that you can dial down the quality until it's in the 90-95% range. If it's below 90%, then increase the quality slowly as you state, until the quality reaches 4:4:4 Q95 (which I would define as the max for this algorithm.) An accurate measurement of BWmax is critical here, though, and I don't really trust that there is a way to measure that accurately. The other problem is that this algorithm is pretty useless for interactive apps, because it would take too many frames for it to converge on the right value. It really needs to detect and change the quality within 2 frames to be useful in an interactive environment. You have to bear in mind that, if you're running on a 5-megabit connection, the difference between "low quality" and "high quality" JPEG in TurboVNC is the difference between 2 Hz and 9 Hz, so it's important to dial in the right quality level very quickly. The other wrinkle is latency. On a high-latency network, unless you're using the new continuous updates feature, your performance will likely be latency-bound instead of bandwidth-bound. There's no way to detect that without measuring the round-trip time from client to server and back. You can start to see why I haven't pursued this before now. TurboVNC is most often used within corporate/institutional environments, for which there are well-known bandwidth constraints. Our largest corporate deployment (Santos), for instance, uses a custom portal that automatically detects where the client is located and presets the JPEG quality based on what it knows about the connection between the TurboVNC server and the client. ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ VirtualGL-Devel mailing list VirtualGL-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
