Changes between Initial Version and Version 1 of User Guide/Portal/Status

Timestamp:

Mar 30, 2026, 5:54:02 PM (6 hours ago)

Author:

editor

Comment:

New: Testbed Status sub-page

User Guide/Portal/Status

@@ +1 @@
+[[Include(WikiToC)]]
+= Testbed Status =
+
+The Testbed Status pages provide real-time visibility into the power state and health of testbed nodes during your active reservations. These pages appear in the portal sidebar '''only when you have a current or upcoming approved reservation''', ensuring that testbed state information is available to users with active access. Global administrators can see all status pages at all times.
+
+----
+
+== Node Status Grid ==
+
+The primary status page displays a visual grid showing every node in your reserved testbed domain. Select a domain from the dropdown at the top — only domains for which you have an active reservation are listed.
+
+=== Grid Layout ===
+
+Nodes are arranged in a grid that reflects their physical position or logical grouping within the domain. For the ORBIT Main Grid, this is a 20×20 physical coordinate layout. For sandboxes and COSMOS domains, nodes are grouped by type:
+
+* '''Nodes''' — general-purpose compute nodes (the main experimental resources)
+* '''Servers''' — server-class machines with additional compute/storage capacity
+* '''RF Devices''' — software-defined radios (USRPs, etc.) and other RF equipment
+* '''Virtual Machines''' — VM-based resources available in some domains
+
+Each cell in the grid represents one node and is color-coded by its current power state:
+
+||= Color =||= State =||= Meaning =||
+|| '''Green''' || POWERON || The node is powered on and responsive. It is either running a baseline image or whatever operating system was last loaded onto it. ||
+|| '''Dark/Black''' || POWEROFF || The node is powered off. It can be powered on using the `omf tell on` command. ||
+|| '''Yellow''' || UNREACHABLE || The node is not responding to management queries. This could indicate a network issue, a failed BMC (baseboard management controller), or a hardware problem. If a node stays unreachable persistently, contact testbed support. ||
+|| '''Red''' || ADMIN DOWN || The node has been taken offline by testbed administrators for maintenance. Admin-down nodes are automatically excluded from `omf` commands and cannot be powered on, imaged, or accessed. ||
+|| '''Gray''' || UNKNOWN || The node's state cannot be determined. This is rare and usually indicates a temporary communication issue. ||
+
+=== Interacting with the Grid ===
+
+Hover over any cell to see a tooltip with the node's full information:
+* Node name and FQDN (fully qualified domain name)
+* Current power state
+* Hardware type (node, server, RF device)
+
+The grid auto-refreshes every '''30 seconds''' to reflect the latest state. You can also manually refresh by reloading the page.
+
+----
+
+== RF Matrix Control (SB4) == #RFMatrix
+
+The RF Matrix page is a specialized status and control interface available '''only during SB4 (Sandbox 4) reservations'''. SB4 is equipped with a JFW 50PMA-012 programmable RF attenuation matrix that lets you control the wireless propagation environment between nodes by adjusting signal attenuation on each link.
+
+=== What is the RF Matrix? ===
+
+In a typical wireless experiment, the signal strength between any two nodes depends on their physical distance, antenna orientation, and the surrounding environment. The RF matrix adds programmable attenuators between node pairs, allowing you to:
+
+* Simulate different distances by increasing attenuation (higher attenuation = weaker signal = as if nodes were farther apart)
+* Create asymmetric links (different attenuation in each direction)
+* Isolate groups of nodes from each other
+* Reproduce specific network topologies for controlled experiments
+
+=== Using the RF Matrix Page ===
+
+The RF Matrix page displays an interactive visualization:
+
+'''Topology graph''' — a network diagram showing the connections between SB4 nodes and their current attenuation values (in dB). Each connection line is labeled with its attenuation level.
+
+'''Adjusting attenuation''' — click on any connection line to open a dialog where you can set the attenuation value from 0 dB (no attenuation — full signal) to 63 dB (maximum attenuation — heavily attenuated signal). Changes take effect immediately.
+
+'''Antenna mode''' — each port can be switched between WiFi antenna mode and SDR antenna mode, depending on the type of experiment you are running.
+
+'''Reset All''' — sets all attenuation values to 0 dB and switches all ports to WiFi mode. Use this to return to a clean starting state.
+
+'''Save/Load configurations''' — you can save your current matrix configuration with a descriptive name for later reuse. Saved configurations can be marked as public (visible to all users) or private (only you can see them). This is useful for reproducing specific topologies across multiple experiment sessions.
+
+The matrix state auto-refreshes every 5 seconds to reflect changes made by all sources (including changes made via the command line using the RF Matrix API).
+
+----
+
+== Understanding Node States During Experiments ==
+
+When running experiments, nodes typically go through these states:
+
+1. '''POWEROFF''' — initial state. Nodes are off and waiting for your commands.
+2. '''POWERON''' — after you run `omf tell on -t <topology>`, nodes power on and boot either the last loaded image or their PXE default.
+3. '''POWERON (imaging)''' — during `omf load`, nodes are powered on, boot into the imaging environment, receive the disk image, and then power off automatically.
+4. '''POWERON (running)''' — after imaging, you power nodes on again with `omf tell on` and they boot the loaded image. At this point you can SSH into them and run your experiment.
+5. '''POWEROFF''' — after your experiment, good practice is to power off nodes with `omf tell off -t all`.
+
+Nodes that show '''UNREACHABLE''' during an experiment may indicate:
+* A node that failed to PXE boot during imaging — try power-cycling it with `omf tell reset -t <node>`
+* A node with a faulty BMC — this is a hardware issue, report it to support
+* A temporary management network glitch — usually resolves within a few minutes