Mantis Bug Tracker

View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000561TunixGeneral Featurespublic2012-04-05 10:462012-04-07 12:32
Assigned ToFred 
PlatformAllOSAllOS VersionAll
Product Version0.9.24-SNAPSHOT 
Target Version0.9.24Fixed in Version 
Summary0000561: Determine Best Logging Semantics
DescriptionCurently MTX uses memory until it crashes a box if left connected to a device for any appreciable period of time. This is the default behaviour. I understand that there is some override on it, but I feel it's an inappropriate default. The idea is to log all data received from the device "just in case" the user wants it and has forgotten to start logging. This likely worked well enough on MS1 with it's limited serial speed and inefficient protocol, or even MS2 with it's inefficient protocol, but with FreeEMS it results in gross usage in a relatively short time frame.

I'm an explicit person (in every sense) and thus prefer to tell my machine what to do and shun automated stuff almost always. Therefore my personal preference would be to not have this feature at all and to simply choose to log and log directly to a file to avoid excessive memory usage during long road trips on low powered devices like 1gig eee pcs. I understand that some others might get saved by this "what was that hiccup? no stress, just save the buffered logs." but it needs a reasonable limit.

Possible solutions:

Auto log to a dated file by default, flushing the memory buffer regularly to keep it small and avoid data loss from the machine going down with a flat battery or mtx crashing. IE, do the same thing on disk (practically unlimited and more than fast enough) and keep the memory footprint as small as possible. This would be my preferred mode, as suddenly I would actually LIKE the feature.

Use a circular buffer with a fixed size (10 meg? 100 meg?) and recycle memory such that only the recent bit is auto logged. I don't like this as much, because it's still using excess RAM and isn't non-volatile during an mtx crash or battery failure.

Give users a "first launch" screen when they boot into mtx that allows them to set their preferences for things like this and the colour style in tables once and forget them. This could be combined with an in-app configuration screen, too, if desired: "to change these at any times, choose X menu and Y option".

There might be other solutions, but the current setup doesn't work for me, and I don't want to see FreeEMS users having these experiences.
Additional InformationAttached screeny of top showing MTX (up about 12 hours) using as much memory as my firefox instance, which has been up for a week (168 hours) and has 157 tabs open! :-o

It's also using more CPU than anything else (eclipse didn't even make the chart!!!), however I feel that that's totally acceptable considering the data processing that it's doing to get data to the screen in a human readable way.

I've had my box fucked by mtx doing this three times disrupting my productivity and losing data.
TagsNo tags attached.
FirmwareVersionall of them
Attached Filespng file icon 2012-04-05-121859_610x328_scrot.png [^] (41,640 bytes) 2012-04-05 10:46

- Relationships

-  Notes
User avatar (0001396)
ToxicGumbo (reporter)
2012-04-06 07:11

I agree with the "first launch" approach and in-app configuration of ideal preferences (and nearly created an issue on that topic a few minutes ago). Perhaps more extreme settings changes (ie. ECU choice or "offline" mode) could prompt the user to restart the application for settings to take effect. Options for "prompt at every launch" or "reset to defaults" could also be provided. Additionally, I was planning MegaTunix duration tests to see what might change if the application's left open for long periods of time, so seeing *expected* memory growth in a short amount of time's a bit surprising. I, too, have a netbook with scant resources that would be good for nonstop use and feedback during extended roadtrips, though I realize that poses different needs and conditions from just sitting in a garage and casually tuning.
dandruczyk (viewer)
2012-04-07 12:32

The automatic log is mainly for users who connect, start tuning and realize (oh @#$#^$!! I forgot to start datalogging!), they can then use the auto-log which is running since startup. It also allows dual logging, the auto-log logs every variable, the user selectable loggging can choose any/all or a subset of them, and both can be run simultaneously. It is atypical for an END USER to run it for 12 hours straight. That is an EXTREME fringe case.

Logging to a file is a good idea, and will probably be implemented, whether mtx saves that file on close or deletes it however is open to discussion.

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker