Topics

System Console


Dave Sand
 

Should the JMRI System Console be automatically started with an opt out option?

Dave Sand


Randall Wood <rhwood@...>
 

What do you mean by “an opt out option”?

On 28-Jun-2020, at 13:24, Dave Sand <@davesand> wrote:

Should the JMRI System Console be automatically started with an opt out option?

Dave Sand



Dave Sand
 

Opt out means that the user can choose to not have the system console start automatically.

Dave Sand

----- Original message -----
From: "Randall Wood via groups.io" <rhwood=mac.com@groups.io>
To: jmri@jmri-developers.groups.io
Subject: Re: [jmri-developers] System Console
Date: Sunday, June 28, 2020 12:26 PM

What do you mean by “an opt out option”?

On 28-Jun-2020, at 13:24, Dave Sand <@davesand> wrote:

Should the JMRI System Console be automatically started with an opt out option?

Dave Sand



Dave Sand
 

Personally, I would not even have the opt out. The user can close or minimize it if the want.

Almost every problem in the user group starts with: Post the system console content.

Dave Sand

----- Original message -----
From: Dave Sand <@davesand>
To: "jmri@jmri-developers.groups.io" <jmri@jmri-developers.groups.io>
Subject: Re: [jmri-developers] System Console
Date: Sunday, June 28, 2020 12:31 PM

Opt out means that the user can choose to not have the system console start automatically.

Dave Sand


----- Original message -----
From: "Randall Wood via groups.io" <rhwood=mac.com@groups.io>
To: jmri@jmri-developers.groups.io
Subject: Re: [jmri-developers] System Console
Date: Sunday, June 28, 2020 12:26 PM

What do you mean by “an opt out option”?

On 28-Jun-2020, at 13:24, Dave Sand <@davesand> wrote:

Should the JMRI System Console be automatically started with an opt out option?

Dave Sand



Randall Wood <rhwood@...>
 

We should *not* be automatically showing the console (users can opt into that if they want to now).

The reason not to automatically show the console is that maintaining a buffer of scrolling text is a relatively heavyweight task and occupies the main and GUI threads. Do you want users who don’t need the log to be complaining about how slow JMRI became (especially on Windows XP and Raspberry Pis)?

One of the things I’ve noticed about a number of problems being reported is that System Console output *does not show anything*, as the problem is not being logged, so it would be really rich to have a number of users be asked to show the System Console output when the problem they are experiencing is that logging is occurring on a resource constrained system.

Prior to the COVID stay at home situation, my club has been running JMRI for years in public shows and never needed the System Console running, so I would kind of assume that most users of JMRI are not reporting problems needing the System Console, so why make them take an action to close the System Console each and every time they use DecoderPro or PanelPro?

Randall

On 28-Jun-2020, at 13:35, Dave Sand <ds@...> wrote:

Personally, I would not even have the opt out.  The user can close or minimize it if the want.

Almost every problem in the user group starts with:  Post the system console content.

Dave Sand


----- Original message -----
From: Dave Sand <ds@...>
To: "jmri@jmri-developers.groups.io" <jmri@jmri-developers.groups.io>
Subject: Re: [jmri-developers] System Console
Date: Sunday, June 28, 2020 12:31 PM

Opt out means that the user can choose to not have the system console start automatically.

Dave Sand


----- Original message -----
From: "Randall Wood via groups.io" <rhwood@...>
To: jmri@jmri-developers.groups.io
Subject: Re: [jmri-developers] System Console
Date: Sunday, June 28, 2020 12:26 PM

What do you mean by “an opt out option”? 

On 28-Jun-2020, at 13:24, Dave Sand <ds@...> wrote:

Should the JMRI System Console be automatically started with an opt out option?

Dave Sand











Bob Jacobsen
 

AFAIK, the Console is retaining content, even if launched. Somebody can manually launch it after the error and still get the info. So it seems a bit excessive to have thousands of people have to minimize the console because a few people can’t find it in the Help menu.

What might help is getting the “Upload debug info” working again. That provides logs, profile and (many) panel files

Bob

On Jun 28, 2020, at 10:35 AM, Dave Sand <@davesand> wrote:

Personally, I would not even have the opt out. The user can close or minimize it if the want.

