Section 8.4. busstat Command

8.4. busstat Command

The busstat command monitors bus statistics for systems that contain instrumented buses. Such buses contain Performance Instrumentation Counters (PICs), which in some ways are similar to the CPU PICs.

8.4.1. Listing Supported Buses

busstat -l lists instrumented buses that busstat can monitor.

# busstat -l busstat: No devices available in system. 

If you see the "No devices available" message, then you won't get any further. Find another system (usually a larger system) that responds by listing instance names. The following is from a Sun Enterprise E4500.

# busstat -l Busstat Device(s): sbus1 ac0 ac1 ac2 ac3 ac4 sbus0 sbus2 sbus3 sbus4 

The output of busstat -l has now listed six devices that provide PICs for us to use. sbus is for SBus, the interconnect bus for devices including peripherals; ac is for Address Controller.

8.4.2. Listing Bus Events

The -e switch for busstat lists events that a bus device can monitor. Here we list events for ac0.

# busstat -e ac0 pic0 mem_bank0_rds mem_bank0_wrs mem_bank0_stall mem_bank1_rds mem_bank1_wrs mem_bank1_stall clock_cycles ... pic1 mem_bank0_rds mem_bank0_wrs mem_bank0_stall mem_bank1_rds mem_bank1_wrs mem_bank1_stall clock_cycles ... 

The list of events for each PIC is very long; we truncated it so that this example doesn't fill an entire page.

It can help to use the pr command to rework the output into columns. The following example does this for the sbus0.

# busstat -e sbus0 | pr -t2 pic0                                pic1 dvma_stream_rd                      dvma_stream_rd dvma_stream_wr                      dvma_stream_wr dvma_const_rd                       dvma_const_rd dvma_const_wr                       dvma_const_wr dvma_tlb_misses                     dvma_tlb_misses dvma_stream_buf_mis                 dvma_stream_buf_mis dvma_cycles                         dvma_cycles dvma_bytes_xfr                      dvma_bytes_xfr interrupts                          interrupts upa_inter_nack                      upa_inter_nack pio_reads                           pio_reads pio_writes                          pio_writes sbus_reruns                         sbus_reruns pio_cycles                          pio_cycles # 

The first column lists events for pic0; the second are events for pic1.

Unlike cpustat, busstat does not finish by listing a reference manual for these events. There is currently little public documentation for bus events^[4]; most Internet searches match only the man page for busstat and the event names in the OpenSolaris source. Fortunately, many of the event names are self-evident (for example, mem_bank0_rds is probably memory bank 0 reads), and some of the terms are similar to those used for CPU PICs, as documented in the CPU manuals.

^[4] Probably because no one has asked! busstat is not in common use by customers; the main users have been engineers within Sun.

8.4.3. Monitoring Bus Events

Monitoring bus events is similar to monitoring CPU events, except that we must specify which bus instance or instances to examine.

The following example examines ac1 for memory bank stalls, printing a column for each memory bank. We specified an interval of 1 second and a count of 5.

# busstat -w ac1,pic0=mem_bank0_stall,pic1=mem_bank1_stall 1 5 time dev    event0               pic0        event1               pic1 1    ac1    mem_bank0_stall      2653        mem_bank1_stall      0 2    ac1    mem_bank0_stall      2039        mem_bank1_stall      0 3    ac1    mem_bank0_stall      3614        mem_bank1_stall      0 4    ac1    mem_bank0_stall      3213        mem_bank1_stall      0 5    ac1    mem_bank0_stall      2380        mem_bank1_stall      0 

The second bank is empty, so pic1 measured no events for it. Memory stall events are interestingthey signify latency suffered when a memory bank is already busy with a previous request.

There are some differences between busstat and cpustat: There is no total line with busstat, and intervals less than one second are not accepted. busstat uses a -w option to indicate that devices are written to, thereby configuring them so that their PICs will monitor the specified events, whereas cpustat itself writes to each CPU's PCR.

By specifying ac instead of ac1, we now monitor these events across all address controllers.

