Folks,
I run GRASS (5.0.0pre2) through ssh on a ppp connection to my installation at
the office. I used the command line interface. When I start a monitor the
lag between keystrokes and displayed results often increases. Starting a
second monitor virtually stops everything. The lag between the time a key is
pressed and the time it appears on the screen sometimes exceeds 30 seconds.
I started pppstat on my local machine to see what was going on, and found
that the first monitor generated a continuous stream of network traffic at
about 8kb/second incoming and 4-5 kb/s outgoing. Somewhat bizzarly, starting
a second monitor dropped that stream to about 5 kb/second incoming and about
200 bytes/s outgoing. The command shell slowed to a near halt.
After I stopped the second monitor the network traffic initially stayed at
about 4 kb/s incoming and 200 bytes/s outgoing, but the traffic later rose
fairly gradually back to about 8 kb/s incoming and 4-5 kb/s outgoing.
All of this behavior is with a blank monitor--nothing at all in the display.
The behavior is the same regardless of whether the monitor is raised or not.
For comparison, "xeyes" running over the same link and taking a continuous
stream of mouse events generated about 1/10 that much traffic. "xcalc"
running over the same link generated no traffic at all when it wasn't being
used.
I tried with a second installation at my office that was based on a CVS
download from last August. That appeared to have the same problem. I have
until recently been using a beta11 installation and never noticed the problem.
What's going on here? Is this problem unique to my installations or is this
a consistent behavior?
Roger Miller
Roger Miller wrote:
I run GRASS (5.0.0pre2) through ssh on a ppp connection to my installation at
the office. I used the command line interface. When I start a monitor the
lag between keystrokes and displayed results often increases. Starting a
second monitor virtually stops everything. The lag between the time a key is
pressed and the time it appears on the screen sometimes exceeds 30 seconds.
I started pppstat on my local machine to see what was going on, and found
that the first monitor generated a continuous stream of network traffic at
about 8kb/second incoming and 4-5 kb/s outgoing. Somewhat bizzarly, starting
a second monitor dropped that stream to about 5 kb/second incoming and about
200 bytes/s outgoing. The command shell slowed to a near halt.
After I stopped the second monitor the network traffic initially stayed at
about 4 kb/s incoming and 200 bytes/s outgoing, but the traffic later rose
fairly gradually back to about 8 kb/s incoming and 4-5 kb/s outgoing.
All of this behavior is with a blank monitor--nothing at all in the display.
The behavior is the same regardless of whether the monitor is raised or not.
I think I know what's going on. XDRIVER is continuously polling the X
display connection and the GRASS monitor socket alternately. It should
really be doing a select() on both descriptors.
I'll look into a fix; in the meantime, you may be able to reduce the
traffic by increasing the timeout in get_connection_sock() in
display/devices/lib/connect_sock.c.
--
Glynn Clements <glynn.clements@virgin.net>
Glynn Clements wrote:
Roger Miller wrote:
> I run GRASS (5.0.0pre2) through ssh on a ppp connection to my installation at
> the office. I used the command line interface. When I start a monitor the
> lag between keystrokes and displayed results often increases. Starting a
> second monitor virtually stops everything. The lag between the time a key is
> pressed and the time it appears on the screen sometimes exceeds 30 seconds.
>
> I started pppstat on my local machine to see what was going on, and found
> that the first monitor generated a continuous stream of network traffic at
> about 8kb/second incoming and 4-5 kb/s outgoing. Somewhat bizzarly, starting
> a second monitor dropped that stream to about 5 kb/second incoming and about
> 200 bytes/s outgoing. The command shell slowed to a near halt.
>
> After I stopped the second monitor the network traffic initially stayed at
> about 4 kb/s incoming and 200 bytes/s outgoing, but the traffic later rose
> fairly gradually back to about 8 kb/s incoming and 4-5 kb/s outgoing.
>
> All of this behavior is with a blank monitor--nothing at all in the display.
> The behavior is the same regardless of whether the monitor is raised or not.
I think I know what's going on. XDRIVER is continuously polling the X
display connection and the GRASS monitor socket alternately. It should
really be doing a select() on both descriptors.
I'll look into a fix; in the meantime, you may be able to reduce the
traffic by increasing the timeout in get_connection_sock() in
display/devices/lib/connect_sock.c.
OK, I've committed a fix to XDRIVER, so that it waits until either the
GRASS monitor socket or the X connection is readable. This should
eliminate the busy wait.
However, it may impact upon the libW11 version; likely consequences
are either:
a) a busy wait, or
b) the monitor becoming unresponsive
when no client is connected. It depends upon whether the descriptor
obtained from ConnectionNumber() is readable (according to select()).
--
Glynn Clements <glynn.clements@virgin.net>
On Monday 28 January 2002 07:21, Glynn Clements wrote:
OK, I've committed a fix to XDRIVER, so that it waits until either the
GRASS monitor socket or the X connection is readable. This should
eliminate the busy wait.
Thanks, Glynn. I checked the traffic generated on the ethernet at work and
found that a single monitor generated traffic at about 17 kb/s. Not very
significant on that network, but even there mulitple monitors would generate
enough extraneous traffic to slow down other communications.
Now my problem is in getting the fix. I'm not familiar with CVS, so I tried
finding the fixed package using the html interface to the CVS repository.
Nothing I found was very recent. Where do I need to look?
Roger Miller
Lee Wilson and Associates
Roger Miller wrote:
> OK, I've committed a fix to XDRIVER, so that it waits until either the
> GRASS monitor socket or the X connection is readable. This should
> eliminate the busy wait.
Thanks, Glynn. I checked the traffic generated on the ethernet at work and
found that a single monitor generated traffic at about 17 kb/s. Not very
significant on that network, but even there mulitple monitors would generate
enough extraneous traffic to slow down other communications.
Now my problem is in getting the fix. I'm not familiar with CVS, so I tried
finding the fixed package using the html interface to the CVS repository.
Nothing I found was very recent. Where do I need to look?
I had neglected to sync the changes with the head, so you would need
to have selected the tag "releasebranch_11_april_2001_5_0_0" from the
"branches" menu at the bottom of the page. However, I've now updated
the head.
The files in question are:
src/display/devices/lib/Work.c
src/display/devices/lib/connect_sock.c
src/display/devices/lib/driverlib.h
src/display/devices/lib/main.c
src/display/devices/XDRIVER/XDRIVER24/Work.c
and all have the following most recent log message:
In get_connection_sock(), wait until either the socket or some other
descriptor (e.g. the X connection) is readable.
However, obtaining them via the CVS web interface isn't particularly
convenient, so I'll send you a tar file.
--
Glynn Clements <glynn.clements@virgin.net>