Almost every problem in the user group starts with: Post the system console content.

Bob Jacobsen
@BobJacobsen


Bob Jacobsen
 

Or perhaps, if the problem is people finding the Console in Help, adding more-visible buttons? That’s easy to do for PanelPro. Not sure where to put it in DecoderPro.

Bob

On Jun 28, 2020, at 10:44 AM, Bob Jacobsen via groups.io <rgj1927=gmail.com@groups.io> wrote:

AFAIK, the Console is retaining content, even if launched. Somebody can manually launch it after the error and still get the info. So it seems a bit excessive to have thousands of people have to minimize the console because a few people can’t find it in the Help menu.

Bob Jacobsen
@BobJacobsen


Dave Sand
 

Bob,

The typical scenario:
- User: I have a problem, a dialog box says there is a panel error.
- Support: Are there any errors in the system console?
- User: Huh?
- Support: Use Help => System Console, select Copy to clipboard and paste in a reply.

Actually, I combine the two support replies as one to skip the intermediate user response.

Fixing *Upload debug info* would be very helpful since that would eliminate the 20 questions syndrome. And it would be easier for the users. Since by default that includes the log files, the system console becomes less important.

Dave Sand

----- Original message -----
From: Bob Jacobsen <@BobJacobsen>
To: jmri@jmri-developers.groups.io
Subject: Re: [jmri-developers] System Console
Date: Sunday, June 28, 2020 12:46 PM

Or perhaps, if the problem is people finding the Console in Help, adding more-visible buttons? That’s easy to do for PanelPro. Not sure where to put it in DecoderPro.

Bob

On Jun 28, 2020, at 10:44 AM, Bob Jacobsen via groups.io <rgj1927=gmail.com@groups.io> wrote:

AFAIK, the Console is retaining content, even if launched. Somebody can manually launch it after the error and still get the info. So it seems a bit excessive to have thousands of people have to minimize the console because a few people can’t find it in the Help menu.

Bob Jacobsen
@BobJacobsen


Andrew Crosland
 

In a discussion on the MERG forum a user said they have seen JMRI slow down over time when running on a Pi. I have seen issues myself trying to debug using logging, but not had the time to investigate fully.

My theory is that the continual background logging (even if the console is not launched) causes an issue with the Pi's flash file system as the log file size increases. There is some correlation with low level serial (UART, SPI, I2C) being used, rather than USB, i.e., MERG CANPiCAP or Pi-SPROG hardware.

Is there anything in JMRI that causes excessive logging without an explicit change to default.lcf?

There's also a thread on the user group about latency on the Pi (same issue as the MERG forum) but that may be due to a particular user logix implementation.

I think the current behaviour is the right default behaviour. An option to keep only the last n messages in RAM might help with the file system, unless the Pi starts page swapping.

Andrew

------ Original Message ------
From: "Bob Jacobsen" <@BobJacobsen>
To: jmri@jmri-developers.groups.io
Sent: 28/06/2020 18:44:41
Subject: Re: [jmri-developers] System Console

AFAIK, the Console is retaining content, even if launched. Somebody can manually launch it after the error and still get the info. So it seems a bit excessive to have thousands of people have to minimize the console because a few people can’t find it in the Help menu.

What might help is getting the “Upload debug info” working again. That provides logs, profile and (many) panel files

Bob

On Jun 28, 2020, at 10:35 AM, Dave Sand <@davesand> wrote:

Personally, I would not even have the opt out. The user can close or minimize it if the want.

Almost every problem in the user group starts with: Post the system console content.

Bob Jacobsen
@BobJacobsen








--
Andrew Crosland


Randall Wood <rhwood@...>
 



On 28-Jun-2020, at 15:51, Andrew Crosland <andrew@...> wrote:

In a discussion on the MERG forum a user said they have seen JMRI slow down over time when running on a Pi. I have seen issues myself trying to debug using logging, but not had the time to investigate fully.

My theory is that the continual background logging (even if the console is not launched) causes an issue with the Pi's flash file system as the log file size increases. There is some correlation with low level serial (UART, SPI, I2C) being used, rather than USB, i.e., MERG CANPiCAP or Pi-SPROG hardware.

Is there anything in JMRI that causes excessive logging without an explicit change to default.lcf?

