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 |
| क्रमचय फ़्लो-शॉप | permutation-flow-shop | classical | Taillard |
| अनुक्रम-निर्भर सेटअप फ़्लो-शॉप (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 के साथ एक मूर्तीकृत मैट्रिक्स के रूप में निर्यात
होती है। अनुक्रम-निर्भर सेटअप फ़्लो-शॉप परिवार इसके बजाय एक CostModel सेटअप मैट्रिक्स
संलग्न करता है: एक मशीन पर भिन्न परिवारों के कार्यों के बीच परिवर्तन सेटअप समय लेता है, अतः
सेटअप उद्देश्य समान कार्यों को समूहित करने को पुरस्कृत करता है। नामित मानक संग्रह केवल
उद्धृत और लिंक किए जाते हैं और रिपॉज़िटरी के भीतर कभी पुनर्वितरित नहीं होते।
कई सातत्य परिवार बहु-संसाधन सह-आबंटन का अभ्यास करते हैं: प्रत्येक कार्य एक साथ एक से
अधिक संसाधन माँगता है और निर्माता उन्हें इसकी समूची अवधि के लिए एक-साथ धारण करता है
(डोमेन अनुबंध देखें)। accelerator-coscheduling परिवार प्रति कार्य एक
गणन नोड और एक दुर्लभ त्वरक सह-आबंटित करता है; distributed-transaction परिवार प्रति लेन-देन
डेटा शार्ड का एक परिवर्ती-कोटि लॉक समुच्चय सह-आबंटित करता है; और fpga-partitioning परिवार
प्रति किरायेदार कर्नेल पुनर्संरचनीय फ़ैब्रिक टाइलों का एक स्थानिक रूप से संतत क्रम
सह-आबंटित करता है। जिन कार्यों के संसाधन समुच्चय प्रतिच्छेद करते हैं वे क्रमबद्ध होते हैं
जबकि असंयुक्त कार्य समवर्ती रूप से चलते हैं — चलाने-योग्य
examples/inspect_coallocation.py
उस लीवर को स्पष्ट करता है।
सह-आबंटन से परे, तीन सातत्य परिवार अपने स्वयं के संरचनात्मक लीवर का अभ्यास करते हैं।
elastic-serverless-autoscale परिवार ढाल-योग्य निष्पादन का अभ्यास करता है: प्रत्येक
फलन आह्वान एक से अधिक निष्पादन मोड घोषित करता है — एक संकीर्ण केवल-घरेलू मोड और एक चौड़ा मोड
जो शीघ्र समाप्त होने के लिए एक छोटे साझा बर्स्ट पूल से एक worker उधार लेता है — अतः शेड्यूल
प्रति कार्य एक मोड चुनता है और क्रम तय करता है कि कौन-से आह्वान दुर्लभ चौड़े-और-तेज़ मोड का
दावा करते हैं। distributed-training-gang परिवार गैंग सह-शेड्यूलिंग का अभ्यास करता है:
एक समकालिक डेटा-समानांतर प्रशिक्षण कार्य के workers एक गैंग साझा करते हैं और एक सब-या-कुछ-नहीं
प्रक्षेपण में विशिष्ट त्वरकों पर सह-आरंभ करने चाहिए — workers त्वरक पूल का पुनः-उपयोग करते
हैं और कार्य समय के साथ आते हैं, अतः एक कार्य तब तक आरंभ नहीं हो सकता जब तक पर्याप्त त्वरक
एक-साथ मुक्त न हों, और क्रम तय करता है कि कौन-सा कार्य पहले अपना पूर्ण worker समुच्चय
प्राप्त करता है। 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 | प्रशंसनीय सामग्री जो अभी तक उद्धरण-समर्थित या पूर्णतः अभिलक्षणित नहीं है। |
| अभ्यर्थी साक्ष्य श्रेणी | पायलट, सांख्यिकीय, और अभियान द्वारों की प्रतीक्षा में उद्धरण-समर्थित सामग्री। |
| पूर्ण-अभियान साक्ष्य श्रेणी | वह साक्ष्य जो उद्धरण, अभिलक्षण, सांख्यिकीय, प्रकटीकरण, और गुणवत्ता द्वार पार कर चुका है। |
स्मोक कैटलॉग कभी अंतिम मूल्यांकन साक्ष्य नहीं होते। वे यह सिद्ध करने के लिए मौजूद हैं कि
जनरेटर, सत्यापन, अभिलक्षण, उद्धरण जाँच, और दृढ़ता शीघ्रता से कार्य करते हैं। पोर्टल कैटलॉग
और डाउनलोड प्रत्येक सातत्य परिवार का इस छोटे स्मोक पैमाने (एक तीन-संसाधन पूल) पर पूर्वावलोकन
करते हैं; एक सह-आबंटन परिवार इतने छोटे पूल पर असंयुक्त-संसाधन समानांतरता प्रदर्शित नहीं कर
सकता, अतः विशिष्ट संरचना एक शोध-पैमाना गुण है। build_continuum_full_catalog() प्रत्येक
परिवार को उसके घोषित शोध पैमाने पर मूर्तीकृत करता है -- वह बड़ा संसाधन पूल और कार्य गणना जहाँ
सह-आबंटन, स्पर्धा, और स्थापन संरचना वास्तव में प्रकट होती है -- शोध-श्रेणी बेंचमार्क बंडलों
के लिए।
वर्गीकरण-विधि
वर्गीकरण-विधि शेड्यूलिंग संरचनाओं, परिवेशों, अवसंरचना यथार्थता, उद्देश्य विशेषताओं, बाधा विशेषताओं, अनिश्चितता, और गतिशीलता को आवृत करती है। उदाहरणों में DAG वर्कफ़्लो, स्वतंत्र कार्य बैच, serverless फलन, कंटेनर और VM समेकन, edge और cloud परिवेश, सार्वजनिक ट्रेस, बहु-उद्देश्य अनुकूलन, deadline, डेटा स्थानीयता, churn, और गतिशील आगमन शामिल हैं।
उद्धरण मैट्रिक्स
बेंचमार्क दावे CitationMatrix के विरुद्ध जाँचे जाते हैं। अभ्यर्थी और पूर्ण-अभियान
साक्ष्य-श्रेणी दावे तब तक सत्यापन में विफल होते हैं जब तक वे उद्धरण-समर्थित स्रोतों को
संदर्भित न करें। असमर्थित सामग्री को साक्ष्य जोड़े जाने तक exploratory ही रहना चाहिए।
स्रोत समुच्चय default_citation_matrix() में स्थिर स्रोत पहचानकर्ताओं, हल-योग्य संदर्भों,
और एक दर्ज लाइसेंस मुद्रा के साथ घोषित है। यह तीन स्तरों में फैला है: मानक
संयोजनात्मक-अनुकूलन संग्रह (केवल उद्धृत और लिंक, कभी बंडल नहीं), उत्पादन क्लस्टर ट्रेस, और
समकालीन वास्तविक-संसार Edge–Fog–Cloud-सातत्य डेटासेटों का एक व्यापक समुच्चय — GPU और
machine-learning क्लस्टर ट्रेस, माइक्रोसर्विस और serverless बेंचमार्क सुइट, वैज्ञानिक-वर्कफ़्लो
ट्रेस, सुपरकंप्यूटर कार्य ट्रेस, edge-placement और गतिशीलता डेटासेट, IoT और सेल्युलर-माँग
डेटासेट, ग्रिड कार्बन और ऊर्जा संकेत, धारा-संसाधन कार्यभार, federated-learning
उपकरण-भागीदारी बेंचमार्क, विस्तारित-यथार्थता प्रणाली परीक्षण-पीठ, और निम्न-पृथ्वी-कक्षा
उपग्रह-नेटवर्क ट्रेस:
विहित संदर्भ सुइट
default_reference_suites() की रजिस्ट्री उन विहित प्रकाशित उदाहरण सुइटों को दर्ज करती है
जिनसे प्रत्येक सामान्य शेड्यूलिंग परिवार जुड़ा है: पहचान, परिवार, उदाहरण गणना, पुनःप्राप्ति
सूचक, और वे सर्वोत्तम-ज्ञात-समाधान ट्रैकर जो सुइट के लिए सीमाएँ प्रकाशित करते हैं। शास्त्रीय
सुइट केवल उद्धृत और लिंक किए जाते हैं — 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 | फ़्लो-शॉप | 120 | OR-Library | zenodo-pfsp-bks-2021 |
vrf-pfsp | फ़्लो-शॉप | 480 | SOA समूह साइट | zenodo-pfsp-bks-2021 |
sdst-taillard-ruiz | सेटअप-फ़्लो-शॉप | 480 | SOA समूह साइट | सर्वोत्तम समाधान उदाहरणों के साथ ही आते हैं |
cicirello-wt-sds | मशीन-शेड्यूलिंग | 120 | Harvard Dataverse | cicirello-wtsds-benchmark |
or-library-smtwt | मशीन-शेड्यूलिंग | 375 | OR-Library | crauwels-potts-vanwassenhove-1998 |
vallada-ruiz-upmsp | मशीन-शेड्यूलिंग | 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 पाठ, Taillard फ़्लो-शॉप मैट्रिक्स, .fjs
लचीला job-shop, WfCommons WfFormat JSON) वे load_reference_suite(suite_id, instances_root=...)
द्वारा उन फ़ाइलों से अंतर्ग्रहीत होते हैं जिन्हें ऑपरेटर डाउनलोड करके एक स्थानीय resources/
ट्री के अंतर्गत रखता है। अंतर्ग्रहण पूर्णतः ऑफ़लाइन चलता है, कृत्रिम जनरेटरों जैसा ही सत्यापन,
अभिलक्षण, हैशिंग, और उद्गम लिफ़ाफ़ा पुनः-उपयोग करता है, और प्रत्येक समस्या पर उसका suite_id
और upstream_instance_id अंकित करता है। केवल-रजिस्ट्री सुइट बिना बंडल्ड पार्सर के अपने
उद्धरणों और पुनःप्राप्ति सूचकों के साथ दर्ज होते हैं।
सर्वोत्तम-ज्ञात-समाधान रजिस्ट्रियाँ
प्रति-उदाहरण सर्वोत्तम-ज्ञात मान कभी DispatchAtlas के साथ नहीं आते। ऑपरेटर उन्हें एक निजी
resources/benchmarks/bks/ निर्देशिका के अंतर्गत JSON फ़ाइलों के रूप में अंतर्ग्रहीत करता है,
प्रति सुइट एक फ़ाइल, जिनमें प्रत्येक schema_version, suite_id, ट्रैकर source_id,
पुनःप्राप्ति तिथि, और मान प्रविष्टियाँ (उदाहरण पहचानकर्ता, उद्देश्य, मान,
इष्टतम-या-ऊपरी-सीमा प्रकार, वैकल्पिक निचली सीमा) धारण करती है। load_best_known_registry
प्रत्येक फ़ाइल को संदर्भ सुइटों और उद्धरण मैट्रिक्स के विरुद्ध सत्यापित करता है और अज्ञात
सुइटों, अज्ञात ट्रैकरों, दोहरी प्रविष्टियों, या असंगत सीमाओं पर बंद-होकर विफल होता है।
अंतर्ग्रहीत रजिस्ट्री के बिना सापेक्ष-विचलन मीट्रिक बस अनुपलब्ध रहते हैं — वे कभी आंशिक रूप
से परिकलित नहीं होते, और कोई सर्वोत्तम-ज्ञात मान किसी सार्वजनिक सतह पर प्रकट नहीं होता।
अंशांकन विचलन
कृत्रिम सामान्य परिवार विहित सुइटों से जुड़े हैं, बिना उनकी उत्पादन योजनाओं को पुनरुत्पादित करने का दावा किए। ज्ञात विचलन छिपाए जाने के बजाय दस्तावेज़ित हैं:
| परिवार | प्रकाशित परिपाटी | कृत्रिम परिपाटी |
|---|---|---|
| सेटअप फ़्लो-शॉप | प्रसंस्करण समय के 10/50/100/125% पर SDST-Taillard सेटअप | तीन सेटअप परिवार, लागत = परिवार + 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 संदर्भ आधार देता है।
नामित अंशांकन मीट्रिक एक calibrated-synthetic प्रोफ़ाइल के अभिलक्षण विशेषता वितरणों और उसके
trace-backed संदर्भ उदाहरणों के वितरणों के बीच प्रति-विशेषता 1-Wasserstein (मृदा-वाहक) दूरी
की रिपोर्ट करता है। प्रति-विशेषता दूरियाँ एकल यथार्थता-अंतराल अंक में समेकित होती हैं;
अधिकतम-विचलन सीमा (डिफ़ॉल्ट 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 परिवार,
प्रोफ़ाइल वर्ग, और कठिनाई स्तर द्वारा फ़िल्टर किया गया एक नियतात्मक उपसमुच्चय चुनता है, जो
समस्या पहचानकर्ता द्वारा क्रमित है ताकि चयन पुनरुत्पादनीय हो।
स्मोक कैटलॉग
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])बंडल किया गया स्मोक कैटलॉग दो distributed-computing परिवारों (cloud/edge स्वतंत्र-कार्य और workflow DAG) को चौदह सामान्य शेड्यूलिंग परिवारों (मशीन शेड्यूलिंग, job-shop, लचीला job-shop, क्रमचय फ़्लो-शॉप, अनुक्रम-निर्भर सेटअप फ़्लो-शॉप, RCPSP, ओपन-शॉप, हाइब्रिड फ़्लो-शॉप, वितरित क्रमचय फ़्लो-शॉप, नो-वेट फ़्लो-शॉप, ब्लॉकिंग फ़्लो-शॉप, वितरित असेंबली फ़्लो-शॉप, बहु-उद्देश्य क्रमचय फ़्लो-शॉप, और RCPSP/max) के साथ co-equal समकक्षों के रूप में शामिल करता है। प्रत्येक उदाहरण मूल बीज से नियतात्मक है और उद्धरण-समर्थित जनरेटर मेटाडेटा का उपयोग करता है जबकि स्मोक विकास सामग्री के रूप में लेबल रहता है।
अभ्यर्थी पूर्ण कैटलॉग
अभ्यर्थी पूर्ण-अभियान कैटलॉग बड़ी विन्यस्त समस्या गणनाओं और कठोर साक्ष्य लेबलों के साथ वही मूर्तीकरण पथ उपयोग करते हैं:
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,
)वे पूर्ण-अभियान साक्ष्य-श्रेणी कैटलॉग उद्धरण-समर्थित, अभिलक्षणित, हैश-लिंक हैं, और तब तक अंशांकन साक्ष्य के रूप में लेबल रहते हैं जब तक अभियान, प्रकटीकरण, और प्रकाशन द्वार विशिष्ट दावों को पदोन्नत न कर दें।