DispatchAtlasМодель бенчмарков
dispatchatlas.bench определяет доказательство бенчмарков до того, как солверы или
кампании его потребляют. Семейство бенчмарков объявляет свою таксономию, доменный профиль,
класс профиля, допущения, доказательство цитирования, оболочку масштаба, пространство имён
семени, и схему вывода. Материализация валидирует каждую сгенерированную задачу через
dispatchatlas.core, характеризует экземпляр, оборачивает его в конверт происхождения, и
записывает стабильные хеши.
Каталог покрывает обобщённые комбинаторно-оптимизационные семейства планирования и планирование distributed-computing как co-equal равноправные, поэтому платформа не является инструментом только-для-distributed-computing.
Исполняемый пример: examples/benchmark_continuum.py генерирует, характеризует, и каталогизирует континуум-атлас бенчмарков на лету.
Семейства планирования
Каждое семейство планирования материализуется как первоклассный равноправный элемент каталога с хотя бы одним профилем-генератором. Таблица каталога ниже генерируется из реестра генераторов бенчмарков и матрицы цитирования, поэтому её итоги по семействам и цитирования источников исчислимы из самих строк. Диаграмма распределения семейств над таблицей показывает, как профили семейств распределяются по категориям семейств планирования.
Generated from the benchmark generator registry and the citation matrix: 69 family profiles across 8 scheduling families — distributed-computing (47), flow-shop (7), job-shop (6), machine-scheduling (3), open-shop (1), rcpsp (3), rcpsp-max (1), setup-flow-shop (1).
Showing 69 of 69 family profiles.
| Distinctive against | Evidence | Citation status | Source citations | |||
|---|---|---|---|---|---|---|
accelerator-coschedulingaccelerator-coscheduling a heterogeneous datacenter job needs a compute resource and a scarce accelerator at the same time, so every job co-allocates two simultaneous resource demands held together for its whole run; the accelerator pool is scarce, so jobs sharing an accelerator serialize on it while jobs on disjoint resources run in parallel, and the scheduler reasons over a multi-resource co-allocation problem rather than a single-unit-demand one | distributed-computing | ioe-complete | published single-resource continuum schedulers (one unit resource demand per task, not the simultaneous co-allocation of a compute resource and a scarce accelerator held together under a Pareto contract) | smoke | citation-backed |
|
aerial-edgeaerial-edge a loitering UAV is a flying fog node that serves the ground region beneath it for a fixed loiter window before moving to the next pass, so sorties group into successive loiter passes pinned to the fog tier the platform embodies while overhead | distributed-computing | ioe-complete | aerial-edge MEC simulators (no flying-fog loiter placement) | smoke | citation-backed |
|
anytime-inferenceanytime-inference an edge accelerator serves deep-learning inference requests that each complete a mandatory minimal-accuracy early-exit branch and may run an optional refinement to full accuracy when their latency deadline allows; every request declares a mandatory duration below its full duration and a tight latency deadline, and arrivals are spaced shorter than a full inference so requests queue and contend, so the scheduler decides which requests refine and which deliver the early-exit result -- an imprecise-computation quality-versus-timeliness trade-off | distributed-computing | ioe-complete | published edge-cloud split inference and datacenter inference serving (a fixed full-accuracy computation per request), neither of which lets a request drop an optional refinement to meet its deadline so the schedule order trades accuracy for timeliness | smoke | citation-backed |
|
blocking-flow-shopblocking-flow-shop | flow-shop | classical | — | smoke | citation-backed |
|
bulk-synchronous-graphbulk-synchronous-graph an iterative graph computation runs as a sequence of supersteps separated by global barriers, so each superstep's vertex partitions compute and exchange messages and every partition of the next superstep waits on all partitions of the prior one; the slowest partition therefore gates each superstep, and the scheduler reasons over a barrier-synchronized partition-balancing problem rather than an overlap-friendly pipeline or an independent-task one | distributed-computing | ioe-complete | published pipeline or independent-task schedulers (an overlap-friendly wavefront or unsynchronized tasks, not supersteps separated by global barriers where the slowest partition gates each round under a Pareto contract) | smoke | citation-backed |
|
carbon-awarecarbon-aware flexible jobs defer to low-carbon-intensity windows under a time-varying grid carbon signal while honoring their SLA deadlines | distributed-computing | ioe-complete | Electricity-Maps grid carbon-intensity and CityLearn carbon-aware community signals | smoke | citation-backed |
|
cloud-independentcloud-edge-independent | distributed-computing | domain-specific | — | smoke | citation-backed |
|
coflow-schedulingcoflow-scheduling a distributed-computing stage completes only when the last network transfer of its coflow lands, not the first, so a coflow's completion time is the maximum over its member flows; every coflow emits data-heavy flow tasks that place freely across the fabric plus a barrier task that depends on all of them, so the barrier gates the group and the coflow-completion-time is an all-or-nothing footprint | distributed-computing | ioe-complete | datacenter coflow schedulers (no continuum tier-placement barrier) | smoke | citation-backed |
|
compact-job-shopcompact-job-shop | job-shop | classical | — | smoke | citation-backed |
|
confidential-edgeconfidential-edge tasks are classified by data sensitivity -- a confidential task that touches protected data must execute inside the enclave-capable trusted tier so its data never leaves the trusted boundary, while a public task draws a free placement affinity across the fabric | distributed-computing | ioe-complete | edge enclave runtimes (no security-classified Pareto placement) | smoke | citation-backed |
|
cyber-physicalcyber-physical control cycles arrive periodically under a time-varying tariff | distributed-computing | ioe-complete | periodic hard-real-time task models and smart-grid demand-side scheduling formulations (no edge-fog-cloud tier placement under a Pareto contract) | smoke | citation-backed |
|
data-localitydata-locality a query over a large dataset is cheaper to run where the data already resides than to ship the data across the WAN fabric; each task's input lives on one tier (edge sensor logs, fog warm aggregates, or cloud cold archives) and the task pins to that tier so its heavy input never crosses the fabric, with the data tiers cycled so placement spans the whole edge-fog-cloud continuum | distributed-computing | ioe-complete | cluster locality schedulers (no continuum data-residency placement) | smoke | citation-backed |
|
datacenter-colocationdatacenter-colocation latency-sensitive service jobs and deferrable batch jobs share multi-tenant cells, so high-priority-band jobs claim capacity ahead of low-band jobs under contention | distributed-computing | ioe-complete | Google Borg ClusterData2019 priority-tiered cell traces | smoke | citation-backed |
|
digital-twin-syncdigital-twin-sync each physical asset periodically syncs its state to its fog/cloud twin and must finish within a freshness (Age-of-Information) window before the twin's state goes stale | distributed-computing | ioe-complete | digital-twin edge frameworks (no joint Pareto placement) | smoke | citation-backed |
|
disaggregated-memorydisaggregated-memory a CXL-pooled cloud platform backs each socket with a small local DRAM tier and a shared far-memory pool, and every VM draws a long-tailed memory working set, so a few memory-hungry tenants dominate a socket's local budget while far-memory access inflates a VM's runtime in proportion to the working set it spills to the pool; the scheduler reasons over local-versus-pool placement rather than core-count placement | distributed-computing | ioe-complete | published CXL memory-pooling and tiered-memory systems (socket-local page placement, no edge-fog-cloud tier scheduling under a Pareto contract) | smoke | citation-backed |
|
distributed-assembly-flow-shopdistributed-assembly-flow-shop | flow-shop | classical | — | smoke | citation-backed |
|
distributed-flexible-job-shopdistributed-flexible-job-shop | job-shop | structurally-complex | — | smoke | citation-backed |
|
distributed-permutation-flow-shopdistributed-permutation-flow-shop | flow-shop | classical | — | smoke | citation-backed |
|
distributed-training-gangdistributed-training-gang a GPU cluster runs synchronous data-parallel training jobs; each job is a gang of workers that must START TOGETHER on distinct accelerators (every all-reduce step synchronizes the workers), so a job cannot begin until enough accelerators are free simultaneously; the workers reuse the accelerator pool and jobs arrive over time, so jobs queue and the scheduler decides which job acquires a full simultaneously-free worker set first -- an all-or-nothing gang co-start, not an independent placement of each worker | distributed-computing | ioe-complete | published GPU-cluster and inference-serving families that place each task independently; none requires a whole job's worker set to co-start simultaneously on distinct accelerators, so no other family forbids a partial start -- the gang-scheduling all-or-nothing constraint under a Pareto contract | smoke | citation-backed |
|
distributed-transactiondistributed-transaction a partitioned database runs transactions that each acquire exclusive locks on a variable read/write set of data shards, so every transaction co-allocates a randomly drawn subset of shards held together for its whole run; two transactions whose shard sets intersect serialize while disjoint transactions commit in parallel, so the scheduler reasons over a variable-cardinality lock-conflict graph rather than a fixed two-resource hold | distributed-computing | ioe-complete | published replica-placement schedulers (a single shard pinned per task for locality, not a variable-cardinality exclusive lock set co-allocated per transaction forming a conflict graph under a Pareto contract) | smoke | citation-backed |
|
edge-offloadingedge-offloading-mec each task chooses between local edge execution and remote offload | distributed-computing | ioe-complete | iFogSim MEC offloading scenarios | smoke | citation-backed |
|
edge-placementedge-placement services place on edge servers near their user population and migrate as demand shifts across base-station coverage cells | distributed-computing | ioe-complete | EUA edge-user-allocation and Shanghai-Telecom base-station placement traces | smoke | citation-backed |
|
elastic-serverless-autoscaleelastic-serverless-autoscale a serverless platform serves function invocations on a shared worker pool, and every invocation is moldable: it may run on one, two, or four concurrent workers, where a wider allocation runs shorter by a sublinear speedup but spends more total worker-seconds; each request declares its execution modes and arrivals are spaced shorter than a base invocation so the pool is contended, so the scheduler picks each invocation's worker width -- a moldable latency-versus-cost choice rather than a fixed resource hold | distributed-computing | ioe-complete | published serverless cold-start and fixed-width co-allocation families (accelerator co-scheduling, fpga partitioning), each of which holds one fixed resource set per task; none lets a request choose among several worker-count modes so the schedule order trades latency for resource cost under a Pareto contract | smoke | citation-backed |
|
facility-assignmentfacility-assignment | machine-scheduling | classical | — | smoke | citation-backed |
|
failure-recoveryfailure-recovery a failed task re-places its checkpoint state to a surviving tier | distributed-computing | ioe-complete | Borg cluster failure-event traces | smoke | citation-backed |
|
federated-learningfederated-learning each training round selects a subset of heterogeneous, straggler-prone edge clients that train on non-IID local data, then a fog or cloud aggregator combines their updates | distributed-computing | ioe-complete | FedScale and Oort federated-learning device-participation benchmarks | smoke | citation-backed |
|
flexible-job-shopflexible-job-shop | job-shop | classical | — | smoke | citation-backed |
|
flow-shoppermutation-flow-shop | flow-shop | classical | — | smoke | citation-backed |
|
fpga-partitioningfpga-partitioning a multi-tenant reconfigurable FPGA hosts tenant kernels that each occupy a contiguous region of fabric tiles, so every kernel co-allocates a contiguous run of tiles held together for its whole residency; two kernels whose tile intervals overlap cannot be co-resident and serialize while kernels on disjoint tile spans run in parallel, so the scheduler reasons over an interval-overlap conflict graph rather than a fixed two-resource hold or a random-subset lock set | distributed-computing | ioe-complete | published accelerator co-scheduling (a fixed compute-plus-accelerator pair) and shard-lock transactions (a random subset of resources), neither of which constrains the co-allocated set to a spatially contiguous tile interval whose overlaps form an interval conflict graph under a Pareto contract | smoke | citation-backed |
|
frontierco-fjspfrontierco-fjsp | job-shop | classical | — | smoke | citation-backed |
|
generative-inference-servinggenerative-inference-serving a transformer inference replica batches autoregressive requests that each hold key-value-cache memory proportional to their token count for the whole decode, so a long-tailed sequence mix fragments a fixed cache budget and the scheduler reasons over memory-bound admission rather than GPU-count placement; every request's decode duration and KV-cache demand scale with its drawn token count | distributed-computing | ioe-complete | published single-replica generative-model serving systems (no edge-fog-cloud tier placement under a Pareto contract) | smoke | citation-backed |
|
gpu-mlgpu-ml training and inference jobs claim accelerators and gang-schedule replicas | distributed-computing | ioe-complete | Alibaba PAI, Philly, and Helios GPU-cluster traces | smoke | citation-backed |
|
hybrid-flow-shophybrid-flow-shop | flow-shop | classical | — | smoke | citation-backed |
|
immersive-xrimmersive-xr each extended-reality frame runs a latency-critical perception, render, and display pipeline placed across the device, edge, and cloud within a hard motion-to-photon deadline | distributed-computing | ioe-complete | ILLIXR extended-reality systems testbed | smoke | citation-backed |
|
intermittent-edgeintermittent-edge a batteryless sensor harvests ambient energy into a small buffer, runs until the buffer depletes, then sleeps to recharge; a job too large for one duty-cycle window is checkpointed at power loss and resumed in the next, so it is a precedence chain of edge-pinned per-window segments each bounded by the constant energy window | distributed-computing | ioe-complete | intermittent-computing runtimes (no continuum energy-window placement) | smoke | citation-backed |
|
iot-edgeiot-edge many small sensor readings arrive periodically and aggregate at the edge | distributed-computing | ioe-complete | published wireless-sensor-network telemetry datasets and in-network aggregation deployments (raw sensor readings, not edge-fog-cloud tier scheduling under a Pareto contract) | smoke | citation-backed |
|
job-shopjob-shop | job-shop | classical | — | smoke | citation-backed |
|
kv-cache-placementkv-cache-placement a distributed key-value cache tier serves a catalog of cache objects whose request rate follows a heavy Zipfian popularity skew, so a few hot objects absorb most of the traffic; each object is placement-flexible, carrying one single-node mode per cache-tier node, so the scheduler chooses which tier node hosts it, and an object's working set -- the transfer volume staged onto its host tier -- scales with its popularity rank, so the hottest object carries the largest working set and a cold-tail object the smallest; a naive uniform placement strands a hot, large-working-set object on a far tier and pays its transfer across the fabric, while a locality-aware placement pins the hottest objects to near tiers to shrink makespan and cost | distributed-computing | ioe-complete | published cache and content-placement families (consistent-hashing replica placement, CDN content distribution) that place each object uniformly or by a hash; none scales each object's working set with a Zipfian popularity rank so the hot objects carry a strictly larger transfer volume, making popularity-skewed near-tier pinning the lever a locality-aware placement pulls under the Pareto contract | smoke | citation-backed |
|
machine-schedulingmachine-scheduling-unrelated | machine-scheduling | classical | — | smoke | citation-backed |
|
microservice-dagmicroservice-dag services form an acyclic call graph pinned by role to a tier | distributed-computing | ioe-complete | Alibaba v2021 microservice-trace call graphs | smoke | citation-backed |
|
mixed-criticalitymixed-criticality a safety-critical real-time mix runs tasks of differing criticality, and a high-criticality task is budgeted with a conservative high-assurance worst-case execution time and a tight deadline while a low-criticality task carries a smaller best-effort budget and a loose deadline, so the criticality tiering lives in the duration and deadline structure; the scheduler reasons over which assured-criticality tasks to guarantee under contention rather than a uniform-assurance deadline-scheduling one | distributed-computing | ioe-complete | published uniform-assurance real-time deadline schedulers (one worst-case execution time and deadline class per task, not criticality-tiered WCET budgets with tighter high-assurance deadlines under a Pareto contract) | smoke | citation-backed |
|
moe-expert-parallelmoe-expert-parallel a sparsely-activated mixture-of-experts model routes each token batch to one expert and the experts are spread across devices, and expert popularity is long-tailed, so a few hot experts receive most token batches while many stay cold and the all-to-all routing exchange dominates fabric traffic; the scheduler reasons over an expert-placement and load-balancing problem rather than a dense uniform-replica serving one | distributed-computing | ioe-complete | published dense generative-model serving systems (uniform per-replica KV-cache admission, not sparse token-to-expert routing under load imbalance and a Pareto contract) | smoke | citation-backed |
|
multi-objective-pfspmulti-objective-pfsp | flow-shop | classical | — | smoke | citation-backed |
|
multi-project-rcpspmulti-project-rcpsp | rcpsp | structurally-complex | — | smoke | citation-backed |
|
multi-tenant-fair-sharemulti-tenant-fair-share a shared cluster serves several tenants whose workloads compete for one node pool; each task is placement-flexible, carrying one single-node mode per pool node, so the scheduler chooses which node it occupies; tenants are sized asymmetrically, so even a load-balanced placement leaves the heavy tenants holding a larger fraction of their busiest node -- a higher dominant resource share -- than the light ones, and a fairness-aware scheduler rebalances placement to shrink the dominant-share spread | distributed-computing | ioe-complete | published multi-tenant colocation families (Borg-style priority colocation, vm allocation) that fix each task's resource and score makespan or cost; none lets the scheduler choose each tenant task's node and scores the dominant-resource-share spread between tenants as a fairness objective | smoke | citation-backed |
|
network-slicingnetwork-slicing isolated slice classes (latency-critical, broadband, massive-IoT) each carry their own service-level deadline and placement, and same-class slices spread across tiers for resilience | distributed-computing | ioe-complete | 5G slicing orchestration (no joint Pareto placement) | smoke | citation-backed |
|
no-wait-flow-shopno-wait-flow-shop | flow-shop | classical | — | smoke | citation-backed |
|
open-shopopen-shop | open-shop | classical | — | smoke | citation-backed |
|
orbital-edgeorbital-edge tasks schedule across ground terminals, moving low-earth-orbit satellites, and cloud backhaul under time-varying connectivity as satellites enter and leave coverage and hand work over | distributed-computing | ioe-complete | LENS real-measurement LEO satellite-network traces | smoke | citation-backed |
|
pipeline-parallel-trainingpipeline-parallel-training a deep network is split into successive pipeline stages pinned across edge-to-cloud tiers and the training mini-batch is divided into micro-batches, so each micro-batch flows forward stage by stage while each stage runs its micro-batches in issue order; the two precedence families form a diagonal wavefront whose warm-up and cool-down idle slots are the pipeline bubbles, and deeper stages carry rising compute, so the scheduler reasons over a stage-partition and bubble-minimizing problem rather than a synchronous data-parallel all-reduce one | distributed-computing | ioe-complete | published data-parallel / gang-scheduled training systems (synchronous all-reduce over co-located replicas, not a stage-by-micro-batch pipeline wavefront with warm-up and cool-down bubbles under a Pareto contract) | smoke | citation-backed |
|
rcpsprcpsp-renewable | rcpsp | structurally-complex | — | smoke | citation-backed |
|
rcpsp-maxrcpsp-max | rcpsp-max | structurally-complex | — | smoke | citation-backed |
|
rcpsp-multi-modercpsp-multi-mode | rcpsp | structurally-complex | — | smoke | citation-backed |
|
reentrant-fabreentrant-fab | job-shop | structurally-complex | — | smoke | citation-backed |
|
replica-placementreplica-placement a replica runs where its data shard already lives | distributed-computing | ioe-complete | CRUSH replicated-data placement | smoke | citation-backed |
|
serverless-cold-startserverless-cold-start a cold invocation pays a container provisioning penalty | distributed-computing | ioe-complete | Azure Functions serverless-in-the-wild traces | smoke | citation-backed |
|
service-function-chainservice-function-chain an NFV packet flow traverses a linear ordered chain of typed virtual network functions -- firewall, intrusion detection, deep packet inspection, address translation -- each pinned to a tier that hosts its function type, so the chain is a strict total order and the flow crosses the edge-fog-cloud fabric in a fixed sequence; the scheduler reasons over a chain-placement problem under an end-to-end latency budget rather than the branching role-pinned call graph of a microservice | distributed-computing | ioe-complete | published microservice call-graph schedulers (a branching role-pinned acyclic call graph, not a strict linear chain of function-typed network functions under an end-to-end latency budget and a Pareto contract) | smoke | citation-backed |
|
setup-flow-shopsetup-flow-shop | setup-flow-shop | classical | — | smoke | citation-backed |
|
smartnic-offloadsmartnic-offload a SmartNIC-accelerated server pairs a fast host CPU with a low-power on-NIC processor, and every microservice draws a long-tailed compute intensity, so most are light enough to offload onto the energy-frugal NIC cores while a few compute-heavy services must stay host-bound; a service's runtime scales with its intensity, so the scheduler reasons over an energy-versus-latency offload-placement problem rather than a uniform host placement one | distributed-computing | ioe-complete | published mobile-edge computation-offloading models (device-to-edge latency offload, not in-server host-to-NIC energy offload under a Pareto contract) | smoke | citation-backed |
|
split-inference-servingsplit-inference-serving each inference request partitions a deep model at a layer cut -- a light head runs the early layers on the edge near the sensor and a heavy tail runs the later layers in the cloud, consuming the head's intermediate feature map under a per-request end-to-end latency SLO | distributed-computing | ioe-complete | datacenter inference serving (no edge-cloud partition placement) | smoke | citation-backed |
|
spot-preemptiblespot-preemptible a cloud provider rents idle capacity at a discount as revocable spot instances reclaimed after a short lease; eviction-tolerant batch work pins to the cloud spot tier under a hard lease deadline (the eviction horizon), while latency-critical interactive work pins to the stable edge on-demand tier with no eviction deadline | distributed-computing | ioe-complete | cloud spot schedulers (no continuum eviction-deadline placement) | smoke | citation-backed |
|
storage-io-tieringstorage-io-tiering a tiered storage pool serves I/O-bound jobs whose runtime is dominated by moving a job's I/O volume through the storage node it lands on; each job is placement-flexible, carrying one single-node mode per tier node, and the mode duration is tier-dependent -- a seek floor plus the I/O volume divided by that tier's I/O bandwidth, which differs by tier (a fast cloud array sustains far more bytes/second than a slow edge disk); a job's I/O volume follows a heavy-tailed falloff over its I/O-demand rank, so a few I/O-heavy jobs carry most of the bytes and have a large cross-tier duration spread, while the light tail barely varies; a naive placement strands an I/O-heavy job on a low-bandwidth tier and pays its volume slowly, while a bandwidth-aware placement pins the heavy jobs to fast tiers to shrink makespan and cost | distributed-computing | ioe-complete | published storage-tiering and hierarchical-storage-management families that migrate blocks between fast and slow tiers by access frequency; none models the heterogeneous-tier I/O bandwidth as a placement-flexible per-tier mode whose duration is the I/O volume divided by that tier's bandwidth, so an I/O-heavy job's cross-tier duration spread is the bottleneck-relief lever a bandwidth-aware placement pulls under the Pareto contract | smoke | citation-backed |
|
streaming-windowstreaming-window events arrive online in bounded windows and must close within one | distributed-computing | ioe-complete | Parallel Workloads Archive online arrivals | smoke | citation-backed |
|
time-sensitive-networkingtime-sensitive-networking each time-triggered flow releases on a fixed period and must finish within one cycle under a hard, jitter-free deadline | distributed-computing | ioe-complete | EdgeCloudSim best-effort scenarios (no gating) | smoke | citation-backed |
|
unrelated-parallel-setupunrelated-parallel-setup | machine-scheduling | structurally-complex | — | smoke | citation-backed |
|
vehicular-offloadingvehicular-offloading a vehicle's tasks share an arrival time and a roadside-unit dwell deadline, and hand over from the roadside unit to the fog tier as the vehicle drives on | distributed-computing | ioe-complete | EdgeCloudSim / SUMO vehicular-edge mobility scenarios | smoke | citation-backed |
|
video-analyticsvideo-analytics each camera streams frames that must be analyzed within a tight real-time latency bound, placed hierarchically with edge inference near the camera and cloud aggregation | distributed-computing | ioe-complete | edge video-analytics clusters (no joint Pareto placement) | smoke | citation-backed |
|
vm-allocationvm-allocation size-heterogeneous virtual-machine deployments pack onto hosts while each deployment's members spread across distinct failure domains for availability | distributed-computing | ioe-complete | Azure Public Dataset Resource Central VM-allocation traces | smoke | citation-backed |
|
workflow-dagworkflow-dag | distributed-computing | structurally-complex | — | smoke | citation-backed |
|
Per-instance characterization and download eligibility live in the benchmark catalog; this table is the family-and-citation inventory.
Компонент выше несёт полный сгенерированный инвентарь — классические и distributed-computing ядровые семейства ниже плюс континуум семейств Edge–Fog–Cloud. Эти основополагающие ядровые семейства в форме документа:
| Семейство | Профиль | Класс профиля | Первичный корпус |
|---|---|---|---|
| Планирование машин (R||Cmax, несвязанная машина) | machine-scheduling-unrelated | classical | OR-Library |
| Job-shop | job-shop-classical | classical | OR-Library, Taillard |
| Гибкий job-shop (FJSP) | flexible-job-shop | classical | Brandimarte; Hurink-Jurisch-Thole |
| Перестановочный flow-shop | permutation-flow-shop | classical | Taillard |
| Flow-shop с последовательностно-зависимой переналадкой (SDST) | setup-flow-shop | classical | Allahverdi et al. (2008); Allahverdi (2015) |
| Планирование проектов с-ограниченными-ресурсами (RCPSP) | rcpsp-renewable | structurally-complex | PSPLIB |
| Distributed-computing (cloud/edge) | cloud-edge-capacity | domain-specific | CloudSim; DynamicCloudSim; Edge vision |
| Distributed-computing (workflow DAG) | workflow-dag | structurally-complex | Standard Task Graph Set |
Семейства несвязанной-машины и гибкого job-shop прикрепляют матрицу времени-исполнения
CostModel к каждому экземпляру, экспортируемую как материализованную матрицу рядом с JSON
задачи. Семейство flow-shop с последовательностно-зависимой переналадкой вместо этого
прикрепляет матрицу переналадки CostModel: переключение между работами разных семейств на
машине стоит времени переналадки, поэтому цель переналадки вознаграждает группировку
схожих работ. Названные стандартные корпуса только цитируются и связываются и никогда не
перераспределяются внутри репозитория.
Несколько континуум-семейств упражняют мульти-ресурсное со-выделение: каждая задача
требует более одного ресурса одновременно, и конструктор удерживает их вместе на всю её
длительность (см. Доменные контракты). Семейство
accelerator-coscheduling со-выделяет вычислительный узел и дефицитный ускоритель на
работу; семейство distributed-transaction со-выделяет набор блокировок
переменной-кардинальности шардов данных на транзакцию; а семейство fpga-partitioning
со-выделяет пространственно непрерывную последовательность плиток реконфигурируемой ткани
на ядро-арендатора. Задачи, чьи наборы ресурсов пересекаются, сериализуются, тогда как
непересекающиеся задачи выполняются параллельно — исполняемый
examples/inspect_coallocation.py
делает рычаг явным.
Помимо со-выделения, три континуум-семейства упражняют свои собственные структурные рычаги.
Семейство elastic-serverless-autoscale упражняет формуемое исполнение: каждый вызов
функции объявляет более одного режима исполнения — узкий только-домашний режим и широкий
режим, который заимствует worker из небольшого общего burst-пула, чтобы завершиться раньше —
поэтому расписание выбирает один режим на задачу, а порядок решает, какие вызовы
притязают на дефицитный широкий-и-быстрый режим. Семейство distributed-training-gang
упражняет банд-со-планирование: workers синхронного данно-параллельного тренировочного
задания делят банду и должны со-стартовать на различных ускорителях в запуске всё-или-ничего
— workers переиспользуют пул ускорителей, а задания прибывают со временем, поэтому задание не
может начаться, пока достаточно ускорителей не освободятся одновременно, а порядок решает,
какое задание первым получает свой полный набор workers. Семейство
multi-tenant-fair-share упражняет справедливость доминантного-ресурса: несколько
асимметрично-размерных арендаторов размещают гибкие-по-размещению задачи на общем пуле
узлов, а цель доли-доминантного-ресурса оценивает разброс между доминантной долей
наиболее- и наименее-обслуженного арендатора — поэтому размещение, то, какие ресурсы
занимает каждый арендатор, и есть рычаг, который его балансирует или искажает. Исполняемые
examples/serverless_autoscale_study.py,
examples/distributed_training_gang_study.py,
и
examples/multi_tenant_fairshare_study.py
делают эти три рычага явными.
Классы профиля
| Класс профиля | Значение |
|---|---|
classical | Происходит из стандартного комбинаторно-оптимизационного корпуса. |
structurally-complex | Несёт структуру предшествования, DAG, или сети-ресурсов. |
ioe-complete | Internet-of-Everything-полный распределённый сценарий. |
trace-backed | Основан на названной трассе реальной-мировой нагрузки. |
domain-specific | Подогнан под единственный операционный домен. |
Метки доказательства
| Метка | Использование |
|---|---|
smoke | Малые детерминированные экземпляры для тестов, примеров, документации, и предпросмотров. |
exploratory | Правдоподобный материал, ещё не подкреплённый-цитированием и не полностью охарактеризованный. |
| кандидатская степень доказательства | Подкреплённый-цитированием материал в ожидании пилотных, статистических, и кампанийных воротов. |
| степень доказательства полной-кампании | Доказательство, прошедшее вороты цитирования, характеризации, статистические, раскрытия, и качества. |
Smoke-каталоги никогда не являются финальным оценочным доказательством. Они существуют, чтобы
доказать, что генераторы, валидация, характеризация, проверки цитирования, и персистентность
работают быстро. Каталог портала и загрузки предпросматривают каждое континуум-семейство в
этом малом smoke-масштабе (пул трёх-ресурсов); семейство со-выделения не может проявить
непересекающе-ресурсный параллелизм на столь малом пуле, поэтому отличительная структура
является свойством исследовательского-масштаба. build_continuum_full_catalog()
материализует каждое семейство в его объявленном исследовательском масштабе — больший пул
ресурсов и число задач, где структура со-выделения, состязания, и размещения подлинно
проявляется — для бенчмарк-наборов исследовательского-уровня.
Таксономия
Таксономия покрывает структуры планирования, среды, инфраструктурную реалистичность, признаки цели, признаки ограничений, неопределённость, и динамизм. Примеры включают DAG-workflows, пакеты независимых задач, serverless-функции, консолидацию контейнеров и VM, edge- и cloud-среды, публичные трассы, много-целевую оптимизацию, deadline, локальность данных, churn, и динамические прибытия.
Матрица цитирования
Утверждения бенчмарков проверяются против CitationMatrix. Утверждения кандидатской и
полной-кампании степени доказательства проваливают валидацию, если не ссылаются на
подкреплённые-цитированием источники. Неподдержанный материал должен оставаться exploratory,
пока доказательство не добавлено.
Набор источников объявлен в default_citation_matrix() со стабильными идентификаторами
источников, разрешимыми ссылками, и записанной лицензионной позицией. Он охватывает три
яруса: стандартные комбинаторно-оптимизационные корпуса (только цитируются и связываются,
никогда не упаковываются), трассы продакшн-кластеров, и широкий набор современных
реальных-мировых датасетов континуума Edge–Fog–Cloud — трассы GPU- и machine-learning-
кластеров, наборы бенчмарков микросервисов и serverless, трассы научных-workflow, трассы
заданий суперкомпьютеров, датасеты edge-placement и мобильности, датасеты IoT и
сотового-спроса, сигналы углерода и энергии сети, нагрузки потоковой-обработки, бенчмарки
участия-устройств federated-learning, тестбеды систем расширенной-реальности, и трассы
спутниковых-сетей низкой-земной-орбиты:
Канонические эталонные наборы
Реестр в default_reference_suites() записывает канонические опубликованные наборы
экземпляров, к которым привязывается каждое generic-семейство планирования: идентичность,
семейство, число экземпляров, указатель получения, и трекеры лучших-известных-решений,
публикующие границы для набора. Классические наборы только цитируются и связываются —
DispatchAtlas никогда не упаковывает и не перераспространяет сторонние файлы экземпляров.
| Набор | Семейство | Экземпляры | Загрузка | BKS-трекер |
|---|---|---|---|---|
fisher-thompson | job-shop | 3 | OR-Library | van-hoorn-2018, scheduleopt-benchmarks |
lawrence | job-shop | 40 | Зеркало JSPLIB | van-hoorn-2018, scheduleopt-benchmarks |
adams-balas-zawack | job-shop | 5 | Зеркало JSPLIB | van-hoorn-2018, scheduleopt-benchmarks |
applegate-cook-orb | job-shop | 10 | Зеркало JSPLIB | van-hoorn-2018, scheduleopt-benchmarks |
storer-wu-vaccari | job-shop | 20 | Зеркало JSPLIB | van-hoorn-2018, scheduleopt-benchmarks |
yamada-nakano | job-shop | 4 | Зеркало JSPLIB | van-hoorn-2018, scheduleopt-benchmarks |
taillard-jsp | job-shop | 80 | Зеркало JSPLIB | van-hoorn-2018, scheduleopt-benchmarks |
demirkol-dmu | job-shop | 80 | Зеркало JSPLIB | scheduleopt-benchmarks |
brandimarte-mk | job-shop (гибкий) | 15 | Зеркало SchedulingLab | scheduleopt-benchmarks |
hurink-fjsp | job-shop (гибкий) | 198 | Зеркало SchedulingLab | scheduleopt-benchmarks |
dauzere-peres-paulli | job-shop (гибкий) | 18 | Зеркало SchedulingLab | scheduleopt-benchmarks |
taillard-pfsp | flow-shop | 120 | OR-Library | zenodo-pfsp-bks-2021 |
vrf-pfsp | flow-shop | 480 | Сайт группы SOA | zenodo-pfsp-bks-2021 |
sdst-taillard-ruiz | setup-flow-shop | 480 | Сайт группы SOA | лучшие решения поставляются с экземплярами |
cicirello-wt-sds | machine-scheduling | 120 | Harvard Dataverse | cicirello-wtsds-benchmark |
or-library-smtwt | machine-scheduling | 375 | OR-Library | crauwels-potts-vanwassenhove-1998 |
vallada-ruiz-upmsp | machine-scheduling | 1640 (заявлено) | Сайт группы SOA | — |
psplib | rcpsp | 2040 | Сайт PSPLIB | psplib-1997 |
mmlib | rcpsp | 4320 (заявлено) | Страница OR&S | solutionsupdate-ugent-rcpsp |
rg300 | rcpsp | 480 | Страница OR&S | solutionsupdate-ugent-rcpsp |
Наборы с упакованным парсером (стандартный job-shop-текст, flow-shop-матрицы Taillard,
гибкий job-shop .fjs, WfCommons WfFormat JSON) загружаются через
load_reference_suite(suite_id, instances_root=...) из файлов, которые оператор скачивает
и размещает под локальным деревом resources/. Загрузка выполняется полностью офлайн,
переиспользует тот же конверт валидации, характеризации, хеширования, и происхождения, что
и синтетические генераторы, и штампует каждую задачу её suite_id и
upstream_instance_id. Наборы только-реестра записываются с их цитированиями и
указателями получения без упакованного парсера.
Реестры лучших-известных-решений
По-экземплярные лучшие-известные значения никогда не поставляются с DispatchAtlas.
Оператор загружает их как JSON-файлы под приватной директорией
resources/benchmarks/bks/, один файл на набор, каждый несёт schema_version,
suite_id, source_id трекера, дату получения, и записи значений (идентификатор
экземпляра, цель, значение, вид оптимум-или-верхняя-граница, опциональная нижняя граница).
load_best_known_registry валидирует каждый файл против эталонных наборов и матрицы
цитирования и проваливается закрыто на неизвестных наборах, неизвестных трекерах,
дублирующихся записях, или несогласованных границах. Без загруженного реестра метрики
относительного-отклонения просто недоступны — они никогда не вычисляются частично, и
никакое лучшее-известное значение не появляется ни на какой публичной поверхности.
Расхождения калибровки
Синтетические generic-семейства привязаны к каноническим наборам без претензии воспроизводить их схемы генерации. Известные расхождения документируются, а не скрываются:
| Семейство | Опубликованная конвенция | Синтетическая конвенция |
|---|---|---|
| setup flow-shop | переналадки SDST-Taillard на 10/50/100/125% времени обработки | три семейства переналадки, стоимость = семейство + 1 |
| планирование машин (R||Cmax) | классы длительностей U[1,100] и коррелированные-машинные варианты | по-парные факторы скорости 0.5–2.0 |
Сравнения против опубликованных конвенций проходят через загруженные канонические экземпляры, а не через синтетические семейства.
Характеризация
Каждая материализованная задача получает нормализованные дескрипторы для:
- плотности возможностей
- разреженности совместимости
- состязания и перегрузки
- глубины зависимости
- коммуникационного давления
- интенсивности переналадки
- перекоса нагрузки и гетерогенности
- конфликта целей
- неопределённости и динамизма
- чувствительности солвера
Мост расстояния между распределениями
Каждый профиль степени доказательства полной-кампании объявляет мост расстояния между распределениями: его
статус (synthetic, calibrated-synthetic, trace-backed, или externally-sourced),
доказательство калибровки, доменный сценарий, покрытие переноса и возмущения, и остаточный
риск калибровки. Продвижение к степени доказательства полной-кампании проваливается
закрыто, если покрытия переноса и возмущения не объявлены, а профиль calibrated-synthetic
должен назвать trace-backed-эталон, против которого он калибруется. Семейства
calibrated-synthetic называют свой trace-эталон явно; загруженные канонические наборы несут
мост externally-sourced, а адаптер WfCommons — первый внешне-парсимый trace-backed-источник
экземпляров, дающий distribution_distance_score реальную trace-backed-эталонную опору.
Названная метрика калибровки сообщает по-признаку расстояние 1-Wasserstein
(землепереносчик) между распределениями характеризационных признаков профиля
calibrated-synthetic и таковыми его trace-backed-эталонных экземпляров. По-признаку
расстояния агрегируются в единый балл расстояния между распределениями; балл выше порога
максимального-расхождения (по умолчанию 0.25) означает, что профиль дрейфовал слишком
далеко от своего эталона и проваливает калибровку. Метрика воспроизводима из
материализованных экземпляров и названной эталонной трассы.
from dispatchatlas.bench import (
build_smoke_catalog,
metrics_from_instance_set,
distribution_distance_score,
)
catalogs = {c.config.profile_id: c for c in build_smoke_catalog()}
synthetic = metrics_from_instance_set(catalogs["cloud-edge-capacity"])
reference = metrics_from_instance_set(catalogs["workflow-dag"])
score = distribution_distance_score(
synthetic, reference, reference_trace_id="google-cluster-data"
)Стратификация и выбор подмножества
difficulty_score агрегирует дескрипторы состязания, перегрузки, глубины-зависимости, и
чувствительности-солвера в нормализованный балл сложности, а stratify_instances распределяет
материализованные экземпляры в страты низкой, средней, и высокой сложности.
select_benchmark_subset выбирает детерминированное подмножество, отфильтрованное по
семейству, классу профиля, и страте сложности, упорядоченное по идентификатору задачи, так
что выбор воспроизводим.
Smoke-каталог
from dispatchatlas.bench import build_smoke_catalog, smoke_benchmark_provider
catalogs = build_smoke_catalog(root_seed=20260527)
provider = smoke_benchmark_provider(root_seed=20260527)
first_problem = provider.get_problem(provider.list_problem_ids()[0])Упакованный smoke-каталог включает два distributed-computing-семейства (cloud/edge независимая-задача и workflow DAG) наряду с четырнадцатью обобщёнными семействами планирования (планирование машин, job-shop, гибкий job-shop, перестановочный flow-shop, flow-shop с последовательностно-зависимой переналадкой, RCPSP, open-shop, гибридный flow-shop, распределённый перестановочный flow-shop, flow-shop без ожидания, блокирующий flow-shop, распределённый сборочный flow-shop, многокритериальный перестановочный flow-shop, и RCPSP/max) как co-equal равноправные. Каждый экземпляр детерминирован от корневого семени и использует подкреплённые-цитированием метаданные генератора, оставаясь помеченным как smoke-материал разработки.
Кандидатские полные каталоги
Кандидатские полные-кампанийные каталоги используют тот же путь материализации с большими сконфигурированными числами задач и более строгими метками доказательства:
from dispatchatlas.bench import build_full_catalog, full_benchmark_provider
catalogs = build_full_catalog(root_seed=2026052713, problem_count_per_profile=30)
provider = full_benchmark_provider(
root_seed=2026052713,
problem_count_per_profile=30,
)Те каталоги степени доказательства полной-кампании подкреплены-цитированием, охарактеризованы, связаны-хешем, и всё ещё помечены как доказательство калибровки, пока вороты кампании, раскрытия, и публикации не продвинут конкретные утверждения.