Freezing of Screens

[Mattm]

I've been asked to investigate a problem we had with one of our
flights 2 days ago. It's an JSF flight, and apparently a number of
screens locked up in a control room during a flight. Andy has been
talking to Mike Jones, but Andy didn't leave me Mikes contact info.

One of the things we've been trying to do with some of the JSF flights
is make a correlation between something of the things they do in the
room (changing info on an Analysis Windows, changing derived
equations, then saving, importing AW's), and then some of the problems
they've been having during a flight. Andy told me, and I wanted to
confirm it, is that when someone saves the info from the config (is
doing a save all in the config tool the same as the save button on the
dashboard?) that an entries get sent to the iadsCDSLog.txt log file.

We've been looking at entries in the iadsCDSLog.txt file which Andy
pointed out has lines that start with "Receiving ~~~~~" and then lines
that say "Sending ~~~~". He said that they correlate to some of the
save actions going on. We're interested in finding out which
workstations made what changes. Do any of those entries correlate to
the entries in the adsCleintLog.txt file?

One of the questions was, when a save is made by a user in the room,
which workstations are effected by those changes. I think the answer
is all of them, but I wasn't sure. The change is sent to all the
clients, right. But what happens when I'm looking at the same screen
that was changed by a different user. Will that change when I move to
another AW and back again. I'm not fully understanding the "last man
out" rule and how the screens are effected during a flight. It seems
that some of these screens are so overloaded, that when someone makes
seemingly insignificant changes, the AW's sometimes seem to lock.
Would appreciate someones thoughts about that. Thanks

Matt M

[Michael Jones]

Hi Matt,

Andy contacted both myself and Mike Burt in parallel. Mike Burt responded first and worked with Andy on this - unfortunately I don't know anything more then the loose details.

My understanding of the problem is that the Clients are Stuttering and/or temporarily pausing during large config updates.  Does this describe the symptom or are locking up?

I haven't played with large updates in realtime for quite some time, but my understanding is that in order to see much of an effect on the clients it needs to be in the multiple thousands of updates within a short time span (i.e. something like Nullings results)

You can correlate information between the two logs using a combination of 'system time' and/or 'irig time'
System Time is the local clock time from the perspective of an individual log contributer - i.e. tied to a particular machine's clock - multiple machines can have vastly different local times.
Irig times are expressed from the perspective of 'global time' as interpreted by the CDS with regard to its primary data source. i.e. mission time

Correct - typically when a user 'saves' all changes get pushed up to the server then from there out to all the clients. In the past, the 'last man out' rule used to apply to an entire Analysis Window, now it only applies to changes. So, if multiple users change the same object, the last person's change will 'win'  Similarly if different users change different aspects of the same window, the result is a melding of the changes.

[Watzlavick, Robert L]

Our rule in FW was “no saving during a mission” unless it is very important.  Early on there were actual crashes related to saving but those have been long fixed.  However, as Mike mentions, you will get a temporary pause as each client processes the changes that were reflected out from the server.  When multiple users are sharing a desktop, the last one wins.

 

I suggest telling the users to coordinate their changes with the Test Director.  There is always the option of saving locally to preserve the changes, then doing a full save at the en d of the mission.  In the event the client crashes before the full save can be accomplished, there are two copies of the config file stored in a temp folder on the client.

 

-Bob

 

From: ia...@googlegroups.com [mailto:ia...@googlegroups.com] On Behalf Of Michael Jones
Sent: Friday, January 27, 2012 15:30
To: ia...@googlegroups.com
Subject: EXTERNAL: [I ADS] Re: Freezing of Screens

 

Hi Matt,

Andy contacted both myself and Mike Burt in parallel. Mike Burt responded first and worked with Andy on this - unfortunately I don't know anything more then the loose details.

My understanding of the problem is that the Clients are Stuttering and/or temporarily pausing during large config updates.  Does this describe the symptom or are locking up?

I haven't played with large updates in realtime for quite some time, but my understanding is that in order to see much of an effect on the clients it needs to be in the multiple thousands of updates within a short time span (i.e. something like Nullings results)

You can correlate information between the two logs using a combination of 'system time' and/or 'irig time'

System Time is the local clock time from the perspective of an individual log contributer - i.e. tied to a particu lar machine's clock - multiple machines can have vastly different local times.

Irig times are expressed from the perspective of 'global time' as interpreted by the CDS with regard to its primary data source. i.e. mission time

Correct - typically when a user 'saves' all changes get pushed up to the server then from there out to all the clients. In the past, the 'last man out' rule used to apply to an entire Analysis Window, now it only applies to changes. So, if multiple users change the same object, the last person's change will 'win'  Similarly if different users change different aspects of the same window, the result is a melding of the changes.

--
You received this message because you are subscribed to the Google Groups "IADS" group.
To view this discussion on the web visit https://groups.google.com/d/msg/iads/-/mnqfkUn0JJQJ.
To post to this group, send email to ia...@googlegroups.com.
To unsubscribe from this group, send email to iads+uns...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/iads?hl=en.

[James Bretz]

Matt,

 

Prudent words from Bob. It's best to delay your saving until on tanker or otherwise, especially when you are doing something significant. Small items are ok, such as one or two lines of equation changes, event markers, analysis, etc, but I would shy away from large table changes or desktop/aw imports, etc until you find some downtime in the test.

 

Anytime a change is "saved" by a user, those changes are sent to everyone in the room. The displays and windows don't update automagically in response to receiving those updates. The updates are just lying and waiting for the user to log out/in or to change their desktops to see the changes. In other words, once a user is running, another user can't change their configuration unless they logout and back in (or reload the desktop). The nulling system is an exception. Nulling changes are applied automatically to the users desktop. Here's an example: User A makes a change to parameter XYZ and saves the changes. The changes are sent to the server, the server sends the changes to everyone in the room. User B receives the changes. User B sees the changes in the ParameterDefaults table (automatically shows the update), but User B's parameter XYZ on their Stripchart is not changed. Does that make sense? We didn't want to risk having someone be able to change what user B is viewing on their displays without user B starting fresh (reload desktop). Another scenario. User A imports a very large desktop DEF and saves. The updates are sent to the server, and the server sends the updates to user B who is on desktop DEF... user B sees no changes (unless they reload their desktop). See the pattern? Likewise, User C gets the desktop changes for DEF, but they are on desktop GHI and of course see no changes.. but if the changes are large enough they will still see a stutter or delay. Bottom line is that everyone gets every change, they might be delayed for that change, but it shouldn't affect their window or parameters unless they reload (with an exception of nulling).

 

Inside the Logs folder, there is a file called "IadsClientLog.txt". That file should give you a good idea of what the users are doing at the time. Look for a line that says "UserAction". If a user imports a desktop, saves a table, changes an equation, etc it should let you know with the time stamp. It sounds like you are looking at the "IadsCDSLog.txt", this is helpful, but generally I would start at the IadsClientLog.txt file first. This is the center of the user activity. As Mike points out, when you find something you can use the time to correlate that to the servers actions in the IadsCDSLog.txt file.

 

Mike is right, a config update really shouldn't stutter the display unless it's fairly large (like a desktop import, or a large table import in the thousands of rows).... and, if you noted the time of the stutter, you might be able to backtrack in the IadsClientLog.txt file to a user action. If you find anything suspicious, please let us know. At one point (can't remember what customer) we saw in the logs that they were importing an entirely new Desktops into the config with approximately 50k lines of updates. That would surely cause at bit of stuttering.

 

Good luck and please let us know what you find,

Jim

From: Watzlavick, Robert L

Sent: Friday, January 27, 2012 1:42 PM

To: ia...@googlegroups.com

Subject: RE: EXTERNAL: [IADS] Re: Freezing of Screens