Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Storage Sensors Suggestions and Data Units Question
#1
Hello Smile

First off, thanks for all your hard work on this outstanding program ^.^

I am wondering if it is possible for you to add a sensor for lifetime-Terabytes-written to a drive ("Total Host Writes" as it's sometimes called); I believe most SSDs contain this information in their SMART data, but I could be wrong. This information is of interest to some people concerning SSD longevity in write-intensive environments, and of course it's nice not to have to break out CrystalDiskInfo every time you want to see that one piece of info.

I've also noticed that the "remaining life" percentage on SSDs defaults to 1 decimal place, but only counts down in integers so it's a bit pointless to have the extra ".0" on the end, and the same goes with every temperature sensor I've seen across the board. Not sure if this is worth bothering to fix though. Anyone can change it manually of course but it is nice to have things default to the most sensible setting in the first place, especially since changing it for every single temperature sensor in the suite can be a bit much, if you're the sort of person who's bothered by it... Tongue

I also wonder if you could put in sensors for hard drive capacity, used space, free space, etc... Although I can't imagine that no one has asked for this before, so you must have your reasons for excluding it... Again it's just nice to have any data you might possibly want to see all in one place. One can always hide those sensors if they aren't interested.

And lastly, I must bring up the dreaded "decimal vs. binary byte groupings" topic... This is really a broader question encompassing system RAM, storage, and network readings; I wonder if you have more specific information about which groupings are used for various readings? Does it just depend on the device/software that HWiNFO reads the data from?

System RAM is typically grouped by orders of 1024 (KiB, MiB, GiB, etc.) but labeled as KB/MB/GB, so I'm assuming that behavior is the same in HWiNFO (thus, I can change the units for my RAM from MB to MiB without setting any multipliers to convert values). But storage drives typically respect the newer conventions instead, where KB/MB refers specifically to orders of 1000, and orders of 1024 are labeled with KiB/MiB, so to change the units to binary I would have to set a multiplier in this case to make sure the readings are exact.

And what about network? When my Total DL says 400000MB, is that 400000x(1000^2) bytes? 400000x(1024^2) bytes?  What if I want it to display in GB/GiB instead? Should I set the multiplier to 1/1000 or 1/1024? At large values the difference is quite significant. If 1000GB is already in binary and just labeled wrong, I can change it to 1000GiB without changing the value. But if it's in decimal, I need to apply the proper multiplier which will change it to 931.3GiB. Not exactly a negligible difference. Can you shed some light on the situation for system RAM, storage, and network alike? Though I suppose depending on how HWiNFO gets its information, you may not know Sad... Well anyway... I do wonder if it's possible to set a special toggle for these types of values that just reports everything in Bytes... then we can set the exact multipliers ourselves to ensure accuracy Smile

(Oh almost forgot... on the topic of changing readings from 400000MB to 400GB, naturally the reason I'd want to do that in the first place is because reading long continuous numbers becomes difficult Tongue Any chance of allowing us to enable thousands-separators for certain sensors? Ideally we could have a US/EU mode toggle too (activate it to use "," for decimal places and "." for thousands separators everywhere, instead of the other way around).

Thanks again for all your work on this program Smile
Reply
#2
I'll put the Total Writes information on my list, but AFAIK this is a bit tricky since vendors use different encoding for this value and one needs to handle this specific for each of them.

I'll also put the displaying of decimal digits for values which are integer onto my list.

Used/free drive space is per logical drive and such information is currently not reported, but I'll think about that.

All units used by HWiNFO displayed as KB/MB/GB are in 1024 units except drive capacity, which is reported in both 1024 and 1000 units. The KB/MB/GB notation (in 1024 units) has always been used that way for decades. AFAIK the division by 1000 was introduced only lately by disk vendors to make their drives appear larger Wink

The thousands separator is a good idea I think, I will put it on my list too.
Reply
#3
(07-21-2015, 08:27 PM)Martin Wrote: I'll put the Total Writes information on my list, but AFAIK this is a bit tricky since vendors use different encoding for this value and one needs to handle this specific for each of them.

I'll also put the displaying of decimal digits for values which are integer onto my list.

Used/free drive space is per logical drive and such information is currently not reported, but I'll think about that.

All units used by HWiNFO displayed as KB/MB/GB are in 1024 units except drive capacity, which is reported in both 1024 and 1000 units. The KB/MB/GB notation (in 1024 units) has always been used that way for decades. AFAIK the division by 1000 was introduced only lately by disk vendors to make their drives appear larger Wink

The thousands separator is a good idea I think, I will put it on my list too.

Thanks Martin! That clears things up Smile I'm aware of the history but I prefer to use the newer notation just to avoid ambiguity, since "MB" can now have multiple meanings while "MiB" can't... Plus the use of Mega, Giga, etc for 1024 bothers me because it isn't consistent with conventional usage (1000 megawatts in a gigawatt, or even in other areas of computing i.e. 1GHz is 1000MHz not 1024). But I know most people find "MiB" a bit weird so... I can't really blame anyone for sticking with the traditional notation, it does have historical precedent anyway Tongue
Reply
#4
That's right. And I'm an old-fashioned guy Wink
Reply
#5
(07-21-2015, 08:27 PM)Martin Wrote: I'll put the Total Writes information on my list, but AFAIK this is a bit tricky since vendors use different encoding for this value and one needs to handle this specific for each of them.

I'll also put the displaying of decimal digits for values which are integer onto my list.

Used/free drive space is per logical drive and such information is currently not reported, but I'll think about that.

All units used by HWiNFO displayed as KB/MB/GB are in 1024 units except drive capacity, which is reported in both 1024 and 1000 units. The KB/MB/GB notation (in 1024 units) has always been used that way for decades. AFAIK the division by 1000 was introduced only lately by disk vendors to make their drives appear larger Wink

The thousands separator is a good idea I think, I will put it on my list too.

(07-21-2015, 08:58 PM)Glenwing Wrote:
(07-21-2015, 08:27 PM)Martin Wrote: I'll put the Total Writes information on my list, but AFAIK this is a bit tricky since vendors use different encoding for this value and one needs to handle this specific for each of them.

I'll also put the displaying of decimal digits for values which are integer onto my list.

Used/free drive space is per logical drive and such information is currently not reported, but I'll think about that.

All units used by HWiNFO displayed as KB/MB/GB are in 1024 units except drive capacity, which is reported in both 1024 and 1000 units. The KB/MB/GB notation (in 1024 units) has always been used that way for decades. AFAIK the division by 1000 was introduced only lately by disk vendors to make their drives appear larger Wink

The thousands separator is a good idea I think, I will put it on my list too.

Thanks Martin! That clears things up Smile I'm aware of the history but I prefer to use the newer notation just to avoid ambiguity, since "MB" can now have multiple meanings while "MiB" can't... Plus the use of Mega, Giga, etc for 1024 bothers me because it isn't consistent with conventional usage (1000 megawatts in a gigawatt, or even in other areas of computing i.e. 1GHz is 1000MHz not 1024). But I know most people find "MiB" a bit weird so... I can't really blame anyone for sticking with the traditional notation, it does have historical precedent anyway Tongue

You're right Martin, as with most of the SMART data, there are few standards regarding what attribute is which specific data item.

Even within a manufacture's range of models like Intel, they may have changed which attribute contains TBW data, as well as the way the data is encoded. I've seen Intel SSD firmware updates for a specific SSD model that changed the way the TBW data is recorded/stored and interpreted. That would cause the need for detection at the firmware level... Dodgy

At least Intel provides datasheets for their SSDs (if you can find them, and if they are up to date) that gives some information how the SMART data is encoded and interpreted. Besides Intel, good luck finding that information.

A nice idea to show that information, but the amount of work needed to do it is IMO more than we should be asking Martin to provide.
ASRock Z97 Extreme6  Intel Xeon E3-1276 v3  Scythe Mugen 4
16GB Samsung M3V 2000MTs 1.35V
SanDisk Extreme Pro 256GB Windows 8.1 UEFI boot
Samsung 840 Pro 256GB x 2 RAID 0 Windows 10 TP UEFI boot
Samsung 830 256GB x 2 RAID 0
EVGA GTX 760
Dell P2714H
Dell U2312HM
ASUS VS24A
Seasonic X660 XP2 PSU
Fractal Define R4
Reply
#6
A customizable thousands separator and displaying of some integer temperatures without decimal digits has been implemented in v5.03-2585 Beta.
Reply
#7
(07-28-2015, 04:09 PM)parsec Wrote: A nice idea to show that information, but the amount of work needed to do it is IMO more than we should be asking Martin to provide.
Fair enough. It'd be interesting information but not super important I suppose.

(08-04-2015, 09:58 AM)Martin Wrote: A customizable thousands separator and displaying of some integer temperatures without decimal digits has been implemented in v5.03-2585 Beta.

Thanks Martin! <3
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)