It should work in the normal way, once the buffer sizes are increased and
the environment variable set. So, I'm not sure. Rebooting might be
required to ensure the larger buffer size is available to your dx
processes.
geenen <[EMAIL PROTECTED]>@opendx.watson.ibm.com on 10/07/2003 03:49:21 PM
Please respond to [email protected]
Sent by: [EMAIL PROTECTED]
To: [email protected]
cc:
Subject: Re: [opendx-users] strange problem with VPE
Your suggestion was right but I dont no why
I started the dxui by itself
/usr/local/dx/bin_linux/dxui
now I can open my .net file and run it.
I am not able to do the same through dxexec although I did change the
buffer
DX_SOCKET_BUFSIZE=262144
more /proc/sys/net/core/rmem_max
262144
more /proc/sys/net/core/wmem_max
262144
is there something else i have to set???
maybe increase the buffer even further?
I mean it works but why does it not work in the normal way???
cheers and thanks for the help
Thomas
On Tuesday 07 October 2003 19:40, Lloyd A Treinish wrote:
> The VPE will appear to hang if the buffer is overflowed between the ui
and
> exec. This can happen with a big net and when you hit the exec button.
If
> you manually kill the dxexec process and the ui comes back, then that's
> probably what's happening. Setting the buffer size as Mattijs suggests
> should resolve the problem.
>
>
>
>
> Mattijs Janssens <[EMAIL PROTECTED]>@opendx.watson.ibm.com on
> 10/06/2003 10:23:44 AM
>
> Please respond to [email protected]
>
> Sent by: [EMAIL PROTECTED]
>
>
> To: [email protected]
> cc:
> Subject: Re: [opendx-users] strange problem with VPE
>
>
>
> What I remember is that a lot of stuff from the .cfg file gets
> transferred (even when no data is transferred). On my Linux system I
> extend the network buffer size to 256Kb
>
> echo 262144 > /proc/sys/net/core/rmem_max
> echo 262144 > /proc/sys/net/core/wmem_max
>
> and setenv the DX_SOCKET_BUFSIZE variable to use this space
>
> setenv DX_SOCKET_BUFSIZE 262144
>
> Again, have no idea whether this has anything to do with your problem
> but elimination of possible problems can never harm.
>
> Mattijd
>
> geenen wrote:
> > yep
> > the window is no longer responding and I am unable to close the VPE
other
>
> than
>
> > kill it.
> > I do not actually load any data so there is no need for large amounts
of
>
> data
>
> > to be transfered between the ui and the exec. anyway I have set
> > DXMEMORY=20000 to prevent any memory problems...
> > I do not get any warning/error messages even when running dx -log on
>
> -trace on
>
> > by the way I am running dx version
> > Executive, version 04.2.0000 (20:08:49, Feb 26 2003)
> > User Interface, version 04.02.0000 (20:09:51, Feb 26 2003)
> > Script, 04.2.0000
> >
> > Thomas
> >
> >
> >
> > Thomas
> >
> > On Monday 06 October 2003 12:28, Mattijs Janssens wrote:
> >>Does it actually hang?
> >>
> >>This is not a network buffer size issue? The $DX_SOCKET_BUFSIZE should
> >>be set to a large number and the network buffer size in the kernel
> >>should be increased. See some older discussions in this list.
> >>
> >>geenen wrote:
> >>>hi
> >>>my VPE hangs when i try to open it after a simple import and
> >>>visualization of spreadsheet data.
> >>>So i tried to save the program first and then open it(edit visual
> >>>program). This resulted in the same behaviour. So i looked at the .net
> >>>file and tried to open each of the macros that are include manually.
>
> This
>
> >>>worked fine. next i looked at my environment vars and startup script.
> >>>sh -x dx
> >>>++ echo ''
> >>>++ grep dxroot
> >>>+ x=
> >>>+ ARGS=
> >>>+ '[' '!' -z '' ']'
> >>>+ '[' -z '' ']'
> >>>+ prefix=/usr/local
> >>>+ DXROOT=/usr/local/dx
> >>>+ export DXROOT
> >>>+ '[' -z '' ']'
> >>>+ DXDATA=/usr/local/dx/samples/data
> >>>+ '[' -d /usr/local/dx/samples/data ']'
> >>>+ export DXDATA
> >>>+ '[' -z
>
>>>/usr/local/dx/samples/macros/:/mara2/geenen/NCF/test/traccoor/rotatie_no
> >>>s
> >>>
> >>>tokes/9 ']'
> >>>+ '[' -z '' ']'
> >>>+ JXMACROS=/usr/local/dx/java/server/dxmacros
> >>>+ '[' -d /usr/local/dx/java/server/dxmacros ']'
> >>>+ '[' -z '' ']'
> >>>+ JXUSERMACROS=/usr/local/dx/java/server/usermacros
> >>>+ '[' -d /usr/local/dx/java/server/usermacros ']'
> >>>+ '[' -z
>
>>>/usr/local/dx/samples/macros/:/mara2/geenen/NCF/test/traccoor/rotatie_no
> >>>s
> >>>
> >>>tokes/9 ']'
> >>>+
>
>>>DXMACROS=/usr/local/dx/samples/macros/:/mara2/geenen/NCF/test/traccoor/r
> >>>o
> >>>
> >>>tatie_nostokes/9:/usr/local/dx/java/server/usermacros + '[' '!' -z
>
>>>/usr/local/dx/samples/macros/:/mara2/geenen/NCF/test/traccoor/rotatie_no
> >>>s
> >>>
> >>>tokes/9:/usr/local/dx/java/server/usermacros ']'
> >>>+ export DXMACROS
> >>>+ '[' -f /usr/local/dx/bin/dxworker ']'
> >>>+ exec /usr/local/dx/bin/dxworker
> >>>
> >>>that looks just fine since the macros that are used are in
> >>>/usr/local/dx/samples/macros/ I even include my working dir and copied
> >>>the included macros to this dir.
> >>>All with no effect. Next I tried to install dx on a different system.
> >>>mandrake 9.1 opendx rpm 4.2
> >>>I had the same behaviour there.
> >>>The first lines of the .net file I try to open in the VPE
> >>>
> >>>// macro reference (direct): Make3DField
> >>>/usr/local/dx/samples/macros//Make3DFieldMacro.net
> >>>include "Make3DFieldMacro.net"
> >>>//
> >>>// macro reference (direct): AutoScale
> >>>/usr/local/dx/samples/macros//AutoScaleMacro.net
> >>>include "AutoScaleMacro.net"
> >>>//
> >>>// macro reference (direct): UnsquishGlyph
> >>>/usr/local/dx/samples/macros//UnsquishGlyphMacro.net
> >>>include "UnsquishGlyphMacro.net"
> >>>//
> >>>// MODULE main
> >>>//
> >>>
> >>>It looks like dx knows where the macros are since it is able to run
the
> >>>.net file but VPE does not know where the macros are do they use
> >>>different env settings??? any help would be highly appreciated
> >>>
> >>>Thomas Geenen
>
> --
> /*---------------------------------------------------------*\
>
> | =========== Mattijs Janssens |
> | \\ / Development Engineer |
> | \\ / |
> | \\ / Nabla Ltd. |
> | \\ / The Mews, Picketts Lodge |
> | \\/ Picketts Lane, Salfords, |
> | F ield Surrey RH1 5RG. |
> | O peration Tel: +44 (0)1293 821272 |
> | A nd Email: [EMAIL PROTECTED] |
> | M anipulation URL: http://www.Nabla.co.uk |
>
> \*---------------------------------------------------------*/