There's also a thread on the user group about latency on the Pi (same issue as the MERG forum) but that may be due to a particular user logix implementation.

I think the current behaviour is the right default behaviour. An option to keep only the last n messages in RAM might help with the file system, unless the Pi starts page swapping.

Without writing our own logger, we would not be able to control how the logger writes to file (i.e. have it hold log entries without writing until a certain number of entries or amount of time has passed). For the Pi, you could suggest that session.log not be written (comment it out in default.lcf), to only write to one log file.

Andrew

------ Original Message ------
From: "Bob Jacobsen" <rgj1927@...>
To: jmri@jmri-developers.groups.io
Sent: 28/06/2020 18:44:41
Subject: Re: [jmri-developers] System Console

AFAIK, the Console is retaining content, even if launched.  Somebody can manually launch it after the error and still get the info.  So it seems a bit excessive to have thousands of people have to minimize the console because a few people can’t find it in the Help menu.

What might help is getting the “Upload debug info” working again.  That provides logs, profile and (many) panel files

Bob

On Jun 28, 2020, at 10:35 AM, Dave Sand <ds@...> wrote:

Personally, I would not even have the opt out.  The user can close or minimize it if the want.

Almost every problem in the user group starts with:  Post the system console content.


Bob Jacobsen
rgj1927@...










-- 
Andrew Crosland



Randall Wood <rhwood@...>
 



On 28-Jun-2020, at 16:00, Randall Wood via groups.io <rhwood@...> wrote:



On 28-Jun-2020, at 15:51, Andrew Crosland <andrew@...> wrote:

In a discussion on the MERG forum a user said they have seen JMRI slow down over time when running on a Pi. I have seen issues myself trying to debug using logging, but not had the time to investigate fully.

My theory is that the continual background logging (even if the console is not launched) causes an issue with the Pi's flash file system as the log file size increases. There is some correlation with low level serial (UART, SPI, I2C) being used, rather than USB, i.e., MERG CANPiCAP or Pi-SPROG hardware.

Is there anything in JMRI that causes excessive logging without an explicit change to default.lcf?

There's also a thread on the user group about latency on the Pi (same issue as the MERG forum) but that may be due to a particular user logix implementation.

I think the current behaviour is the right default behaviour. An option to keep only the last n messages in RAM might help with the file system, unless the Pi starts page swapping.

Without writing our own logger, we would not be able to control how the logger writes to file (i.e. have it hold log entries without writing until a certain number of entries or amount of time has passed). For the Pi, you could suggest that session.log not be written (comment it out in default.lcf), to only write to one log file.

Correction: "Without writing our own logger...” should be “Without finding a logger we can replace log4j with, or writing our own logger..."

Andrew

------ Original Message ------
From: "Bob Jacobsen" <rgj1927@...>
To: jmri@jmri-developers.groups.io
Sent: 28/06/2020 18:44:41
Subject: Re: [jmri-developers] System Console

AFAIK, the Console is retaining content, even if launched.  Somebody can manually launch it after the error and still get the info.  So it seems a bit excessive to have thousands of people have to minimize the console because a few people can’t find it in the Help menu.

What might help is getting the “Upload debug info” working again.  That provides logs, profile and (many) panel files

Bob

On Jun 28, 2020, at 10:35 AM, Dave Sand <ds@...> wrote:

Personally, I would not even have the opt out.  The user can close or minimize it if the want.

Almost every problem in the user group starts with:  Post the system console content.


Bob Jacobsen
rgj1927@...










-- 
Andrew Crosland




Bob Jacobsen
 

Might be good to ask people who are seeing a slow-down check that the log files are actually growing, and if so what they contain.

JMRI shouldn’t normally log very much when there aren’t errors. It’s mean to be effectively silent after startup. If it is writing to much absent errors, we should fix that.

Many claims of a particular cause for poor performance are wrong, particularly if there’s not been a specific measurement of the cause. Systems are complex enough now that most intuitive guesses are wrong. There are lots of other things that can be causing slow-down with time.

Bob

On Jun 28, 2020, at 12:51 PM, Andrew Crosland <andrew@...> wrote:

In a discussion on the MERG forum a user said they have seen JMRI slow down over time when running on a Pi. I have seen issues myself trying to debug using logging, but not had the time to investigate fully.

