"There are 10 kinds of people in the world ...those who understand binary and those who do not"

A primer in numbering systems

There are four basic numbering systems that are used in the human, networking, and computer science worlds. Binary, octal, decimal and hexadecimal. Decimal, the numbering system we are most familiar with has a base, or radix, of 10 and to us this is natural. Why 10? Most of us have 10 fingers and that is how it was selected as our numbering system; it's as simple as that. The Yuki people of California on the other hand (pun intended) use an octal numbering system, counting the spaces between their fingers and not the fingers themselves. Pretty cool, huh?

The other systems widely in use in the networking and computer science world are binary, octal and hexadecimal (See table below). In this tutorial we'll concern ourselves only with binary, decimal and hexadecimal, ignoring octal altogether. As a side note, one use of octal numbering is with Linux and UNIX systems to set file permissions using the chmod command.

It's all just ones and zeros - bits and nibbles and bytes oh my!

Yes, we're talking binary here. I start here by asking that you don't think of a binary number as being a just series of 1's and 0's, such as 01000001 (65 decimal), but rather as a valid numbering system. So, why binary and not decimal? Take our previous example of 01000001. It's really a sort of computer Morse code, but instead of dots and dashes, it's the presence or absence of state, on or off; whether it be electrical pulses on an Cat5 cable or the state of transistors within a CPU or memory stick. Individually a bit, that is a 1 or 0, is pretty useless. However, put them together in a byte (8 bits) for example, then you have something. With our previous example, the byte 01000001 represents the character 'A'. With the computer's ability to process and transmit millions of bytes in miliseconds it can give us letters, words, pictures, music, videos and oodles of other things almost instantly. No matter what we type or create via keyboard or mouse, eventually it all gets translated into a numerical series of 1's and 0's to represent our intent. So, you see it IS all just 1's and 0's! Oh, I almost forgot ...a nibble is half a byte, 4 bits.

Thinking in binary

With the decimal numbering system we have 10 digits to work with, 0 thru 9 and when we count we start at 0, then 1, then 2 and so on until we reach 9. Then what? Well, we've run out of digits. So, we start again at 0, but we place a 1 to the left giving us 10 (ten). And once the 1's and 10's columns reach 9 and 9 (99) they  both flip, giving us 100. Same thing goes with binary except we only have 2 digits to work with, 1 and 0.

The principal is the same we start at 0 then 1, then ...well, we've run out of digits haven't we? So, we flip that 1 to 0 and place a 1 to the left giving us 10 (two). Increment by 1 again and we have 11 (three) and once again they both flip and we move into a new column giving us 100 (four). This is probably not so bad for small numbers, but once you get past 8 or so binary digits it becomes unmanageable. I mean what does 10011100 equate to in human terms? Don't even mention that binary numbers are unwieldy; 3,000 is 101110111000 in binary ...geez! So, while it is true that we need to think in binary, we can represent these binary numbers in a more human friendly form. Anyone say decimal? Fortunately we have the ability (and absolute need) to convert between the two. 

Converting binary to decimal

For this section I'll start by examining and explaining the table below.

• First thing  to take note of is that there are 8 individual bits giving us a byte. When working with IP addresses, networking folks refer to this as an octet. Obviously, binary numbers can be larger than a simple byte. However, the byte is the most basic representation of data and as such, for the most part, we'll stay at the byte level.

• The 'Bit Set' row is for our binary digits, either 0 or 1. Here they are all 1.

• The 'Exponent Value' row is how we arrive mathematically at the 'Decimal Value' row. An exponential value such as 2³ means 2 x 2 x 2 = 8. By the way, any number with an exponent of 0 ALWAYS equates to 1 (2⁰ = 1 and 400⁰ also = 1).    

• The 'Decimal Value' row represents positionally the decimal value of the binary digit in question. It's imperative that you commit this row to memory. Practice by writing it down over and over 'till its part of your DNA :-)

• The labels 'MSB' and 'LSB' stand for 'Most Significant Bit' and 'Least Significant Bit' respectively. This lets us know which end of the binary number we are talking about. For example, if I had a binary number of 11010101 and I say 'Starting at bit 1' ...that might be confusing. However, if I say 'Starting with the bit at LSB 1'. Well, you get the picture.

Previously we talked about thinking in binary means knowing how to count in binary and that still holds valid, but now, in order to convert between the two, we are going to only concern ourselves with the position of each binary digit as it relates to its decimal equivalent. What?? OK, take for example the binary number 00001010. Referring to the table above just add the positional decimal equivalents where the 1's occur. So, 00001010 means 128 (no), 64 (no), 32 (no), 16 (no), 8 (yes), 4 (no), 2 (yes) 1 (no). Given that, we see that 8 + 2 =10. In other words 00001010 binary is 10 decimal. Here are a few more examples.

