Skip to main content
Every simulation writes record files that you list and download with the results API. This page names the files the platform documents, says what writes each one, and describes the columns of the files that several models share. Files written by a single model, such as the Chakra workload or the Scala UET NIC, are described on that model’s records page; the file types overview links to each one.

How to access output files

After a simulation ends, the platform makes every file the simulator wrote available through three endpoints. In the examples, replace {sim_id} with the simulation’s ID and {file_name} with a file name from the list.

List the files

  • Each entry in files carries a downloadUrl that is valid for 15 minutes. Download the file from it directly.
  • size is the file’s size in bytes, as a string. duration is the run’s elapsed time.
  • type comes from the file’s extension: csv, json, log, pcap, state, or unknown. Use the type query parameter to list one type only.
  • A page holds at most 100 files. When pagination.hasMore is true, pass pagination.nextCursor as the next query parameter to get the next page. A simulation run on several simulator processes writes one file per process for each record, so expect several pages.
  • A file in a subdirectory is listed with its path, for example subdir/file.csv.

Download one file

This endpoint issues a new 15-minute downloadUrl for the file named by fileName, for example when the link from the list has expired. Its response also gives contentType, sizeBytes, expiresAt, and, when one is available, a checksum.

Get computed results

GET /api/v1/simulations/{sim_id}/results/data computes results on the platform from the record files, so you do not have to download and combine every shard yourself. The response does not hold the results: its file.downloadUrl links to a zstd-compressed JSON document that does.
metric names the record to compute from, and mode the kind of result. mode defaults to summary. tier limits the result to one network tier: ssw, fsw, rsw, or nic (see Network tiers). The default, all, covers every tier. The Simulations API reference lists every parameter of the endpoint, including its filters.

File naming convention

Output files follow the pattern:
For example, a simulation with the ID sim_3K9VG9B0TZrUrvmv9lfDopnDAMF produces files like:
  • sim_3K9VG9B0TZrUrvmv9lfDopnDAMF-ecn-pfc-stats-0.csv
  • sim_3K9VG9B0TZrUrvmv9lfDopnDAMF-nd-stats-0.csv
  • sim_3K9VG9B0TZrUrvmv9lfDopnDAMF-nd-stats-1.csv
{simulation} is the same in every file of one simulation. It is usually the simulation’s ID, as in the example above, but some simulations use the name you gave the simulation instead. To find a file, match the record part of its name rather than the prefix. {shard-index} numbers the simulator processes. A simulation runs as one or more simulator processes, and each process writes its own file for each record, covering the nodes that process ran. A simulation that runs as one process writes only shard 0. To cover the whole simulation, combine the files of every shard. A few files differ from the pattern:
  • global-sim-report is a JSON file: {simulation}-global-sim-report-{shard-index}.json.
  • chakra-mapping is written in shard 0 only, and chakra-comm-collective-percentiles-stats is one file for the whole run (Chakra workload records).

File types overview

Files described on this page

Files described on a model page

A simulation also writes diagnostic files for the simulator’s own use.

Detailed file schemas

Network device statistics (nd-stats)

Network Device Statistics files contain per-interface, per-time-step counters for every network device in the simulated topology. Each row captures packet counts, byte volumes, throughput rates, link utilization percentages, and drop counters. The global EnableNetDeviceStatLogging (default true) turns the file on, and metric=nd-stats computes results from it (Get computed results). Filename pattern: {simulation}-nd-stats-{shard-index}.csv

Columns

Network tiers

Example row


Performance metrics (perf)

Performance Metrics files capture application-level latency measurements. Two applications write rows:
  • The Scala Traffic Generator writes a row for each transaction whose reply completes in the recording window (perf).
  • The Scala UDP Echo application’s client writes a row for each echoed packet.
In other simulations the file holds only its header. metric=perf computes results from it (Get computed results). Filename pattern: {simulation}-perf-{shard-index}.csv The name pattern *-perf-*.csv also matches the chakra-perf and rdma-perf files, which are other records.

Columns

Example row


ECN and PFC statistics (ecn-pfc-stats)

ECN and PFC statistics files record Priority Flow Control (PFC) frame counters and Explicit Congestion Notification (ECN) marking counts per interface, per priority level. Use this data to analyze congestion events and flow control behavior. The global EnablePFCECNStatsLogging (default true) turns the file on, and metric=pfc computes results from it (Get computed results). An interface and priority get rows only once one of their counters is non-zero. From then on they get a row every interval. Filename pattern: {simulation}-ecn-pfc-stats-{shard-index}.csv

