ICM simulation controller

[boiermoflea]

Hi,

Is there a way to see which user is sending simulation to which PC without login in to the coordinator?
I am asking this because I do not have admin rights to login into the coordinator, and because I am running sims which sometimes takes 20 hours or more. I shouldn't need admin rights just to see who is running on what pc, how many slots they are using.
Also I have noticed that when you send sims onto one PC the free slots number is not always the right number, how can we increase the refresh rate for this number to be accurate?

Thanks!

[Andy Bolden]

Hi,

Is there a way to see which user is sending simulation to which PC without login in to the coordinator?
I am asking this because I do not have admin rights to login into the coordinator, and because I am running sims which sometimes takes 20 hours or more. I shouldn't need admin rights just to see who is running on what pc, how many slots they are using.
Also I have noticed that when you send sims onto one PC the free slots number is not always the right number, how can we increase the refresh rate for this number to be accurate?

Thanks!

The points you have raised are ones I have raised in the past because when something goes wrong it is difficult to trace. Even if you can login to the Coordinator the information you get is not user-friendly and it is surprising what it not available. When I say 'available' I am referring to the log files. Having trawled through log files on several machines to look for a possible fault in the last week I was not able to spot an obvious issue (even though the log files were set to 'Trace') so I sent extracts to Innovyze for their thoughts. An example is that you can see when a job comes from a user (by name and by their PC identifier). You can see when (in our case) a simulation server sends the results back to the coordinator but instead of this being by reference to its name it is by its IP address. However when a job is sent to a machine by the Coordinator it does not show where it is going to.

Another example is that the coordinator log file reports each machine advising its status to the coordinator but not what the status is. This week our simulation server was twiddling its thumbs waiting for work but there were more than 200 jobs waiting on the coordinator. It was not until I stopped and started the agent on the simulation server that the flood gates opened and the coordinator started sending jobs to it.

It does seem fundamental that the coordinator should know how many jobs there are in a queue and for which machine. It knows who sent them and which machine to send the results so it would be very good if it could share this information with users. Answering the question, who has sent 1000 jobs to run shouldn't require delving into log files.

I very much agree that there is a need for ordinary users to be able to see what is happening across the system. We tend to find that users start to realise that something is not quite right several hours after a problem arises. They have no means to check if there is a log jam somewhere. This gets followed by some investigation (which itself is time consuming) and it doesn't take much to lose a day's production (and night, depending when the problem arose).

[Martin Spiers]

The Sentinel Admin Control Centre is -some_help in working out who's using what, but doesn't show what's queued.

[boiermoflea]

Thanks Andy, Martin.
I hope that somebody from software development is looking into these issues.
Indeed Sentinel is good for looking who is using the licenses, not for simulations, which can run on your network even after you shut down the terminal (terminate the license usage).