My theory is that the continual background logging (even if the console is not launched) causes an issue with the Pi's flash file system as the log file size increases. There is some correlation with low level serial (UART, SPI, I2C) being used, rather than USB, i.e., MERG CANPiCAP or Pi-SPROG hardware.

Is there anything in JMRI that causes excessive logging without an explicit change to default.lcf?

There's also a thread on the user group about latency on the Pi (same issue as the MERG forum) but that may be due to a particular user logix implementation.

I think the current behaviour is the right default behaviour. An option to keep only the last n messages in RAM might help with the file system, unless the Pi starts page swapping.

Andrew

------ Original Message ------
From: "Bob Jacobsen" <@BobJacobsen>
To: jmri@jmri-developers.groups.io
Sent: 28/06/2020 18:44:41
Subject: Re: [jmri-developers] System Console

AFAIK, the Console is retaining content, even if launched. Somebody can manually launch it after the error and still get the info. So it seems a bit excessive to have thousands of people have to minimize the console because a few people can’t find it in the Help menu.

What might help is getting the “Upload debug info” working again. That provides logs, profile and (many) panel files

Bob

On Jun 28, 2020, at 10:35 AM, Dave Sand <@davesand> wrote:

Personally, I would not even have the opt out. The user can close or minimize it if the want.

Almost every problem in the user group starts with: Post the system console content.

Bob Jacobsen
@BobJacobsen








--
Andrew Crosland



Bob Jacobsen
@BobJacobsen


Steve_G
 

We are writing _two_ log files. Really?
I hope they are logging different things, that are really important.


On June 28, 2020 4:00:54 PM EDT, "Randall Wood via groups.io" <rhwood@...> wrote:


On 28-Jun-2020, at 15:51, Andrew Crosland <andrew@...> wrote:

In a discussion on the MERG forum a user said they have seen JMRI slow down over time when running on a Pi. I have seen issues myself trying to debug using logging, but not had the time to investigate fully.

My theory is that the continual background logging (even if the console is not launched) causes an issue with the Pi's flash file system as the log file size increases. There is some correlation with low level serial (UART, SPI, I2C) being used, rather than USB, i.e., MERG CANPiCAP or Pi-SPROG hardware.

Is there anything in JMRI that causes excessive logging without an explicit change to default.lcf?

There's also a thread on the user group about latency on the Pi (same issue as the MERG forum) but that may be due to a particular user logix implementation.

I think the current behaviour is the right default behaviour. An option to keep only the last n messages in RAM might help with the file system, unless the Pi starts page swapping.

Without writing our own logger, we would not be able to control how the logger writes to file (i.e. have it hold log entries without writing until a certain number of entries or amount of time has passed). For the Pi, you could suggest that session.log not be written (comment it out in default.lcf), to only write to one log file.

Andrew

------ Original Message ------
From: "Bob Jacobsen" <rgj1927@...>
To: jmri@jmri-developers.groups.io
Sent: 28/06/2020 18:44:41
Subject: Re: [jmri-developers] System Console

AFAIK, the Console is retaining content, even if launched.  Somebody can manually launch it after the error and still get the info.  So it seems a bit excessive to have thousands of people have to minimize the console because a few people can’t find it in the Help menu.

What might help is getting the “Upload debug info” working again.  That provides logs, profile and (many) panel files

Bob

On Jun 28, 2020, at 10:35 AM, Dave Sand <ds@...> wrote:

Personally, I would not even have the opt out.  The user can close or minimize it if the want.

Almost every problem in the user group starts with:  Post the system console content.


Bob Jacobsen
rgj1927@...










-- 
Andrew Crosland



--
Sent from my Android device with K-9 Mail. Please excuse my brevity.


Andrew Crosland
 

------ Original Message ------
From: "Bob Jacobsen" <@BobJacobsen>

JMRI shouldn’t normally log very much when there aren’t errors. It’s mean to be effectively silent after startup. If it is writing to much absent errors, we should fix that.
Agreed.


