Sponsored Content
Special Forums UNIX and Linux Applications High Performance Computing Building Linux cluster for mechanical engineering software Post 302920299 by DGPickett on Wednesday 8th of October 2014 03:18:17 PM
Old 10-08-2014
VNC on XWindows platforms creates a local virtual XWindow desktop that supports your choice of window managers, has low latency and can be viewed by a phelora of platform supporting viewers off your client machine of choice. I am using a JAVA viewer, as I lack local admin. The X tcp or unix sockets run inside the host for min laatency (unless you point off-host X clients to it), and a VNC socket connects the viewer. You can run the VNC tcp though an ssh tunnel for security.

Heterogenous clustering requires smarter load balancing and code compatability or porting. Java is portable, compared to C++/g++, which produces code specific to the CPU and O/S, but still is very widely available to compile locally compatible code.

VM makes sense. In practice, very few modern systems page much, and it makes the environment that much more robust. It can support huge sparse matrixes in an mmap()'d space, key to many problems.

Going highly parallel on cpu and ram suggest that net and file access will become bottlenecks, so yes, you need to put lots of work into making them as parallel as possible, too. Network fabric needs to be many path switches and high bandwidth. If you go fiber with either, remember that with its higher speeds comes higher latency, so problems may need to be structured to avoid that. Net and file have been becoming the same problem, as more and more file is remote from the host.
 

4 More Discussions You Might Find Interesting

1. UNIX for Advanced & Expert Users

building and running a software in different linux kernel versions

my Querry is if i build a software on a specific linux kernel and then try to run it on another linux kernel ....what can be the possible problems or what errors can most probably appear while running the binary in an updated version of linux. (1 Reply)
Discussion started by: mobydick
1 Replies

2. High Performance Computing

Building a Solaris Cluster Express cluster in a VirtualBox on OpenSolaris

Provides a description of how to set up a Solaris Cluster Express cluster in a VirtualBox on OpenSolaris. More... (0 Replies)
Discussion started by: Linux Bot
0 Replies

3. High Performance Computing

Building a Linux Virtual Server cluster

Hi Guys, I'm busy building a LVS-NAT cluster on Red-Hat server 5.1 and I need a kernel that has LVS capabilities for a red-hat server 5.1. Is the anyone who can advise me where I can get this kernel. I have already visited the following site Ultra Monkey: and this has old kernels e.g. 2.4.20... (2 Replies)
Discussion started by: Linux Duke
2 Replies

4. Red Hat

Free Cluster software with Red Hat Linux 5.0

Hi, I would like to know wheather any free cluster software is coming with Red Hat Ent Linux Medias? or needs to be purchased seperately. (3 Replies)
Discussion started by: manoj.solaris
3 Replies
Xvnc(1) 							     TightVNC								   Xvnc(1)

NAME
Xvnc - an X server providing VNC connectivity SYNOPSIS
Xvnc [:display] [-geometry widthxheight] [-depth depth] [-pixelformat rgbNNN|bgrNNN] [-udpinputport port] [-rfbport port] [-rfbwait time] [-nocursor] [-rfbauth passwd-file] [-httpd dir] [-httpport port] [-deferupdate time] [-economictranslate] [-lazytight] [-desktop name] [-alwaysshared] [-nevershared] [-dontdisconnect] [-viewonly] [-localhost] [-interface ipaddr] [-inetd] [-compatiblekbd] [X- options...] DESCRIPTION
Xvnc is a VNC (Virtual Network Computing) server. It acts like an X server with a virtual display. The display can be seen by a VNC viewer application, which may be running on a different machine: see vncviewer(1). Xvnc is built inside the source code tree of XFree86, and shares many options with it. Normally, you don't need to start Xvnc manually; use the vncserver(1) wrapper script instead. This script sets reasonable defaults for Xvnc session, checks many error conditions etc. Please read the BUGS section if you plan to use VNC on an untrusted network. OPTIONS
Xvnc supports many standard X server options and a number of VNC-specific options. To see what standard X server options are supported, please look at the Xvnc -help output and read the Xserver(1) manual page for details on those options. The VNC-specific options are as follows: -geometry widthxheight Set desktop width and height. -depth depth Set the colour depth of the visual to provide, in bits per pixel. Must be a value between 8 and 32. -pixelformat rgbNNN|bgrNNN Set colour format for pixels representation. The viewer can do the conversion to any other pixel format, but it is faster if the depth and pixel format of the server is the same as the equivalent values on the viewer display. -udpinputport port UDP port for keyboard/pointer data. -rfbport port TCP port for RFB protocol. The RFB protocol is used for commnunication between VNC server and clients. -rfbwait time Maximum time, in milliseconds, to wait for an RFB client (VNC viewer). -nocursor Don't put up a pointer cursor on the desktop. -rfbauth passwd-file Use authentication on RFB protocol from the specified file. The passwd-file can be created using the vncpasswd(1) utility. -httpd dir Serve files via HTTP protocol from the specified directory. Normally, Java viewer classes are stored in such directory. -httpport port TCP port on which Xvnc should listen for incoming HTTP connections (to allow access to the desktop from any Java-capable browser). -deferupdate time Time in milliseconds, to defer screen updates (default 40). Deferring updates helps to coalesce many small desktop changes into a few larger updates thus saving network bandwidth. -economictranslate Use less memory-hungry pixel format translation. -lazytight Disable the "gradient" filter in Tight encoding (TightVNC-specific). The "gradient" filter often helps to improve data compression ratios, but may slow down the server performance. Please note that this filter is never used when a client enables JPEG compression in the Tight encoding. -desktop name Set VNC desktop name ("x11" by default). -alwaysshared Always treat new clients as shared, never disconnect existing client on a new client connection. -nevershared Never treat new clients as shared, do not allow several simultaneous client connections. -dontdisconnect Don't disconnect existing clients when a new non-shared connection comes in, refuse new connection instead. -viewonly Don't accept keboard and pointer events from clients. All clients will be able to see the desktop but won't be able to control it. -localhost Only allow loopback connections from localhost. This option is useful in conjunction with SSH tunneling. -interface ipaddr Listen for client connections only on the network interface with given ipaddr. -inetd Xvnc is launched by inetd. This option causes Xvnc to redirect network input/output to stdin/stdout. -compatiblekbd Set META and ALT keys to the same X modifier flag, as in the original version of Xvnc by AT&T labs (TightVNC-specific). BUGS
There are many security problems in current Xvnc implementation. It's recommended to restrict network access to Xvnc servers from untrusted network addresses. Probably, the best way to secure Xvnc server is to allow only loopback connections from the server machine (the -local- host option) and to use SSH tunneling for remote access to the Xvnc server. For details on SSH tunneling, see <URL:http://www.cl.cam.ac.uk/Research/DTG/attarchive/vnc/sshvnc.html> . SEE ALSO
vncserver(1), vncviewer(1), vncpasswd(1), vncconnect(1), sshd(1) AUTHORS
Original VNC was developed in AT&T Laboratories Cambridge. TightVNC additions were implemented by Constantin Kaplinsky. Many other people participated in development, testing and support. Man page authors: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>, Tim Waugh <twaugh@redhat.com>, Constantin Kaplinsky <const@tightvnc.com> August 2006 Xvnc(1)
All times are GMT -4. The time now is 09:52 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy