Tag Archives: Colin King

Linux

Colin King: Pragmatic Graphing

Leave a comment

Over the past few days I have been analysing various issues and also doing some background research, so I have been collecting some rather large sets of data to process.   Normally I filter, re-format and process the data using a bunch of simple tools such as awk, tr, cut, sort, uniq and grep to get the data into some form where it can be plotted using gnuplot. 

The UNIX philosophy of piping together a bunch of tools to produce the final output normally works fine, however, graphing the data with gnuplot always ends up with me digging around in the online gnuplot documentation or reading old gnuplot files to remind myself exactly how to plot the data just the way I want.   This is fine for occasions where I gather lots of identical logs and want to compare results from multiple tests, the investment in time to automate this with gnuplot is well worth the hassle.   However, some times I just have a handful of samples and want to plot a graph and then quickly re-jig the data and perhaps calculate some statistical information such a trend lines.  In this case, I fall back to shoving the samples into LibreOffice Calc and slamming out some quick graphs.

This makes me choke a bit.  Using LibreOffice Calc starts to make me feel like I’m an accountant rather than a software engineer.  However, once I have swallowed my pride I have come to the conclusion that one has to be pragmatic and use the right tool for the job.  To turn around small amounts of data quickly, LibreOffice Calc does seem to be quite useful.   For processing huge datasets and automated graph plotting, gnuplot does the trick (as long as I can remember how to use it).   I am a command line junkie and really don’t like using GUI based power tools, but there does seem to be a place where I can mix the two quite happily.

…read more
Source: FULL ARTICLE at Planet Ubuntu

Linux

Colin King: ..and now something seasonal

Leave a comment

The Christmas holidays are almost here and to celebrate I’ve mildly obfuscated some C that prints the lyrics to a traditional English carol.

The source code can be found here and compiled and run using:

#include
#include
#include
#define H malloc (1237) ;
#define c while
#define W >> /* fallen right tree */
#define w 2?”th”:N),p(Z[2]);c(true+Q)p(q|Q?Q?
N:4[Z]:”a “),P(1[Z],Q),p(Q>1?”, “:N),–
Q;p(“.nn”),++q;}
char typedef o;void typedef d

;
o*N
=””;o
q;o*O(o
*p){o
*P,_;o*
f=P=H;c(_
=*p)_^=1,*f
++=B(1,w)|B(4
,W)|B(2,w)|
B(8,W)|(_&240
),++p,*f=false;
return P;}d p(o*f
){fputs(f,stdout);}
d P(o*s,o o){c( o
–){c(122-*s)s++; s
++;}c(122-*s)putchar(
*s++);} o main(void){o*
Z[]={O(“hgy}p{}dmnj`{pcg”
“y`{hny{hgh{}gs{}dxdj{”
“dglc{jgj{pdj{dbdxdj{p|d”
“bh{“),O(“qeypyg`ld!gj!e!q”
“dey!pydd{p|n!ptypbd!`nxd}{p”
“cydd!Hydjmc!Cdj}{hnty!mnbbw!i”
“gy`”
“}{h”
“gxd”
“!ln”
“b`d”
“j!ygjl}{}gs!ldd}”
“d&e&bewgjl{}dxdj”
“!}|ej}&e&}|gff”
“gjl{dglcp!feg`”
“}&e&fgbogjl{jgjd!be`gd}!`ejmgjl{pdj!bny`}&e&bdeqgjl{”
“dbdxdj!qgqdy}&qgqgjl{p|dbxd!`ytffdy}!`ytffgjl{“) ,O (
“!`ew!nh!Mcyg}pfe}!fw!pytd!bnxd!lexd!pn!fd!”),O(“Nj!p”
“cd!”),O(“!ej`!e!”)};L L L L L L L L L L L L /*Xmas*/}

Source: Planet Ubuntu

Linux

Colin King: Debugging using Visualisation.

Leave a comment

There are many different classes of bugs and hence many different debugging techniques can be used.   Sometimes there is a lot of complexity in a problem and it is hard to make a mental model of what exactly is going on between multiple interdependent components, especially when non-deterministic behaviour is occurring.

Unfortunately the human mind is limited; there is only so much debugging state that it can follow.  The problem is compounded when a bug manifests itself after several hours or days of continuous execution time – there just seems like there is too much state to track and to make sense from.

Looking at thousands of lines of debug trace and trying to spot any lurking evidence that may offer some hint to why code is failing is not trivial. However the brain is highly developed at making sense of visual input, so it makes sense to visualise copious amounts of debug data to spot anomalies.

The kernel offers many ways to gather data, be it via different trace mechanisms or just by using plain old printk().   The steps to debug are thus:

1.  Try and find a way to reliably reproduce the problem to be debugged.
2.  Where possible, try to remove complexity from the problem and still end up with a reliable way of reproducing the problem.
3.  Rig up a way of collecting internal state or data on system activity.   Obviously the type of data to be collected is dependant on the type of problem being worked on.   Be careful that any instrumentation does not affect the behaviour of the system.
4.  Start collecting data and try to reproduce the bug.  You may have to do this multiple times to collect enough data to allow one to easily spot trends over different runs.
5.  Visualise the data.

Iterating on steps 2 to 5 allow one to keep on refining a problem down to the bare minimum required to corner a bug.

Now step 5 is the fun part.  Sometimes one has to lightly parse the output to collect specific items of data. I generally use tools such as awk to extract specific fields or to re-munge data into a format that can be easily processed by graphing tools.  It can be useful to also collect time stamps with the data as some bugs are timing dependant and seeing interactions between components is key to understanding why issues occur.  If one gathers multiple sets of data from different sources then being able to correlate the data on a timestamp  can be helpful.

If I have just a few tens of hundreds items of data to visualise I generally just collate my data into tab or comma separated output and then import it into LibreOffice Calc and then generate graphs from the raw data.   However, for more demanding graphing I normally resort to using gnuplot.   Gnuplot is an incredibly powerful plotting tool – however for more complex graphs one often needs to delve deep into the manual and perhaps crib from the very useful worked examples.

Graphing data allows one to easily spot trends or correlate between seemingly unrelated parts of a system. What was originally an overwhelmingly huge mass of debug data turns into a powerful resource.   Sometimes I find it useful to run multiple tests over a range of tweaked kernel tuneables to see if bugs change behaviour – often this aids understanding when there is significant amounts of inter-component complexity occurring.

Perhaps it is just the way I live to think about issues, but I do recommend experimenting with collecting large data sets and creatively transforming the data into visualise representations to allow one to easily spot issues.  It can be surprising just how much one can glean from thousands of seemingly unrelated  traces of debug data.

Source: Planet Ubuntu