Don't under estimate the power of simply exporting X11. As an example a very small amount of data goes over the network that might say "move that window 75 pixels to the left" and then the x-server has to change the value of 350,000 pixels and maybe remember the values of the ones covered restore the values of the ones uncovered. It is MUCH better then sending raster graphics over the net. It also moves calculations of about clipping and renders vector graphics to rater all onto the server If using openGL al lot of complex matrix math can be pushed off to the computer with the physical display.
About the cable. Just don't worry about oil. oil does not conduct. Remember many larger size transformers live in an oil bath. Flooding them with oil keeps the water out. It is only the wire insolation might care or not about oil. On Sun, Nov 6, 2016 at 12:34 PM, Gene Heskett <ghesk...@shentel.net> wrote: > On Sunday 06 November 2016 12:35:40 Chris Albertson wrote: > > > On Sun, Nov 6, 2016 at 1:14 AM, Gene Heskett <ghesk...@shentel.net> > wrote: > > > My newest concern is the poor > > > bogomips I see in dmesg. Only 153 for all 4 cores. This machine has > > > 17682. > > > > In case you did not catch it, "bogomips" is short for "bogus MIPS". > > In other words a worthless measurement pf speed. > > The processor used in the Pi 3 actually runs at just a little over 1 > > MIP per GHz (more or less.) > > > > If you are seeing poor performance with remote X11, I'd suspect poor > > network in performance. The best networking performance will be to > > use a USB 1000 BaseT dongle You will not get full gigabit level > > performance but it will outperform the built-in 100 BaseT interface. > > Then make sure you have a gigabit switch going to the PC. The > > advantage here is that you are NOT running an x-server on the Pi 3. > > Any work you can off load from there Pi 3 is good. Check memory > > usage using "top" > > > It seems to me, the best, cheap link would be to usb-2 to usb-2, which > gives 480 megabits each way, at the expense of some latency. However, > since the hal is running on the machine connected to the machinery, the > latency would be visual, and I don't believe that an extra 20ms due to > the physical links inherent latency would be a detectable problem. > > The problem as I see it, is in telling the usb system its ok to have a > std board socket at both ends of the link, and locating a short, as in > 6-8 inches, usb to usb cable. > > > The Machine kit people (if I understand it correctly) are breaking up > > LinuxCNC to run as a set of independent processes that communicate > > with messages. If Im right then it looks like the goal might be to > > have the ability to run the GUI on a different computer then HAL. > > This is the best design, not exporting the display, but the entire GUI > > program. > > That make more sense to me than just exporting x commands to a different > server. > > Now, I've had some breakfast and went to the garage to check it for first > impressions. But am back quickly, in severe back pain because I forgot > to take the morning pills, so the gabapenten hasn't had time to work. > > 1. Mouse is swimming in very cold corn syrup, and speeding it up in the > mouse prefs makes no difference. Not a show stopper, but distracting. > > 2. Linuxcnc is just as slow at opening its screen, and eventually drawing > the full lcnc screen there as it is here. 15+ seconds to a fully drawn > display. > > 3. Running the LinuxCNC logo, it ran normally. Mouse no slower when lcnc > is running, so this is AFAIAC a mouse problem in x. Running the same > mouse/kbd on the Dell I disconnected, the mouse was best described as > spastic, is now smooth and noticeably slow moving. Microsoft kbd and > mouse, and kbd known to not send timely keyup's. I'll check for weak > batteries but the real fix for that keyboard is a logitech K-360 as the > range to the dongle is way too short too. 3 feet max, <1 foot for no > missed keys. > > I should get some bi-color leds, steering diodes and some suitable > current limiting R's and put them where the motors hook up so I can see > the motors "running" while its sitting on the table yet. That, and get > the encoder finished. > > I'm still debating on how to best get the encoders cable out of the > spindle casting tub. Too much oil if I run it under the gears to one of > 2 holes in the rear of the tub. And potentially too close to spinning > gears. One thought is to drill a hole near the lower front, tipping the > drill as I go so a hunk of 3/8" SS tubing can be cut so as to drop thru > the casting and down thru the standoff spacer bar where the QCGB used to > be. That SS tubing is tough stuff, and cannot be bent by my tubing > bender intended for similarly sized copper. That casting is also hard > drilling, needing drill bits fresh from a drill doctor. > > 4. I get the impression the thing might work, if the mouse moved like my > hand. That slow, laggy move is distracting. The real test is how long > from a gnd short on e-stop to a full machine stopped, not counting > spindle unwind. > > Question, how much memory have most reserved for the GPU? I set that up > to 256 megs, from 64 in raspi-config, but that now seems excessive, > could that be part of the mouse lag? > > Now, maybe the %$# pill has become effective enough to walk around. > > Datapoint on the synaptic run refusal, there was no passwd set for root, > so I set one about 30 chars long. Now it runs if I give it that passwd, > but its almost unusable, wrong screen colors, mostly black, but fonts a > tad big. Sub-windows it opens are transparent black, with data from the > window under them showing thru. Just barely usable IOW. > > I haven't looked for an xconfigurator, but it looks like an 8 color, with > 4 of them solid black, screen. Best description is UGLY. > > Cheers Chris, Gene Heskett > -- > "There are four boxes to be used in defense of liberty: > soap, ballot, jury, and ammo. Please use in that order." > -Ed Howdershelt (Author) > Genes Web page <http://geneslinuxbox.net:6309/gene> > > ------------------------------------------------------------ > ------------------ > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today. http://sdm.link/xeonphi > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > -- Chris Albertson Redondo Beach, California ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