• 11000000 - 128 + 64 = 192

• 00000001 - = 1

• 00110011 - 32 + 16 + 2 + 1 = 51

• 11011011 - 128 + 64 + 16 + 8 + 2 + 1 = 219

• 00000000 - = 0

• 11111111 - 128 + 64 + 32 +16 + 8 + 4 + 2 + 1 = 255

If you encounter a binary number less than a byte such as 11001 (25 decimal), just pad the missing binary digits with 0's, making the number 00011001, a complete byte. Also, if you are presented with a binary number larger than a byte then double the decimal number with each subsequent binary position to the left. See table below. Later, when we work with subnetting, we'll use these larger values. 

At this point you should be comfortable with converting binary to decimal. Now let's go the other way, decimal to binary. I'll show you two different methods. Use the one that best works for you.

Method 1 - Process of Elimination

This method is pretty straight forward. The first thing to do is write down the decimal value row previously covered.

Next, somewhere off to the side, write down your decimal number. With a byte, or octet, the smallest number is 0 and the largest 255, so your number must be within this range. Next, follow the procedure below:

Compare the decimal number with the MSB (128). If your number is larger than or equal to 128 then place a 1 under the 128 column, subtract 128 from your number and move to the next position (64). However, if your number is less than 128 then place a 0 under the 128 column and move to the next number (64) without subtracting.

Repeat the above process with 64, 32, 16 etc. until your original number is reduced to zero. If you reach zero before reaching the LSB (1) fill in the remaining columns with 0's. below are a few examples:

Method 2 - Divide and Conquer

This method has you repeatedly dividing a decimal number by 2 and saving the remainder, either 1 or 0, as a binary digit. Keep doing this until, again, your original number has been reduced to 0. It's not as confusing as it sounds. Let's walk through an example:
Refer to the example above. Given the decimal number 41 and the divide-and-conquer method, we derive its binary equivalent with the following logic:

• 41 divided by 2 is 20, remainder 1. Place a 1 in the remainder column and 20 in the division column. This is the LSB and will be the rightmost binary digit.

• 20 divided by 2 is 10, remainder 0. Place a 0 in the remainder column and 10 in the division column.

• 10 divided by 2 is 5, remainder 0. Place a 0 in the remainder column and 5 in the division column.

• 5 divided by 2 is 2, remainder 1. Place a 1 in the remainder column and 2 in the division column.

• 2 divided by 2 is 1, remainder 0. Place a 0 in the remainder column and 1 in the division column.

• 1 divided by 2 is 0, remainder 1. Place a 1 in the remainder column and we're done ...

... well almost. Our solution came out to be only 6 binary digits long. Since we are working with bytes, just pad the left with 0's until the binary number is 8 digits in length. One more thing. Your last operation will always be 1/2 = 0, remainder 1. Here a couple more examples:

 

Binary and decimal numbers larger than a byte

At times you might have a binary or decimal that is larger than a byte. Don't panic. All you need to do is extend the binary byte row to the left, doubling as you go along.

now becomes the following if we have a 12 bit binary number:

Here is a sample conversion from binary to decimal using process of elimination:

Moving on to hexadecimal

Just when you got your head around binary and decimal, along comes hexadecimal, hex for short. Before, I mentioned that everything in the computing and networking arena is nothing more that 1's and 0's and that axiom remains unchanged. We now know how to convert back and forth between binary (what the computer speaks) and decimal (what we speak), so why do we even need hex? Besides being an efficient numbering system, hexadecimal is widely used to represent to us humans the 1's and 0's that traverse circuits and wires. A few examples where hex numbers are used are colors, memory references, IPv6 addresses and MAC addresses. Let's explore this a little more in detail.

A binary byte is exactly eight digits long, e.g. 00101110 and a hex byte number is exactly two digits in length, e.g. 6A. A decimal byte on the other hand is anywhere between one and three digits long, e.g. 4, 64 or 233. Yes, you could pad these with 0's making 004, 064 and 233, but this is still not as efficient or as practical as hex. (as we'll see when we start converting hex and binary numbers). Download myextended ASCII table; it will help with the following illustration and serve as a useful refernece for your studies:

 This screenshot is a memory dump of my computer. Imagine if those numbers were represented in binary!

Let's get on with it.

What the hex are you talking about?

Below is a hex table with decimal equivalents:

With hex, the first 10 digits, 0 thru 9, are the same as decimal. However, 10 thru 15 decimal are represented as a single hex digit A thru F. The number 5 in decimal is 5 in hex and the number 13 in decimal is D in hex. What happens when we reach F (15 decimal) and need to increment by 1 is that, just like with all other numbering systems, we flip that to 0 and place a one to the left. 0xF + 0x1 = 0x10. What is this 0x business? Placing 0x in front of a hex number is the typical way to indicate it's really hex. It makes it clear that 11 (decimal) and 0x11 (hex) are two different numbers entirely. So, from here on out I'll use the 0x to indicate hexadecimal numbers. Sometimes you'll see the hex numbers 0xA thru 0xF written in lower case (0xa thru 0xf). There's nothing wrong with that and it does not change the numerical value of the number in question. I use caps in this how-to.

