Show HN: Visualizing disk IO activity using log-scale banded graphs
bvckup2.com
bvckup2.com
We had a need for a tool to graph IO activity at arbitrary sampling rates, so there was finally a solid excuse to do some datavis work :)
The thing I wanted to show is not the program itself, but the idea of factoring values and displaying factorization to cover several magnitude levels in one go. I suspect that this has been done before, but I couldn't find anything similar when I was researching this beforehand.
Edit: Scratch the GDI+ bit, it's just GDI.
Seems to be an odd complaint to make, to me. You could run ProcessMonitor to see what the application is doing.
Or read the excellent Windows Internals books if you've got a few weeks spare (and for Windows 10 it is missing Volume 2 at the moment - given that Windows 10 is a constantly moving target the poor book will be out of date as soon as it is written, let alone published).
Do you audit apps on Android / iOS / macOS too? I find my Android device dials home all the time and flings data out at an astounding rate, which is disappointing.
How do you use your satellite/cable/TV these days? How do you audit your entertainment systems? Mine came with the GPL on a bit of paper in the box given that it's got no end of Open Source software used inside it but I was unable to audit it - how did you manage it?
Do you read the source code of every Open Source application before running it? Have you combed over the entire Linux kernel before booting it? What do you think to Peter H. Anvin's bootloader code given that you use it every single time Linux boots? How long did auditing that take?
At what point do you start to trust an executable or code?
https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...
This relies on IO performance counters enabled for the target drive, but that's typically the case. If they are off, they can be enabled with "diskperf.exe".
I'm thinking about how to do something similar in my monitoring. How would you extend it to allow zooming on the X-axis? With a continuous log scale, or a simple linear scale, it's easy to know how to compress the data horizontally: take the min/max/avg of the datapoints that go in to one horizontal pixel. I'm not sure how to apply that to your discrete log scale; it seems to work on the assumption that points along the X-axis are discrete.
Edit: I said Y-axis, I meant X-axis. I'm embarrassed.
Well, the whole point is to NOT need to do any Y-scaling. What would be the case for zooming in?
The simplest option would obviously be to just show a conventional candlestick when zoomed out. There might be an option to do something interesting with rendering the stick when min/max have the same higher-order factors... but it might also end up looking like a royal mess.
This is just pure nick picking, your current design probably suit your need already.
Why sampling rate is fixed then?
The tradition way to solve this is to rescale the y axis (for example google stock price chart ranges from 1000-1200). But this doesn't work for graphing IO because it spikes up/down too often in a huge range.
Your visualization plots the base-1024 digits so whenever the IO is sustained at a certain range, the top few digits will be held constant and the next digit will show the variation within that scale.
Unfortunately I don't think this solves the spiking problem completely. It's mentally hard to parse since two adjacent values are only comparable whenever their top digits match.
For example it's only meaningful to compare (1gb+2mb+3kb) with (1gb+2mb+5kb) on the kb graph. If it spikes down to 0gb+0mb+0kb, you need to switch to reading the gb graph (since comparing the kb value to one before is pretty meaningless unless for some crazy reason you actually care about the mod 1024 value of two very different numbers).
To fix this, you should color code the "runs" of values that are meaningful to compare! In other words, kb values have the same color only if their gb/mb values match. And mb values have the same color if their gb value matches.
Hard part would be how to do this over a long span of columns without the whole thing looking like a unicorn puked on the chart...
https://community.grafana.com/t/advanced-graphing-part3-righ...
It can be kinda hard to see if two neighboring entities are the same in a given band (kbs, mbs, gbs), because you're looking for the absence of a difference of a pixel or two. Maybe if they are the same and neighboring, join the two columns rather than have them spaced? That would visually instantly tell you that those two samples are the same.
Process Explorer [1] can show some small graphs as tray icons but there is not much detail visible without opening the main application's window.
XMeters [2] does a little more but its configuration is very inflexible and clicking on any item just opens the plain Windows Taskmanager instead of showing additional details and graphs like iStat Menus.
[0] https://bjango.com/mac/istatmenus/
[1] https://docs.microsoft.com/en-us/sysinternals/downloads/proc...
How do you deal with a value of 0?
Do you use the same distance between "0" and 1 as between 1 and 10?
On a different note:
In a lot of cases I prefer using something like sqrt(data) or data^(0.x) because a) it smoothly supports the case of 0 and b) it squashes the data less than log.
Regarding b): In a lot of cases I think that log() squashes the information too much and you easily lose a sense of scale. A scaling funtion like sqrt(data) still squashes data with high values but it maintains the feeling of "Oh, this value is much higher than that value" better than log(data).
In this case, the slope of each dataset is the important thing, and very low values are probably too noisy to give you information anyways
1: https://en.wikipedia.org/wiki/File:Influenza-2009-cases-loga...
We are a desktop software shop, so mobile browser support hasn't been a top priority.
Ah, scratch that. I see the issue!... Check now?
Maybe it is some kinda of secret society code: "I'm sorry Dave, I can not do that... TWO!!!!"
If your read/write rate is not constant, such as in the non-optimized file copy and you display the rate mod 1024 in the first band, I expect to see seemingly random bars that would not show any meaningful information. What am I missing?
No my samples, but the buffer sizes in read/write requests are multiples of 1 MB.
Consider when a disk driver would update its read/write counters - it happens when a request is completed, so even if a request takes longer than a sampling interval to complete, the byte counter will still go up in buffer size, atomically.
This was run on OSx, linux users can use strace to watch for open files, much better performance.
# Using lsof in a loop (no sudo required) (while :; do lsof |gsed -r "s#(\w+)\s+.\s+(.+)#$(gdate +"%s")\|\1\|M\|\2#;t;d";done) | \ gource --realtime --filename-time 2 --highlight-users --1280x800 --log-format custom -
# Using Dtrace (better option, could replace with opensnoop possibly but still requires dtrace) sudo dtrace -n 'syscall::open:entry { printf("%u|%s|%s",walltimestamp,execname,copyinstr(arg0)); }' | \ gsed -r 's#.+ ([0-9]{10}).+\|(.+)\|(.+).+#\1\|\2\|M\|\3#;t;d' |\ gource --realtime --filename-time 2 --highlight-users --1280x800 --log-format custom -
This is an internal tool that just happens to produce good looking graphs, so we released a build to let people play with it if they want to. It's not a beta of a product, more of a tech demo... if even that.
There are plenty of alternative tools for that, but the point of the article is that helps in the visualization to use a log scale.
I would see this nicely applicable to system tray icons for monitoring tools. 16 pixels - 4 log bands with 0.25 precision.
Couple requests: option to scroll the timeline, option to export the timeline, ability to view more than one drive at a time.