Many claims of a particular cause for poor performance are wrong, particularly if there’s not been a specific measurement of the cause. Systems are complex enough now that most intuitive guesses are wrong. There are lots of other things that can be causing slow-down with time.
Again, agreed. That's really why I've hesitated to say anything until this thread about system console prompted me. I've seen other behaviour causing slowness on Pi, such as moving windows around. I think it's still somehow related to the Pi-SPROGs serial activity via the UART. That was my motivation for switching to cbus/gridconnetc and implement the command station in the hardware, not in JMRI, to reduce the traffic.

Andrew



--
Andrew Crosland


Randall Wood <rhwood@...>
 



On 28-Jun-2020, at 22:57, Steve_G <RailRodder@...> wrote:

We are writing _two_ log files. Really?
I hope they are logging different things, that are really important.

We have been for years, and they are duplicates. The log files are “session.log”, the log of the current running instance (I do not know that we ever defined what happens when someone runs DecoderPro and PanelPro at the same time), and the other is “messages.log”, which contains the logs of multiple sessions.

On June 28, 2020 4:00:54 PM EDT, "Randall Wood via groups.io" <rhwood@...> wrote:


On 28-Jun-2020, at 15:51, Andrew Crosland <andrew@...> wrote:

In a discussion on the MERG forum a user said they have seen JMRI slow down over time when running on a Pi. I have seen issues myself trying to debug using logging, but not had the time to investigate fully.

My theory is that the continual background logging (even if the console is not launched) causes an issue with the Pi's flash file system as the log file size increases. There is some correlation with low level serial (UART, SPI, I2C) being used, rather than USB, i.e., MERG CANPiCAP or Pi-SPROG hardware.

Is there anything in JMRI that causes excessive logging without an explicit change to default.lcf?

There's also a thread on the user group about latency on the Pi (same issue as the MERG forum) but that may be due to a particular user logix implementation.

I think the current behaviour is the right default behaviour. An option to keep only the last n messages in RAM might help with the file system, unless the Pi starts page swapping.

Without writing our own logger, we would not be able to control how the logger writes to file (i.e. have it hold log entries without writing until a certain number of entries or amount of time has passed). For the Pi, you could suggest that session.log not be written (comment it out in default.lcf), to only write to one log file.

Andrew

------ Original Message ------
From: "Bob Jacobsen" <rgj1927@...>
To: jmri@jmri-developers.groups.io
Sent: 28/06/2020 18:44:41
Subject: Re: [jmri-developers] System Console

AFAIK, the Console is retaining content, even if launched.  Somebody can manually launch it after the error and still get the info.  So it seems a bit excessive to have thousands of people have to minimize the console because a few people can’t find it in the Help menu.

What might help is getting the “Upload debug info” working again.  That provides logs, profile and (many) panel files

Bob

On Jun 28, 2020, at 10:35 AM, Dave Sand <ds@...> wrote:

Personally, I would not even have the opt out.  The user can close or minimize it if the want.

Almost every problem in the user group starts with:  Post the system console content.


Bob Jacobsen
rgj1927@...










-- 
Andrew Crosland



-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.


Ken Cameron
 

Yes we use two different log files and both have an important part of
helping our users. The session.log records just the current session. When
they can't get the program responding it is good for seeing what the program
was doing and where it hung them up. The second file is a rotating buffer
messages.log (default 4 files, 1 Meg each) that is the record of all of the
sessions which is frequently important to find out what happened first time
around and not just their retries or to sense how it was setup before they
messed it up.

The constant writing of the session.log is critical for many of the hanging
conditions. It seldom seems to happen that it can't write at least some log
message to leave a trail.

-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.org
www.syracusemodelrr.org


Steve_G
 

Ken
Thats different from writing 2 log files, providing the log rotation happens in
a seperate low priority process.
Steve G.

---------- Original Message ----------
From: Ken Cameron <@KenC57>
Date: June 29, 2020 at 6:38 AM


Yes we use two different log files and both have an important part of
helping our users. The session.log records just the current session. When
they can't get the program responding it is good for seeing what the program
was doing and where it hung them up. The second file is a rotating buffer
messages.log (default 4 files, 1 Meg each) that is the record of all of the
sessions which is frequently important to find out what happened first time
around and not just their retries or to sense how it was setup before they
messed it up.

The constant writing of the session.log is critical for many of the hanging
conditions. It seldom seems to happen that it can't write at least some log
message to leave a trail.

-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.org
www.syracusemodelrr.org