Binary to hex - nibbles and bits

To convert a binary byte to hex byte, first split the binary number into two nibbles, treating them as separate numbers, and then compute the hex equivalent for each half. Finally, concatenate the two hex numbers into a single solution. This works perfectly because a nibble has a value from 0 thru 15 or 0x0 thru 0xF.

Here's some examples:

Binary to hex - bits and nibbles

The conversion process from hex to binary is not much different, we just reverse the process. A picture is worth a thousand words. Here's 4,000 of them.

Once in a while you may find yourself presented with a binary or hex number larger than a byte. The methods are the same, just expanded. If you have a binary number to convert then you may have to pad the MSB with 0's in order to have a binary number that falls on nibble boundaries, multiples of 4. For example, the binary number 1001100101 won't convert correctly, because it's ten digits in length. Add two 0's making the number 001001100101. A few illustrations:

Decimal to hex - tens to sixteens

Up to now we've been able to accomplish our conversions armed with only paper and pencil. It's time to break out your calculator for converting decimal to hex and vice versa. Take  Look at these decimal / hex equivalents:
16 = 0x10  |  34 = 0x22  |  214 = 0xD6  |  175 = 0xAF
Here's how we get from the decimal value on the left of the = sign to its hexadecimal equivalent on the right. Remember the divide and conquer method we used for converting decimal to binary? We are going to use the same method except that we are going to be dividing by 16 rather than 2. The upside is that the process is a lot shorter.

• 225 divided by 16 is 14, remainder 0x1. Place a 0x1 in the remainder column and 14 in the division column. This is our rightmost hex digit.

• 14 divided by 16 is 0, remainder 14. Since we are converting to hex we use 0xE. Place 0xE in the remainder column and we're done.

• If you have a small decimal number such as 12, you'll have your answer on the first divide. 12 / 16 = 0, remainder 12 or 0xC. Place a leading 0 in from of the C to keep things uniform. So, the answer would be 0x0C

How easy is that? Here are a few more:

It's no different with numbers larger than a byte:

Hex to decimal - sixteens to tens

Whew! Nearly done. This is our last number conversion segment, hexadecimal to decimal. With a hex number each position represents a power of 16 and what we do is calculate each position's decimal equivalent and then add them all up. We are going to use a large hex number to illustrate this concept. Given the hex number 0xA59C we find its decimal equivalent with the following logic.
(10 x 16³) + (5 x 16²) + (9 x 16¹) + (12 x 16⁰) = 43,296. Here's how it breaks down:

...And a few more:

I encourage you to practice, practice, practice. Download this worksheet to work thru various conversion exercises.

Parting shot - If you are an aspiring network or systems admin then make sure you understand without question binary and decimal conversion through and through.

Coming soon - Part II Understanding IP addresses, subnet masks and subnetting.

./Robert

 以前一直不太会用这个参数。现在认真研究了一下iostat，因为刚好有台重要的服务器压力高,所以放上来分析一下.下面这台就是IO有压力过大的服务器

rrqm/s:   每秒进行 merge 的读操作数目（当系统调用需要读取数据的时候，VFS将请求发到各个FS，如果FS发现不同的读取请求读取的是相同Block的数据，FS会将这个请求合并Merge）。即 delta(rmerge)/s
wrqm/s:  每秒进行 merge 的写操作数目。即 delta(wmerge)/s
r/s:           每秒完成的读 I/O 设备次数。即 delta(rio)/s
w/s:         每秒完成的写 I/O 设备次数。即 delta(wio)/s
rsec/s:    每秒读扇区数。即 delta(rsect)/s
wsec/s:  每秒写扇区数。即 delta(wsect)/s
rkB/s:      每秒读K字节数。是 rsect/s 的一半，因为每扇区大小为512字节。(需要计算)
wkB/s:    每秒写K字节数。是 wsect/s 的一半。(需要计算)
avgrq-sz: 平均每次设备I/O操作的数据大小 (扇区)。delta(rsect+wsect)/delta(rio+wio)
avgqu-sz: 平均I/O队列长度。即 delta(aveq)/s/1000 (因为aveq的单位为毫秒)。
await:    平均每次设备I/O操作的等待时间 (毫秒)。即 delta(ruse+wuse)/delta(rio+wio)
svctm:   平均每次设备I/O操作的服务时间 (毫秒)。即 delta(use)/delta(rio+wio)
%util:      一秒中有百分之多少的时间用于 I/O 操作，或者说一秒中有多少时间 I/O 队列是非空的。即 delta(use)/s/1000 (因为use的单位为毫秒)

