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 من تجمّع انفجار مشترك صغير لينتهي أبكر —
بحيث يختار الجدول نمطًا واحدًا لكل مهمة ويقرر الترتيب أي الاستدعاءات تطالب بالنمط
الواسع-والسريع النادر. تمارس عائلة 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 | سيناريو موزّع كامل-إنترنت-كل-شيء. |
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، ومجموعات
معايير microservice و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 | flow-shop | 120 | OR-Library | zenodo-pfsp-bks-2021 |
vrf-pfsp | flow-shop | 480 | موقع مجموعة SOA | zenodo-pfsp-bks-2021 |
sdst-taillard-ruiz | flow-shop بإعداد | 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 القياسي، ومصفوفات flow-shop بصيغة
Taillard، وjob-shop المرن .fjs، وJSON بصيغة WfCommons WfFormat) عبر
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 كل ملف مقابل المتون المرجعية ومصفوفة
الاقتباس ويفشل مُغلقًا عند متون مجهولة أو متتبّعات مجهولة أو مدخلات مكررة أو حدود
غير-متسقة. دون سجل مُستوعَب تكون مقاييس الانحراف-النسبي غير متاحة ببساطة — لا تُحسب
جزئيًا أبدًا، ولا تظهر قيمة أفضل-حل-معروف على أي سطح عام.
تباعُدات المعايرة
تُرسى العائلات العامة الاصطناعية على المتون المعتمدة دون ادّعاء إعادة-إنتاج مخططات توليدها. تُوثَّق التباعُدات المعروفة بدل إخفائها:
| العائلة | الاصطلاح المنشور | الاصطلاح الاصطناعي |
|---|---|---|
| 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 مرجع أثرها صراحةً؛ وتحمل المتون المعتمدة المُستوعَبة جسر
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 مجموعة فرعية حتمية مُرشَّحة حسب العائلة وفئة الملف
وطبقة الصعوبة، مُرتّبةً حسب معرّف المسألة بحيث يكون الاختيار قابلًا للاستنساخ.
كتالوج الدخان
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 مرن، flow-shop تبديلي، flow-shop بإعداد معتمد-على-التسلسل، RCPSP، open-shop، flow-shop هجين، flow-shop تبديلي موزّع، flow-shop بلا-انتظار، flow-shop بالحجب، flow-shop تجميعي موزّع، flow-shop تبديلي متعدد-الأهداف، و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,
)تلك الكتالوجات بدرجة-دليل حملة-كاملة مدعومة-بالاقتباس، ومُميَّزة، ومربوطة-بالتجزئة، وما تزال مُعنوَنة كدليل معايرة حتى تُرقّي بوابات الحملة والإفصاح والنشر دعاوى مُحدَّدة.