>I am running Xvnc over a small 10/100 LAN. When it's working, everything is
>great and the speed is near real-time.
>
>However, intermittently it just gets REALLY slow. This cannot be fixed by
>killing and restarting either the client (running on Windows) or the server
>(running on RH Linux). Also, this is a very small LAN (3 machines) and I
>have checked everything I can to eliminate any cases of something suddenly
>running that hogs either the CPU cycles or the LAN bandwidth.
>
>After some time (hours or days) it just resumes running fast without
>changing anything. What could I be missing???
I would like to take this chance to mention something very similar that I
have seen when I started working with the viewer code on PocketPC's (CE
3.0), trying to accelerate it to a more usable level. I have put in video
acceleration code and other modifications, and it is now quite fast enough
WHEN IT WORKS NORMALLY. But sometimes, it just gets ridiculously slow. I
have a Linux box (RH7.0), Gnome, 240x320 desktop, depth/visual doesn't
matter. It seems to be most noticeable when moving through the "Start"
menu from the taskbar (OK, I'm sure that's not what Gnome calls it, but
that what it looks like). Usually, it is fine, and then, out of the blue,
it starts drawing so slowly that you can SEE each individual scanline of
the update region being drawn.
This is on a network that consists of two machines - the server and the
viewer. There are *NO* collisions. Network speed in other applications is
fine. Using something like forwarded X sessions from one Linux box to
another through the NIC in the Linux box (with or without OpenSSH X
forwarding) never exhibits this problem. Data transfers of large files
(10+ MB) between the Linux box and CE unit occur at full speed, without
drops. The exact same behavior (everything I've mentioned so far, except
for the X session stuff) occurs whether my network link is a 10Mb/s link or
a 115200baud (.1Mb/s) PPP link. When the slow down occurs, it is just as
bad on the 10Mb/s link as it is on the .1Mb/s link.
I think it is some kind of multithreading resource contention in the viewer.
I say this for a variety of reasons:
1. Windows has some major problems with thread scheduling. Sometimes
threads are arbitrarily boosted in priority, sometimes they are dropped.
Thread priorities in the presence of hardware interrupts gets even more
interesting, and I don't even want to start on the subject of Interrupt
Service Threads vs. Interrupt Service Routines...
2. I have experienced major performance differences when I adjust the
relative thread priorities of the drawing thread and the other threads. I
did this by adjusting the priority of the drawing thread, because that was
the one I was most interested in (because of video acceleration
modifications). I would be very interested if someone would be willing to
drop me an architectural overview of the viewer so I could see the thread
interactions more clearly. My work so far has been examining the bark of
the trees, which makes it extremely difficult to form a coherent picture of
the forest...
3. In my case, the slowdown only occurs for less than a minute. Comparing
this to the hours or days of slowdown in the above case suggests to me a
lockstepping problem. If you think of the thread synchronization
operations occurring at some frequency, then when you put the two (or more)
frequencies (threads) together, you will get a beat frequency
(lockstepping). The nature and duration of the "beat" will depend on the
CPU speed, relative cost of executing the code in the various threads,
local code vs. OS system calls, and a ridiculous number of other
parameters. It is entirely possible that on "almost all" machines, these
parameters work out such that the "beat" is infrequent and of very short
duration, making it easily misinterpretable as a networking hiccup or
temporary congestion. It also makes it excruciatingly difficult to debug -
after all, if it has to run for hours to start doing it, how can you be
sure that you fixed it? You can't put a breakpoint on the code that only
fires when the beat occurs without already knowing what the cause of the
beat is... This is one of the reasons I would like to see an effor made to
rewrite the viewer without multithreading (but I get ahead of myself...)
4. I know that, at least in CE, the GDI, the serial driver, and the
networking stack have a tendency to hose each other. This was causing some
overall speed issues originally, which have been resolved, but the acute
slowdown that I have described has persisted through every change I have made.
5. My thesis work was on distributed parallel computing, with a focus on
harnessing idle CPU cycles. As such, I have a first-hand and relatively
painful awareness of Windows mishandling of thread priorities.
I would like to point out that I do not consider this a "fault" of the
viewer. I strongly suspect that the problem is in Windows and its
derivatives. I would, however, be happier if the viewer could be made
non-multithreaded. This would make it work more cleanly even on badly
behaved operating systems, and would make it substantially easier to debug.
I realize that this would require some immense rewriting, and may not even
be possible. That is one of the reasons I would like an overview of the
architecture and, if possible, the problems that forced the viewer into a
multithreaded form. (Hey, I had to write an entire class-hierarchy aware
exception handling substructure to be able to get the viewer code to
compile under the PocketPC tools, which don't support C++ exceptions. I
_might_ have ideas for getting around other kinds of problems, too)
Also, if you have encountered similar problems, it might be worthwhile to
report them so that we have a vague idea how much of an issue this is.
(Unfortunately, for those of us experiencing it, it is a HUGE issue that
makes VNC almost unusable, but if there are only two of us, then maybe we
just have to solve it ourselves. If, on the other hand, several people are
having this problem, it might be worthwhile to have a more extensive project)
Sorry for the rambling. Hope someone sends me an overview. Thanks,
Mac
_____________________________ /"\
Mac Reiter \ / ASCII Ribbon Campaign
Nomadics, Inc. X Against HTML Mail
[EMAIL PROTECTED] / \ (To join the campaign, simply use
this in your signature.)
---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list
to [EMAIL PROTECTED]
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------