如果 %util 接近 100%，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘
可能存在瓶颈。
idle小于70% IO压力就较大了,一般读取速度有较多的wait.
同时可以结合vmstat 查看查看b参数(等待资源的进程数)和wa参数(IO等待所占用的CPU时间的百分比,高过30%时IO压力高)
另外 await 的参数也要多和 svctm 来参考。差的过高就一定有 IO 的问题。
avgqu-sz 也是个做 IO 调优时需要注意的地方，这个就是直接每次操作的数据的大小，如果次数多，但数据拿的小的话，其实 IO 也会很小.如果数据拿的大，才IO 的数据会高。也可以通过 avgqu-sz × ( r/s or w/s ) = rsec/s or wsec/s.也就是讲，读定速度是这个来决定的。

另外还可以参考
svctm 一般要小于 await (因为同时等待的请求的等待时间被重复计算了)，svctm 的大小一般和磁盘性能有关，CPU/内存的负荷也会对其有影响，请求过多也会间接导致 svctm 的增加。await 的大小一般取决于服务时间(svctm) 以及 I/O 队列的长度和 I/O 请求的发出模式。如果 svctm 比较接近 await，说明 I/O 几乎没有等待时间；如果 await 远大于 svctm，说明 I/O 队列太长，应用得到的响应时间变慢，如果响应时间超过了用户可以容许的范围，这时可以考虑更换更快的磁盘，调整内核 elevator 算法，优化应用，或者升级 CPU。
队列长度(avgqu-sz)也可作为衡量系统 I/O 负荷的指标，但由于 avgqu-sz 是按照单位时间的平均值，所以不能反映瞬间的 I/O 洪水。

  别人一个不错的例子.(I/O 系统 vs. 超市排队)

举一个例子，我们在超市排队 checkout 时，怎么决定该去哪个交款台呢? 首当是看排的队人数，5个人总比20人要快吧? 除了数人头，我们也常常看看前面人购买的东西多少，如果前面有个采购了一星期食品的大妈，那么可以考虑换个队排了。还有就是收银员的速度了，如果碰上了连 钱都点不清楚的新手，那就有的等了。另外，时机也很重要，可能 5 分钟前还人满为患的收款台，现在已是人去楼空，这时候交款可是很爽啊，当然，前提是那过去的 5 分钟里所做的事情比排队要有意义 (不过我还没发现什么事情比排队还无聊的)。

I/O 系统也和超市排队有很多类似之处:

r/s+w/s 类似于交款人的总数
平均队列长度(avgqu-sz)类似于单位时间里平均排队人的个数
平均服务时间(svctm)类似于收银员的收款速度
平均等待时间(await)类似于平均每人的等待时间
平均I/O数据(avgrq-sz)类似于平均每人所买的东西多少
I/O 操作率 (%util)类似于收款台前有人排队的时间比例。

我们可以根据这些数据分析出 I/O 请求的模式，以及 I/O 的速度和响应时间。

下面是别人写的这个参数输出的分析

上面的 iostat 输出表明秒有 28.57 次设备 I/O 操作: 总IO(io)/s = r/s(读) +w/s(写) = 1.02+27.55 = 28.57 (次/秒) 其中写操作占了主体 (w:r = 27:1)。

平均每次设备 I/O 操作只需要 5ms 就可以完成，但每个 I/O 请求却需要等上 78ms，为什么? 因为发出的 I/O 请求太多 (每秒钟约 29 个)，假设这些请求是同时发出的，那么平均等待时间可以这样计算:

平均等待时间 = 单个 I/O 服务时间 * ( 1 + 2 + … + 请求总数-1) / 请求总数

应用到上面的例子: 平均等待时间 = 5ms * (1+2+…+28)/29 = 70ms，和 iostat 给出的78ms 的平均等待时间很接近。这反过来表明 I/O 是同时发起的。

每秒发出的 I/O 请求很多 (约 29 个)，平均队列却不长 (只有 2 个 左右)，这表明这 29 个请求的到来并不均匀，大部分时间 I/O 是空闲的。

一秒中有 14.29% 的时间 I/O 队列中是有请求的，也就是说，85.71% 的时间里 I/O 系统无事可做，所有 29 个 I/O 请求都在142毫秒之内处理掉了。

delta(ruse+wuse)/delta(io) = await = 78.21 => delta(ruse+wuse)/s =78.21 * delta(io)/s = 78.21*28.57 = 2232.8，表明每秒内的I/O请求总共需要等待2232.8ms。所以平均队列长度应为 2232.8ms/1000ms = 2.23，而 iostat 给出的平均队列长度 (avgqu-sz) 却为 22.35，为什么?! 因为 iostat 中有 bug，avgqu-sz 值应为 2.23，而不是 22.35。