From: John Stone (johns_at_ks.uiuc.edu)
Date: Sat Dec 22 2001 - 21:56:00 CST

Dear Alexei,
  In order to provide a short-term hack which might help people
experiencing the type of problem you described previously, I have
added a special VMDMSECDELAYHACK environment variable which can be
used to make VMD less agressive in its event processing and redrawing
rate. This is not a proper fix for the behavior some people are
experiencing, but by reducing the CPU and graphics utilization within
VMD itself, one may be able to overcome various deficiencies in the
X server and OpenGL implementation on a given machine. By enabling
this hack, VMD will sleep for a specified number of milliseconds before
attempting to do further drawing or event processing. The net result
should be decreased CPU and graphics utilization, making it easier
for the X or other window server, and the graphics hardware to do
their jobs. This hack will be available in VMD 1.7.1, which I hope
to release late tonight or early tomorrow. Let us know if you have
other questions.

Thanks,
  John Stone
  vmd_at_ks.uiuc.edu

On Fri, Dec 21, 2001 at 12:55:30PM -0800, Alexei Podtelezhnikov wrote:
> Hi VMD-team,
>
> Overall impression about the recent beta is positive. It's stable and it
> works. Besides that little problem on Linux-boxes I already wrote you
> about some two months ago. In short, it's a bad responsiveness under
> cirtain circumstances: when you have a large molecule rolling, CPU load is
> maxed up. On top of it, if you move or click a tcl/tk menu (asking for
> additional actions from XFree86, I guess), the system goes into denial.
> All you see is your molecule spining fine, but your menues are redrawn
> sloooooooowly (we talking doesn's of seconds here).
>
> This problem was also pointed out to you in the thread "VMD freezes KDE
> under Linux Redhat 7.1" on vmd-l. They've seen it using nVidia drivers and
> XFree86 4.0.3, we are seeing it with G200 and G400 and 4.1.0. Somebody
> mentioned "socket collision" as an explanation. For whatever that means...
>
> Yes, it maybe a hardware problem, irq flooding, a driver bug, etc...
>
> Do you have any idea, what might be going on? An idea on workaround?
>
> Thanks,
> Alexei

-- 
NIH Resource for Macromolecular Modeling and Bioinformatics
Beckman Institute for Advanced Science and Technology
University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
Email: johns_at_ks.uiuc.edu                 Phone: 217-244-3349              
  WWW: http://www.ks.uiuc.edu/~johns/      Fax: 217-244-6078