On Sunday, February 12, 2012 12:11:09 PM Mark Wendt (Contractor) did opine:
> On 2/11/2012 3:25 PM, gene heskett wrote: > > Greetings all; > > > > Sorta one of those days to hibernate, 3" of snow blowing all over, 19F > > etc in north central WV today. > > > > So I'm sitting here with a couple ssh sessions going to that box, > > motor power off etc. > > > > I found that installing ksysguard give me a remote system monitoring > > facility, and am hoping its not lying to me. > > > > My base_thread is 20,000 now, which would I would think, show up as > > several percent of the 2nd cpu, the red line in the ksysguard system > > tabs display. When linuxcnc isn't running, I see, possibly at 10 > > second intervals, a barely visible spike to perhaps 0.5%, with > > isolcpus=1 in effect I've no clue what that might be. > > > > With linuxcnc running (without the taskset launch), and carving the > > logo, I see an occasional spike to perhaps 2% at about that same 10 > > second interval. And a spike to maybe 5% if I do something in axis > > like adjust the feed override slider. > > > > With a 20 microsecond base thread, and a 3 microsecond reset timing > > set in the .hal file, ISTM that core 2's usage should be higher that > > that. I do see in this utilities process list, an 'rtkit' that is > > caught using 2 or 3% very occasionally. And the > > hal_manual_tool_change shows up too. > > > > Keyboard response from here of course includes the network lags, but > > seems good enough that at a .28ipm jog rate, I can jog it half a thou > > with a quick tap on an arrow key. This, with a 30 microsecond base > > thread on the old machine, would not have been possible because it > > would run on for several seconds after the key was released. Whether > > I get the same results from its local keyboard remains to be seen and > > may be the result of running axis on a remote display& not burning > > cpu cycles for the local display since this boxes nvidia driven > > display is probably 20x faster than that machines intel based display > > is. > > > > > From this I get the impression that an additional box with good gfx > > > might > > > > be a huge advantage even if the network cable was only 6 feet long. > > > > Discussion? > > > > Am I using the wrong tools to track this? > > > > In which case what tool should I be using? > > > > Thanks and Cheers, Gene > > Gene, > > About tracking that occasional blip on the isolcpu, have you used atop? > Consider it a "top" on steroids. It shows processes running much like > top, but also displays what cpu they are running on. Here's the atop > web site: http://www.atoptool.nl > > Click on the screen shots and take a peek at what atop has over the top > utility. I use it at work. > > Mark > This prompted me to do a little more experimenting between running it as lcnc, which is a script that does the taskset, and running it as linuxcnc which does not. Then either way atop did not detect enough activity on the 2nd cpu to bother listing it more than 5% of the time. In that regard, htop, which displays each cpu it is configured for, full time as a slider in the upper area of its screen. To me, htop is the better utility, but then I am used to it and have been using it for years on this box full time. ksysguard OTOH used for the rest of this testing, showed a higher cpu usage overall for both cpu's and cpu001 was consistently in the 50-60% range when taskset was in effect, and about a 20% less total when it was not, only with possibly an 8% peak for #1 while it was running a 20 minute program with the motors off. Which of these two monitors utils is correct, I'll have to plead the 5th on as I don't have a clue. Then I thought I'd see how fast I can run the base thread, starting to hit realtime delays when taskset was used at about 17 microseconds, and pretty consistently at 14 microseconds, and when taskset was not used, I could go down another microsecond, perhaps 2. Without taskset, and at 19 microseconds, it has now run that 20 minute program 3 times without a delay warning thrown. This of course is without the local and slower gfx delays that relatively poor intel gfx chip will cause when it is using its own X to display the axis output. Hooking up my lappy, and ssh-ing into it so as to use the laptops gfx, probably wouldn't be quite that advantageous as its an ati gfx chipset and only a 1.4Ghz 'turion', but I'd think, until I observe otherwise, that what I'd see would be laggy gfx if the miss-match was too great. I guess what I'm saying is that in the overall scheme, using taskset isn't the magic twanger I thought it might be. The gfx in use, from this testing would seem to have the more noticeable effect. I will, very occasionally hit a realtime delay when running on its own x server & local screen with a 20 microsecond base thread when using taskset. Konversation is running, but firefox is not, kcalc and update_manager are but neither of the last are using detectable cpu. When I installed atop, it started an atop daemon, but I have no clue if it is actually active and collecting data when the display isn't running, in any event I just now used htop to run it down & send it a quit signal just in case. htop, FWIW, is showing cpu1 at around .5% so it must be using the same mechanism as atop to collect the data. As this HAS to be a bit intrusive, its possible it might cost a microsecond in base thread time to actually collect the data. I don't normally run it, or ksysguard, on that box since the gfx for ksysguard would have to impinge on the rest of the system. Conclusion? Forget taskset, and export the display to a remote server for best realtime performance. I believe that is the same conclusion some of you have reached. However, the improvement wouldn't seem to warrant the sheckels to buy another of those boxes and a display, territory of $375 additional cost, although that box could probably boot from a usb key and wouldn't need a dvd writer, bringing that back down to perhaps $300. Still not worth the minuscule improvement IMO. Thanks Mark. Cheers, Gene -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) My web page: <http://coyoteden.dyndns-free.com:85/gene> It is a poor judge who cannot award a prize. ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
