Bridgeport Retrofit - keyboard input delays noted

It might give someone a clue. I am very novice to all of this. Had to google "top". Here is a screenshot if somebody can glean any useful info from it I'd be appreciative.

Mark

So now that i have experimented with Top a little bit i see it dynamically shows processes running. I understand none of this but i have observed that the 2 heaviest processes are axis and Xorg. When the linuxcnc seems to be working correctly (no delays) the axis process runs 25% CPU or so. Xorg is under 10%. When I observe the delay, axis goes away. Xorg is the heaviest process now a bit less, approx 5%. Once axis pops back to the top, the keyboard command is back to normal. From what little i have read Xorg is keyboard i/o related. So it appears to me that the OS is still handling keyboard (Xorg) but axis is not occupying any cpu so is off the top of the list.

Any of that useful to the gurus out there?

Mark

Not sure what the means except its not an obvious user process hogging all the CPU

It might help to post your HAL and INI files in case a HAL guru can spot a configuration error of some kind

PCW wrote:

Not sure what the means except its not an obvious user process hogging all the CPU

It might help to post your HAL and INI files in case a HAL guru can spot a configuration error of some kind

Following this thread with great interest because I am Marks friend that also experienced the problem with a lathe retrofit I did. (same Atom PC and MESA boards). I am in the process now of retrofitting a mill and have another Atom pc which I planned to use.

I am confused a bit here, perhaps Pete can comment. The PC shows high cpu usage during normal operations but trucks along nicely, running and making parts no problem, during such times CPU usage is say 75-90%. Then, when just sitting at rest, doing a simple move with the MDI, the occasional long delay happens, DURING this delay, cpu usage shows it drops to maybe 10% or so. After the delay cpu usage returns to its previous high level and all is fine.

It seems to me that the issue is not something hogging CPU usage causing the delay, the cpu is only running at 10% or so DURING the delay. It seems the cpu is greatly UNDER utilized at this time, causing the delay. There are no apparent problems when CPU usage is showing a high utilization.

Maybe I am missing something here. I would also like to get to the bottom of this issue.

George

Here are my HAL and INI files for your reading enjoyment. I certainly hope that there is something here that is causing the delays. I had not considered them to be the root cause because the machine works with these configs. I anticipated at the outset that this is more likely an OS related tuning issue

Thanks for the assistance. I am swimming in deep water.

Mark

I am assuming something is hogging the CPU since it gets so slow.
One thing that makes this difficult is that the time used in the real time portion
does no show up with the normal CPU monitoring tools.

It might be valuable to do the halrun capture when the delay is happening

It seems to me that the issue is not something hogging CPU usage causing the delay, the cpu is only running at 10% or so DURING the delay. It seems the cpu is greatly UNDER utilized at this time, causing the delay.

The Intel atom is a dual core processor, are you running with isolcpus=1 on the kernel parameter line or a CPU hog?
The problem may be as Peter was suggesting, that the displayed CPU usage, is only measuring userspace threads and when they are low, could be co-inciding with high realtime usage.

There are dozens of Atom variants available as Foxcomm machines, can you be specific as to which board you have?
The video chip is another factor, there are a lot of dodgy ones in this series of MBs, would be good to know what chip that is and what driver is being used
(lspci -vv)

regards

Further to the video line

This screenshot was of my computer running axis_mm sim and the default carving gcode

Even with shutter running as well to do the screenshot, xorg is well below Axis. On normal running prior to taking the shot, xorg was between 0.5% and 1% consistantly with Axis around 8% and milltask at 1.5%ish
This obviously is a much faster CPU, but percentage wise, xorg never gets near your 3 x cpu usage of axis

You may be assuming a level of technical ability that I don't have.

I turned the system on as normal. Opened a terminal window and executed "halrun". The machine turned off. Axis screen disappeared.

So then I executed "halrun" in a terminal window. Saw a command prompt "halcmd:". Then fired up LinuxCNC. I saw an error message regarding real time error and told me to run latency test before proceeding. Unfortunately I didn't capture that and ignored it. I then homed the machine. Went back to the terminal window and saw nothing had changed on the screen.

I attempted this a 2nd time and got a whole different set of results. Again, I did not capture it but I received a string of error messages (similar to what I would see if i were to attempt to start LinuxCNC without my field supply turned on).

I assume from reading the man page for halrun, there are some parameters you assumed that I might know. I guess the bottom line is, can you be very specific how you wish me to do the "halrun capture"? I am missing something.

Mark

What I _meant_ to say was run this command in a terminal window when linuxcnc is having one of these 10 second delays:

halcmd show all > allhal.txt

and post the allhal.txt file here again