CPU usage high, fixed by deep clear

are you using Augment3d on this console?

I have used it, but always with an external computer 

Hi Robert Pennington  we may be able to discover a cause or causes for this by looking at your Ion's logs.  The next time you experience this issue, would you please press [Displays] + [Record] to put a marker in the logs, then save and send them to us?  More details are here: Retrieving or Saving Log Files from Eos Family Consoles - Electronic Theatre Controls Inc

You can attach them to this forum post or email to eos @ etcconnect.com.  If you email them, please reference this forum post so we can connect the dots.

ETC_Logs_Ion_Primary_04112022_220304.zip

Hey! I had a tech rehearsal for a show coming up, and by the end the console was struggling pretty badly. CPU sitting at low to mid 90% range, and most of that wasn't the GUI or FADE. This was affecting the time code coming into the console, as well as the output of the console. A deep clear still fixes the issue, but I'd like to prevent it all together.

EDIT: I did forget to put a marker in the logs. If this is necessary I will do it next time.

Hello Robert Pennington  the logs are showing that your USB keyboard and mouse are disconnecting and reconnecting many many times during a given programming session.  That seems to be strongly correlated with the lags that are logged by the console, so I would suggest checking those connections and possibly running without that gear for a while to see if that improves things.  If they are hosted through a USB Hub, try plugging them directly into the console instead.

I'm also noticing a possible issue with your network setup - You may need to remove the "Default gateway" in your Network port that is currently offline.

Hello Robert Pennington  the logs are showing that your USB keyboard and mouse are disconnecting and reconnecting many many times during a given programming session.  That seems to be strongly correlated with the lags that are logged by the console, so I would suggest checking those connections and possibly running without that gear for a while to see if that improves things.  If they are hosted through a USB Hub, try plugging them directly into the console instead.

I'm also noticing a possible issue with your network setup - You may need to remove the "Default gateway" in your Network port that is currently offline.

The keyboard and mouse are on a KVM to switch between console and a KVM computer matrix

I would suggest this is a very bad idea. Every time you switch between your computer and console you are mounting/unmounting USB devices from each system which will cause some delays in processing. This might not cause massive issues on your computer as most tasks can just wait until the resources become available, but on a console which is constantly processing fades and rendering this has the potential to slow down those actions.

This is not just theoretical either, I have seen this myself in the past.

Makes sense that switching the usb devices would cause a spike in processing, but how would that cause the CPU to stay pinned at 90% or so? It's not just for brief periods of time, it's constant until a deep clear is run.

I'm not sure exactly what under the hood with KVM might cause that higher usage.  Are you able to run your console for a day and avoid switching, to see if that makes a difference?  Are you able to remove the Gateway IP from your unused Ethernet port to see if that makes a difference?

I have removed the second gateway IP, we'll see if that helps. Unfortunately I need to be able to use the same keyboard and mouse with both the console and computers for now.

I haven't had an issue with this since removing the default gateway on that port. Do you know why that would've been causing issues?

I don't precisely know why that would be causing an issue, but the system logs were full of a message like "Event=Error, Source=IPRIP, ID=29031, IPRIP was unable to add a route to the system route table."  It's possible that the underlying OS was working very hard to figure out where to route ethernet traffic.

We could have a look to see if that message is no longer being logged.