MIB#

Introduction#

The Pixie SDK uses a management information base (MIB) to manage and report on the system. The MIB provides a standardization framework already in use by other XIA products. Within the SDK, we use it to store system information, and in a few cases control runtime system behavior. MIBs bring a number of benefits such as dynamic configuration and pro-active error handling.

MIB Structure#

A MIB is a set of key/value pairs. The key is a path delimited by the . character. There are multiple MIBs within the system. We have attempted to group them so that similar types are together. The fundamental grouping is the module. For example, MIB variables for a module in slot 10 are under module.10.

Note

The SDK uses the module’s physical slot to address and index modules. This differs from the C API, which uses a logical mapping from Pixie16InitSystem().

MIB Variables#

MIB variables have one of the following types:

  • String,

  • Boolean,

  • Unsigned integer,

  • Real (i.e. double), and

  • Timestamp.

MIB variables can be:

  • Read and writable,

  • Read only, and

  • Write Once; Read only.

Note

An error is returned if set is used on a read only MIB variable.

The MIB variables present vary depending on the hardware in the crate and the state of the system. If there’s no module in Slot 10, then the slot 10 MIB will not be present. Also, Revision F modules will not have any daughter board (db) MIB nodes. Most MIB variable paths provide enough information to explain what there roles are. Some examples include

  • module.10.db04.0.channels

    The number of channels on the daughter board in slot 10.

  • module.10.pci.slot

    Slot 10’s PCI slot.

  • module.2.pci.mbox.opens

    The number of times that slot 2 has had a PCI connection made since the system powered on.

Some variables can be set to change a setting or trigger something to happen. A variable of any type can be set using a string. The string will be automatically converted to the variable type and errors raised if the conversion is not successful.

Note

At this time we do not provide write access to the MIB, but we do allow full read access. As we start to bring more of the system into the MIB we’ll expand the permission sets.

MIB Queries#

MIB queries provide access to MIB variables. They can also be used to generate system reports. MIB queries are regular expressions using the ECMA-262 grammar. Here are a few examples.

  1. module.10.* reports all MIB variables for the module in slot 10.

  2. module.\d+.serial-num reports on all the module serial numbers in the system.

  3. module.\d+.num-channels can be used to calculate the system channel count.

Query reports return the variables and their values as strings. We also provide typed API calls as a convenience. In the channel count example, you could loop over the slots and sum the results instead of parsing the strings.

Query reports come in two data formats: text and JSON. The text format contains a single key/value pair per line using an = to delimit the key from value. Example 3 above would produce the following text formatted output.

module.2.num-channels = 16
module.7.num-channels = 16
module.8.num-channels = 16
module.9.num-channels = 16
module.10.num-channels = 32
module.13.num-channels = 16

The second format, JSON, would look like this

{
    "module": {
        "10": {
            "num-channels": "32"
        },
        "13": {
            "num-channels": "16"
        },
        "2": {
            "num-channels": "16"
        },
        "7": {
            "num-channels": "16"
        },
        "8": {
            "num-channels": "16"
        },
        "9": {
            "num-channels": "16"
        }
    }
}

System Control#

The C API exposes a number of SysControl functions that allow users to interact with the MIB (ex. PixieSysControlOpen()). These functions provide users with a way to read and write information to and from the MIB.

Note

Again, please be aware that the MIBs do not contain user writable entries at this time.

System Control can be used for:

  • Configuration reporting

    Report against aspects of the system, ex. channel counts or PLX versions.

  • Performance monitoring

    Some MIB variables are the current backplane bandwidth being used by a module

  • Self-test reports

    Report self test results for module that have tests

  • (future) Runtime configuration changes

    Change settings not explicitly covered by the SDK module/channel parameter interface

Let’s say you wanted monitor the amount of list-mode data transferred from the modules during a list-mode data run and get that information in JSON format. The implementation may look something like this.

int retval = PixieSysControlOpen("module.\d+.run.dma_in", PIXIE_SYSCTL_FORMAT_JSON);
if(retval < 0) {
    // do error handling here and don't continue.
}

size_t len = 0;
retval = PixieSysControlSize(&len);
if(retval < 0) {
    // do error handling here and don't continue.
}

char* buffer = malloc(len);
retval = PixieSysControlRead(buffer, &len);
if(retval < 0) {
    // do error handling here and don't continue.
}

// send JSON to a reporting interface

free(buffer);

You can then wrap this up in a loop that executes every second, and now you’ve got real-ish time monitoring of the data transferred from the module. We provide the above example in C since that can be easily translated into python or C++.