On 01/09/2012 09:22 AM, Kent A. Reed wrote: > On 1/9/2012 5:20 AM, Mark Wendt wrote: > >> On 01/08/2012 06:27 PM, Kent A. Reed wrote: >> >>> I had a few minutes this afternoon and decided to try another experiment >>> with this board---still running Ubuntu 10.04LTS with the 2.6.32-122-rtai >>> kernel. >>> >>> I disabled Gnome (which shut down X) on the board by running the following >>> from the command line: >>> >>> sudo service gdm stop >>> >>> (I disabled a few other services too, like Apache, but I don't think this >>> is relevant. The stock Ubuntu/EMC2 install starts up far too many services >>> for my taste. When I want a controller, that's all I want, not a desktop >>> computer.) >>> >>> Then I logged out and disconnected keyboard/mouse/monitor (well, actually I >>> just set my KVM switch to another computer; possibly it still imposes some >>> electrical levels at the motherboard connectors.) >>> >>> Finally, I logged into the board via Ethernet from another computer using >>> ssh -Y and again ran the latency-test for 15 minutes with approximately the >>> same level of stress as before (2 copies of glxgear, web browsing, listing >>> the directories of an external USB drive, etc.). >>> >>> Bottom line: the latency numbers got even better. Max jitter fell to >>> 3211ns/3222ns. >>> >>> For some time I have envisioned running my tabletop mill with a headless >>> controller and a networked operator console. If anything, the present >>> result says this would be the preferred mode. Of course, I could make it >>> cleaner by stripping down the distribution some more, possible even install >>> RTAI and EMC2 over a Ubuntu server distribution to avoid the Gnome/X-server >>> stuff altogether, since there's the usual niff-naff about booting Ubuntu >>> desktop edition without a monitor attached, etc. >>> >>> I'm curious if anyone has tried this experiment with other boards and, if >>> so, what results were obtained. >>> >>> And, yes, I realize I am chasing after diminishing returns. The latency on >>> a stock board is already good enough for practical purposes. Let's just say >>> my home situation causes a form of ADHD were I work furiously on very >>> short-term projects. >>> >>> Regards, >>> Kent >>> >>> >> Kent, >> >> Just curious, while headless, which runlevel were you at? You're still >> going to have to run some form of X to get a remote display, and to do >> that you need to be at either runlevel 5 or kick off startx. You can >> run "init 3" to bring it down to a non-X runlevel, but you won't be able >> to run Axis remotely without X running on the headless system. >> >> Mark >> >> > Mark: > > For me, runlevels are tricky---every Unix variant seems to come with its > own idea of what's what, and recent Ubuntu distributions replace the > traditional init approach with the goings-on of a package called > Upstart. Unmodified, my system reports the current runlevel is "2" and > the previous runlevel is "N" (meaning, there was no previous runlevel > recorded in the utmp record). > > In the end, runlevels are just a convenient way to manage the starting > and stopping of services. For my test I decided to kill the service(s) I > didn't want running using the "service" command (alternatively, I could > have downloaded and used the rcconf tool). The runlevel remained "2". > > Remember, X11 apps are perfectly happy to run on a headless machine if > they are talking to a remote X11-server. Their only requirement is the > local presence of appropriate libraries (assuming the apps are > dynamically linked, that is). > > X11's intrinsic network-communication model is massive overkill for > single-machine applications but it's there precisely to support > multi-machine environments. > > Regards, > Kent >
Kent, I understand that, I've got a number of Unix/Linux servers here at work that run headless. Most of them are RedHat machines, and run at a runlevel of 3, which keeps X from running but otherwise keeps it a relatively full-up network system, but yeah, there are a lot of different flavors in the Linux world when it comes to init levels. When you killed gdm above, did it also take out X? Mark ------------------------------------------------------------------------------ Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
