More news on this. At least part of the issue seems to have been
hardware-related. For some reason (possibly my network switch, because
I seem to get the same behavior from multiple machines), whenever I
manually set either my server or client NIC to 10 Mbps, it produces an
odd performance curve that drops off sharply past about an 8k transfer
size, to the point that the typical transfer sizes being sent by
TigerVNC perform at more like 2 Mbps, even with no latency added. Thus,
the performance was being limited by the bandwidth, which is why I
didn't see any benefit to the advanced flow control features.
If I instead run with the regular 100 Mbps transfer rate but still
artificially add latency via qdisc, then I can see a clear benefit, both
qualitatively and quantitatively-- as long as I jack up the TCP max
buffer sizes to 8 MB in /etc/sysctl.conf:
net.core.rmem_max = 8388608
net.core.wmem_max = 8388608
net.ipv4.tcp_rmem = 4096 87380 8388608
net.ipv4.tcp_wmem = 4096 65536 8388608
I'm not sure how realistic that configuration is, but it's not the first
time I've used it for benchmarking. I have yet to find a reliable way
to limit the bandwidth. At least on my system, trying to use qdisc for
that as well produces very unpredictable results.
I ported over the fake mouse event generator that I use in TurboVNC to
test interactive performance (patch attached, if anyone is interested.
The only reason I didn't check it in is that I don't know if it is of
any use for testing applications other than GLXspheres. For a more
typical 3D app, for instance, it would probably be necessary to simulate
more of a cross-screen back-and-forth drag instead of just a mouse
wiggle.) To test performance, I run 'vglrun
/opt/VirtualGL/bin/glxspheres64 -fs -i' on the server and then start the
client with 'TVNC_FAKEMOUSE=1 vncviewer'. Once connected, pressing both
left and right mouse buttons at the same time activates/deactivates the
fake mouse event generator, which will stream mouse events every 10 ms
to the server, causing the spheres to animate.
/opt/VirtualGL/bin/tcbench is then used to record the actual throughput
on the client. I observe that, with the 11/08 build and 200 ms of
simulated latency, the frame rate was latency-limited to 5 Hz. In the
11/23 build, after some initial variability as Linux autotunes the TCP
parameters, the frame rate settles into about the same level as it is
with no latency. I tested with compress level = 1 and quality level = 8.
I do still observe a 1/3 drop in performance relative to using a
deferred update timer of 1 ms, however. This is true with both the 200
ms and 0 ms latency cases. I will restate my desire to change this back
to a default of 1 ms, unless there is compelling quantitative evidence
to indicate that a 10 ms DUT is beneficial.
On 12/7/11 2:45 AM, Pierre Ossman wrote:
> Any luck getting this working?
>
> On Thu, 1 Dec 2011 11:31:25 +0100
> Pierre Ossman <oss...@cendio.se> wrote:
>
>> On Wed, 30 Nov 2011 15:47:14 -0600
>> DRC <dcomman...@users.sourceforge.net> wrote:
>>
>>>
>>> Yes, I'm getting the "enabling continuous updates" message. How I'm
>>> testing is to look at responsiveness when running 'vglrun glxspheres -i
>>> -fs' with quality=1 and compress level=1. I move the mouse across the
>>> screen and gauge (with a stopwatch) how long it takes for the server to
>>> "catch up." It's consistently about 1.5 seconds both before and after
>>> the high-latency modifications. TurboVNC performs similarly with
>>> similar quality/compress level ("Low-Quality JPEG preset.")
>>>
>>
>> Not sure I'm understanding your test case. The mouse is normally
>> rendered locally and not latency sensitive. Or are you disabling that
>> for the test?
>>
>>> GLXspheres at this quality level is going to cause Tiger/TurboVNC to
>>> generate about 0.5 Mbits/frame of data at 1240x900, so if the frame rate
>>> is not latency-limited, TigerVNC should be capable of at least 5-6 Hz
>>> given the effective bandwidth of the 10 Mbit connection. However, it
>>> seems to be still generating about 3 Hz, the same as it did before the
>>> modifications.
>>
>> Odd. There is a corner case where single updates exceed the congestion
>> window, but that shouldn't happen here. For 10 Mbit at 100 ms RTT, it
>> should have a window of at least 1 Mbit, meaning it should fit two or
>> three of those updates in there per round trip.
>>
>> Can you try with the congestion debugging turned on and see what
>> latency and congestion window it gets?
>>
>>> I also do not notice any difference when typing into a console window,
>>> moving windows around, etc. Further, it appears that double buffering
>>> is not working quite right, but that's the case in the pre-modified
>>> build as well.
>>
>> In what way? At such low frame rates, perhaps you're hitting the timer
>> which prematurely updates the screen so it won't appear frozen.
>>
>> Rgds
>
>
Index: vncviewer/Viewport.cxx
===================================================================
--- vncviewer/Viewport.cxx (revision 4819)
+++ vncviewer/Viewport.cxx (working copy)
@@ -69,7 +69,8 @@
Viewport::Viewport(int w, int h, const rfb::PixelFormat& serverPF, CConn* cc_)
: Fl_Widget(0, 0, w, h), cc(cc_), frameBuffer(NULL), pixelTrans(NULL),
colourMapChange(false), lastPointerPos(0, 0), lastButtonMask(0),
- cursor(NULL), menuCtrlKey(false), menuAltKey(false)
+ cursor(NULL), menuCtrlKey(false), menuAltKey(false),
+ fakeMouseEnabled(false), fakeMousePending(false), fakeMouseInterval(10)
{
// FLTK STR #2599 must be fixed for proper dead keys support
#ifdef HAVE_FLTK_DEAD_KEYS
@@ -421,6 +422,24 @@
}
handlePointerEvent(Point(Fl::event_x() - x(), Fl::event_y() - y()),
buttonMask);
+
+ if (event == FL_PUSH) {
+ char *env = NULL;
+ if ((env = getenv("TVNC_FAKEMOUSE")) != NULL && !strcmp(env, "1") &&
+ buttonMask == 5) {
+ int temp;
+ if ((env = getenv("TVNC_FAKEMOUSEINTERVAL")) != NULL &&
+ (temp = atoi(env)) > 0)
+ fakeMouseInterval = temp;
+ fakeMouseEnabled = !fakeMouseEnabled;
+ if (fakeMouseEnabled && !fakeMousePending) {
+ Fl::add_timeout((double)fakeMouseInterval / 1000.0,
+ handleFakeMouse, this);
+ fakeMousePending = true;
+ }
+ }
+ }
+
return 1;
case FL_FOCUS:
@@ -530,6 +549,29 @@
}
+void Viewport::handleFakeMouse(void *data)
+{
+ Viewport *self = (Viewport *)data;
+ static int offset = 0;
+
+ assert(self);
+
+ try {
+ if (!self->fakeMouseEnabled) return;
+ self->fakeMousePending = false;
+ rfb::Point p(self->lastPointerPos.x + offset,
+ self->lastPointerPos.y + offset);
+ self->cc->writer()->pointerEvent(p, 1);
+ offset = 1 - offset;
+ Fl::add_timeout((double)self->fakeMouseInterval / 1000.0,
+ handleFakeMouse, data);
+ } catch (rdr::Exception& e) {
+ vlog.error(e.str());
+ exit_vncviewer(e.str());
+ }
+}
+
+
rdr::U32 Viewport::translateKeyEvent(int keyCode, int origKeyCode, const char
*keyText)
{
unsigned ucs;
Index: vncviewer/Viewport.h
===================================================================
--- vncviewer/Viewport.h (revision 4819)
+++ vncviewer/Viewport.h (working copy)
@@ -128,6 +128,7 @@
void handlePointerEvent(const rfb::Point& pos, int buttonMask);
static void handlePointerTimeout(void *data);
+ static void handleFakeMouse(void *data);
rdr::U32 translateKeyEvent(int keyCode, int origKeyCode, const char
*keyText);
void handleKeyEvent(int keyCode, int origKeyCode, const char *keyText, bool
down);
@@ -164,6 +165,10 @@
Fl_RGB_Image *cursor;
rfb::Point cursorHotspot;
+
+ bool fakeMouseEnabled;
+ bool fakeMousePending;
+ int fakeMouseInterval;
};
#endif
------------------------------------------------------------------------------
Cloud Services Checklist: Pricing and Packaging Optimization
This white paper is intended to serve as a reference, checklist and point of
discussion for anyone considering optimizing the pricing and packaging model
of a cloud services business. Read Now!
http://www.accelacomm.com/jaw/sfnl/114/51491232/
_______________________________________________
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
