Closed GoogleCodeExporter closed 9 years ago
I've noted both on irc and on the forums that the next major release will have
ram feature, but it's a very difficult one to implement and experience has
shown me that such features usually take about 2 to 4 weeks to get stable
depending on the range of user data sets, and the quality of the data, which in
this case is very low, which means lots of filtering.
I had hoped for some time that /sys would grow to contain ram data, I actually
do not understand why it doesn't, but it hasn't done so at this point, so I'm
giving up on that idea and going back to the fallback of using dmidecode to
grab that data, which has several major negatives, one being that you must be
root to run dmidecode, the other being that parsing /sys is VERY fast, and much
more reliable.
But since ram is not appearing in /sys, at least not last I checked, with one
exception eec ram types, which are almost useless for most users, I decided a
while ago to just use dmidecode, which also has the advantage of giving
automatic bsd support as well without further hacks.
I have a crude outline of what -R or -M, probably -M for memory, will show,
it's a lot of data, it will show the number of memory bank arrays, usually one
or two for consumer systems, much more for servers, and I've still not seen an
actual server dmidecode output which I will need to see before planning this,
the amount of ram that each bank or array supports, per slot maxes, then the
population of the arrays, etc. The amount of information available to the
system is very finite however, sometimes there is no product name, no speed,
etc, but the capacities are generally present.
The more of these data sets: inxi -xx@14
I can get, that's the full data dump for the system, run as root, with
dmidecode installed, the better. Particularly from servers with far more ram
installed than normal, I need to build in that support from the ground up or it
will be too hard to modify smaller systems to support larger ones.
I don't have 2 to 4 free weeks at the moment nor do I expect to have that for a
while, but I can collect data in the meantime, usually the more data I have the
better, but most of inxi's datasets are generated without dmidecode installed
and not as root, so I have very few dmidecode datasets, I need at least 10 from
systems of varying age, from old redhats to bsds to real servers with tons of
ram to normal systems to laptops etc. Experience has shown me with linux/bsd
features that expecting consistency of any type in output is a major error, so
I expect inconsistency now, and try to build in support for that from the
ground up.
That's why I added the recent -w/-W weather option instead, that was a fairly
quick and easy hack that only took a few days of coding and debugging to get
stable, now stable in 1.9.7 for the time being.
memory support will be in either 1.10 or 2.0, depending on the version
numbering selected, probably 1.10 to avoid the now disgustingly popular version
number inflations made popular by firefox and google chrome browser.
It's alwasy important, of course, to grasp that inxi won't add this feature, I
will, and that takes a lot of work and time. I used to make the mistake of
thinking new features would be easy (-R raid and -s sensors come to mind as
some of my more radically wrong guesses in terms of how long it would take to
get them stable, and how many user data sets would be required to actually get
the programming to handle most cases out there that exist), but I have learned
my lesson, difficult features are not easy and always cost me roughly one month
of time as a dev, between data collection, analysis, programming, debugging,
rewriting, debugging, data collection, analysis, etc...
So yes it's the next major feature planned, but don't hold your breath for the
release day, it will come when it comes.
Original comment by inxi-...@techpatterns.com
on 28 May 2013 at 7:14
Expecting.......
Original comment by leafonsw...@gmail.com
on 29 May 2013 at 5:48
Issue 49 has been merged into this issue.
Original comment by inxi-...@techpatterns.com
on 10 Jan 2014 at 6:02
Issue 54 has been merged into this issue.
Original comment by inxi-...@techpatterns.com
on 29 Mar 2014 at 5:53
By the way, I lied, ram/memory support will be in a future release, not 2.0,
since inxi is now at 2.1.x (2.0 was systemd/upstart/ etc support), 2.1 was,
ongoing, line wrapping dynamically.
So ram is down the road, I keep holding out for /sys ram data, it will be there
one day, like motherboard stuff was.
Original comment by inxi-...@techpatterns.com
on 29 Mar 2014 at 10:42
Original comment by inxi-...@techpatterns.com
on 5 Apr 2014 at 7:13
Original comment by inxi-...@techpatterns.com
on 5 Apr 2014 at 7:13
Original comment by inxi-...@techpatterns.com
on 5 Apr 2014 at 7:14
I've laid the crude groundwork for -m Memory in the current trunk, but the
actual functions are not created, but this feature may come within 2 months or
so.
I don't see any other things except bug fixes, 2.1.x is stable now give or
take, the wrapping of lines is largely done, the init system feature of 2.0 is
stable, most other bugs have been fixed as found or reported.
I've been looking at the dmidecode output to get a better sense of what can and
can't be done, I'm going to use type 16 and 17, 16 identifies the memory array,
and 17 is the slot. I wish I could use 5/6 because they have more information,
but that is not consistently present across systems and it's actually hard to
know how to match up the 5/6 stuff with the 16/17 stuff without pure guesswork
on inxi's part, but I may just add those guesses as -xx type data anyway, which
can be missing or present, I'll see how that goes, but the first version will
probably use 16/17 types, because those seem to always be present in all my
dmidecode output samples.
Again, nothing functional will appear for a while, quite a while possibly, but
the framework for testing/debugging has been added to trunk/inxi so I can keep
that going with bug fixes while testing memory in branches/one/inxi
Original comment by inxi-...@techpatterns.com
on 14 Apr 2014 at 9:07
Look for -m in 2.2 release, whenever that comes. I don't see any other real new
features that might come first, so 2.2 will probably be it.
Original comment by inxi-...@techpatterns.com
on 14 Apr 2014 at 9:09
inxi 2.1.90 now has initial memory handling. inxi -m
I have not completed this feature, but its basically working. Still to come are
-x, -xx, and -xxx extra data, and some other stuff, but the basic stuff most
people need is now live.
I will wait for feedback on this thread before closing this issue since this
only went live in stable inxi today.
Original comment by inxi-...@techpatterns.com
on 12 Aug 2014 at 5:32
Closing this issue, for all actual issues with ram/memory data, start a new
issue report. 2.1.96 is close enough to final where it can be considered to
close this issue.
Original comment by inxi-...@techpatterns.com
on 15 Aug 2014 at 4:45
Original issue reported on code.google.com by
leafonsw...@gmail.com
on 28 May 2013 at 7:06