Columns

Note: The microsecond-duration columns are fractional (Float64); the simulator derives them from nanosecond timers divided by 1000. Server-side PFC summary values (e.g. totalTimePausedUsec) may therefore be non-integer.

Example header


Application report (application-report)

Application Report files describe the socket bindings established at simulation startup. Each row maps a host component and node to its application type, socket role, DSCP/ECT settings, and peer node. The file is written only when the global EnableApplicationReport is true (default false). Filename pattern: {simulation}-application-report-{shard-index}.csv

Columns

Example row


Beacon (beacon)

Beacon files record periodic heartbeat counters tracking client and server activity and data goodput. What the client and server columns count depends on the application: requests and replies for the Scala Traffic Generator (Beacon), work requests for the Scala RDMA application (Beacon). Filename pattern: {simulation}-beacon-{shard-index}.csv

Columns

Example row


RoCE transport statistics (roce-transport-stats)

RoCE Transport Statistics files record detailed RDMA over Converged Ethernet (RoCEv2) transport-layer counters per network device. This includes packet counts by verb type, acknowledgment/NACK tracking, reordering buffer statistics, work queue entries, retransmissions, and round-trip time measurements. The file has a row for each Scala RoCE NIC every NDStatsReportInterval. The global EnableRoceTransportStats (default true) turns it on, and metric=roce-transport-stats computes results from it (Get computed results). Records the transport writes explains what the transport counts. Filename pattern: {simulation}-roce-transport-stats-{shard-index}.csv

Columns

Example header


Tier hop (tier-hop)

Tier Hop files record the cumulative and interval packet counts received on the switch ports of each tier (spine, fabric, rack). Use this to understand traffic distribution across the network hierarchy. The file is written with nd-stats, and each shard counts the switches it runs. Filename pattern: {simulation}-tier-hop-{shard-index}.csv

Columns

Example row


Topology report (topology-report)

Topology Report files describe the static physical topology of the simulated network. Each row represents one link between two devices, including tier placement, device type, link speed, and propagation delay. The file is written once, when the topology is built; each shard writes the links of the nodes it runs. The global EnableTopologyReport (default true) turns it on. Filename pattern: {simulation}-topology-report-{shard-index}.csv

Columns

An empty field means the component or link has no such value. It is never written as 0:
  • Rack switches, NICs and servers have a POD and a rack. Fabric switches have a POD and no rack. Spine switches and scale-up switches have neither.
  • The FAP and FE nodes of a chassis switch have the POD and rack of their chassis.
  • A link between a spine switch and a fabric switch has the plane of the spine. Spine switch s of a data center is in plane s / N, rounded down, where N is the number of spines in each plane. Other network links have no plane.
  • Scale-up links have a plane and a scale-up group (see Scale-Up Groups). Other links have no scale-up group.

Example row

Scale-up groups

A run that has scale-up groups (Section II of the Chakra mapping file) also reports each group in this file. Each link has two rows, one from each end. Both rows of a scale-up link carry its group in scaleup_group and its plane in plane. An untyped group has the one plane 0. The switch, spine and crossbar ends have an empty pod, rack and pod_config_name, and the member end has those of its server. A group that names neither a fabric type nor a number of planes in Section II is an untyped group. The report shows an untyped group as a two-tier switched tree:
  • Each subgroup has one switch component, named scaleup-g<group>-sg<subgroup>. Its component type is ScaleUpSwitch, its tier is 5, and its subtier is 1.
  • A group with more than one subgroup also has one spine component, named scaleup-g<group>-spine. Its component type is ScaleUpSwitch, its tier is 5, and its subtier is 2.
  • The net_device of every end that is a switch or a spine, and the peer_net_device of every member row, is ScaleUpSwitchPort.
A group that names a fabric type and a number of planes in Section II is a typed group. A typed group reports each plane separately.
  • A typed group of fabric type EPS has the same tree for each plane <k>, counted from 0. The switch of a subgroup is named scaleup-g<group>-p<k>-sg<subgroup>, and the spine is named scaleup-g<group>-p<k>-spine. Their component type, tier, subtier and net_device are the same as above.
  • A typed group of fabric type OCS-XBar has one crossbar for each plane <k>, named scaleup-g<group>-p<k>-ocs. Its component type is ScaleUpOpticalSwitch, its tier is 5, and its subtier is 1. The net_device of the crossbar end of a link is ScaleUpOpticalSwitchPort. Each member has one link to the crossbar of each plane. A group of this type has no spine. The peer_net_device of every member row is ScaleUpOpticalSwitchPort. The OCS controller writes no rows.