# busstat -w ac,pic0=mem_bank0_stall,pic1=mem_bank1_stall 1 5 time dev    event0               pic0        event1               pic1 1    ac0    mem_bank0_stall      2641        mem_bank1_stall      0 1    ac1    mem_bank0_stall      2766        mem_bank1_stall      0 1    ac2    mem_bank0_stall      0           mem_bank1_stall      0 1    ac3    mem_bank0_stall      0           mem_bank1_stall      0 1    ac4    mem_bank0_stall      0           mem_bank1_stall      0 2    ac0    mem_bank0_stall      2374        mem_bank1_stall      0 2    ac1    mem_bank0_stall      2545        mem_bank1_stall      0 2    ac2    mem_bank0_stall      0           mem_bank1_stall      0 2    ac3    mem_bank0_stall      0           mem_bank1_stall      0 2    ac4    mem_bank0_stall      0           mem_bank1_stall      0 3    ac0    mem_bank0_stall      2133        mem_bank1_stall      0 

We would study the dev column to see which device the line of statistics belongs to.

busstat also provides a -r option, to read PICs without changing the configured events. This means that we monitor whatever was previously set by -w. Here's an example of using -r after the previous -w example.

# busstat -r ac0 1 5 time dev    event0               pic0        event1               pic1 1    ac0    mem_bank0_stall      2039        mem_bank1_stall      0 2    ac0    mem_bank0_stall      1822        mem_bank1_stall      0 3    ac0    mem_bank0_stall      1868        mem_bank1_stall      0 4    ac0    mem_bank0_stall      2109        mem_bank1_stall      0 5    ac0    mem_bank0_stall      1779        mem_bank1_stall      0 

8.4.4. Event Multiplexing

As with using cpustat for a limited number of PICs (see Section 8.2.5), you can specify multiple events for busstat so that more events than PICs can be monitored. The multiple-event specifications are measured alternately.

The following example demonstrates the use of busstat to measure many bus events.

# busstat -w ac0,pic0=mem_bank0_rds,pic1=mem_bank0_wrs -w \ ac0,pic0=addr_pkts,pic1=data_pkts -w ac0,pic0=ac_addr_pkts,pic1=ac_data_pkts 1 9 time dev    event0               pic0        event1               pic1 1    ac0    mem_bank0_rds        47692       mem_bank0_wrs        1785 2    ac0    addr_pkts            87753       data_pkts            112209 3    ac0    ac_addr_pkts         126718      ac_data_pkts         141410 4    ac0    mem_bank0_rds        40187       mem_bank0_wrs        4860 5    ac0    addr_pkts            92343       data_pkts            119899 6    ac0    ac_addr_pkts         55964       ac_data_pkts         69573 7    ac0    mem_bank0_rds        39518       mem_bank0_wrs        3050 8    ac0    addr_pkts            84103       data_pkts            108542 9    ac0    ac_addr_pkts         256737      ac_data_pkts         317145 # 

We specified three pairs of events, with an interval of one second and a count of nine. Each event pair was measured three times, for one second. We would study the event0 and event1 columns to see what the pic values represent.

For additional information on busstat, see busstat(1M).

8.4.5. Example: UltraSPARC T1

UltraSPARC T1 processors also have a number of DRAM performance counters, the most important of which are read and write operations to each of the four memory banks. The tool to display DRAM counters is the busstat command. Be sure to type the command on a single line.

# busstat -w dram0,pic0=mem_reads,pic1=mem_writes -w dram1,pic0=mem_reads,pic1=mem_ writes -w dram2,pic0=mem_reads,pic1=mem_writes -w dram3,pic0=mem_reads,pic1=mem_writes time dev event0 pic0 event1 pic1 1 dram0 mem_reads 16104 mem_writes 8086 1 dram1 mem_reads 15953 mem_writes 8032 1 dram2 mem_reads 15957 mem_writes 8069 1 dram3 mem_reads 15973 mem_writes 8001 

The counts are of 64-byte lines read or written to memory; to get the total bandwidth, add all four counters together. In the preceding example, the system is roughly reading (4 * 16000 * 64) = 4096000 bytes / 3.9 megabytes per second and writing (4 * 8000 * 64 bytes) = 2048000 bytes / 1.95 megabytes per second.