On the member side, the row has the component name, type, tier, subtier and node ID of the member’s server. Its dev_id is the number of devices on the server’s node, plus the plane for a typed group, so it does not match the dev_id of any other link of that server. Its net_device is the class name of the scale-up port. On the crossbar side, the dev_id of a member is the position of the member in its group, in ascending order of Chakra ID. On the side of a subgroup switch, the dev_id of a member is the position of the member in its subgroup, in ascending order of Chakra ID. The link to the spine has the next number after the last member. On the spine, the dev_id of a subgroup is the position of the subgroup in the group, in ascending order of subgroup ID. The delay of a scale-up row includes the switch latency, so the delays along a path add up to the crossing time of the group. In an untyped group and on an EPS plane, between two members of one subgroup, the delays add up to 1 switch latency and 2 cable latencies. Between members of different subgroups, they add up to 3 switch latencies and 4 cable latencies. On an OCS-XBar plane, between any two members, they add up to 1 switch latency and 2 cable latencies, whatever their subgroups. A scale-up row writes prop_delay_ns with four digits after the decimal point, so a half picosecond is exact. A switch latency of 1 ps with a cable latency of 0 gives 0.0005 ns for a member link. When the run uses more than one core, the file of each shard holds the rows that the shard owns. The shard of a member holds both rows of the link of that member. The shard of the lowest Chakra ID of a group holds the rows of the links between that group’s switches and spine. The files of all shards together describe each link once from each end.

Switch buffer statistics (scala-switch-agg-buff-stats)

Switch Buffer Statistics files capture aggregated buffer occupancy metrics for each switch in the network. Each row reports buffer utilization for a specific buffer type (egress queue, ingress usage, or shared buffer), direction, and pool on a given switch at a given time step. Every Scala Switch writes rows, every BufferStatsReportInterval (a switch attribute, default 1 ms). Filename pattern: {simulation}-scala-switch-agg-buff-stats-{shard-index}.csv

Columns

Example row


Packet trimming statistics (packet-trimming-stats)

Packet Trimming Statistics files count, for each switch, the packets it trimmed and the trimmable and trimmed packets it handled. The file is written only when a switch has both TrimmingEnabled and TrimmingStatsEnabled set to true (both default false). It has a row for each such switch every NDStatsReportInterval. Egress admission describes which packets a switch trims. A packet is counted as received when the switch admits it at ingress, and as sent when the switch admits it to an egress queue. Each count has a cumulative column, prefixed total_, and an interval column, prefixed ivl_. Filename pattern: {simulation}-packet-trimming-stats-{shard-index}.csv

Columns

Example header


Global simulation report (global-sim-report)

The Global Simulation Report is a JSON file with run totals for the devices of one shard: packets, bytes, and drops from the same counters as nd-stats, and PFC frames and pause time from the same counters as ecn-pfc-stats. It is written when nd-stats or ecn-pfc-stats is on. The simulator rewrites it during the run, so the file holds the totals at its last update. Filename pattern: {simulation}-global-sim-report-{shard-index}.json The file has two objects, net-device and pfc. Each holds one global entry, which sums every device of the shard, and one entry for each tier and direction: ssw-ul, ssw-dl, fsw-ul, fsw-dl, rsw-ul, rsw-dl, nic-ul, and nic-dl. The file can hold more entries; this page describes only these.

Diagnostic files

The results list also holds files that you can ignore. Most of them report on the simulator’s own run rather than on the simulated network:
  • scala-remote-trace-log: a trace of the messages between simulator processes. It is written only when the global EnableRemoteTraceLogging is true (default false). Each message adds a row on the sending process and on each receiving process, so on a large run the file can reach hundreds of gigabytes, enough to fill the run’s disk and stop the simulation.
  • cpu-mem-stats: CPU and memory use of the machine running the simulator.
  • scala-switch-buff-stats: per-port switch buffer occupancy.
  • .log files: the simulator’s logs.
  • generic-workload-config.csv: the settings the simulator ran with.
  • Objects under summary/ and parquet/: the platform’s caches for Get computed results.
This page does not describe any other file in the results list.