Further Reading

If you missed the first two parts of this series, start there — they introduce the concepts of topology strings and binding basics that this article builds on:

Compute Nodes with Heterogeneous Topology in Gridware Cluster Scheduler

Understanding Binding in Gridware Cluster Scheduler

Why order and range matter

Imagine your cluster as a row of houses, each with several rooms. Jobs are like guests arriving to stay overnight.

Without a plan, guests will pick rooms at random. Some might share walls and benefit from proximity; others might end up in different houses entirely.

Binding order and range options give the scheduler a plan — a way to decide how the “houses” and “rooms” are filled:

• -bsort defines which house or room type to consider first.
• -bstart sets where the first guest can enter.
• -bstop defines where the group must stop filling.

It’s a simple idea — but it’s the foundation for consistent, balanced, and sometimes energy-efficient scheduling. This ensures that jobs don’t overlap or scatter unpredictably — they follow a defined parking pattern.

1. Sorting with -bsort

The -bsort option controls the order in which available CPU units are considered. It uses the same letters as topology strings (S, C, E, N, X, Y) but interprets them by utilization:

• Uppercase letters (S, C, N…) mean start with free resources.
• Lowercase letters (s, c, n…) mean start with already-used resources.

This simple mechanism lets administrators describe sophisticated fill-up patterns:

• -bsort "SC" — Fill unutilized sockets and cores first.
• -bsort "sC" — Reuse partially filled sockets before opening a new one.
• -bsort "nSyC" — (GCS only) Use utilized NUMA nodes and 3rd Level Caches before starting opening new ones but empty sockets and cores are preferred within NUMA nodes and core groups.

If no sort order is defined, the scheduler uses the hardware’s natural order as reported by HWLOC. This order is the default behavior in most competitive workload management systems and ensures predictable placement when the WLM lacks a possibility to specify preferences.

2. Defining the range with -bstart and -bstop

After sorting, the scheduler knows which binding units exist and in what order they should be considered. The next question is: how much of that ordered list should be used? That’s what -bstart and -bstop control.

You can think of the sorted topology as a long sequence of nodes — a string that lists sockets, cores, or cache domains in the order defined by -bsort.

With -bstart and -bstop, you mark a window inside that string to show where binding is allowed.

Start here → [================] ← Stop here

The brackets represent the usable part of the topology. Binding can happen only inside this bracketed region; everything outside it is ignored. This is especially useful when you want to reserve or exclude certain parts of a host — for example, to keep the first socket free for system services or to group jobs within a specific NUMA region.

Consider a dual-socket, quad-core host represented as:

SCCccSCCCC

(lowercase c marks partially utilized cores)

• -bstart S -bstop s → the scheduler begins binding at the first unutilized socket (S) and stops before the first partially used socket (s), effectively limiting the job to the clean half of the machine. (SCCcc[SCCCC])
• -bstart s -bstop S → Reversing the range starts binding at the first used socket (s) and continues until the next free socket (S) ([SCCcc]SCCCC)

You can imagine this as managing a parking lot: -bsort arranges the parking spaces by preference, and -bstart/-bstop draw the lines around the section that is currently open for parking. Jobs will always stay within that section, preventing overlap and ensuring predictable placement.

3. Real-world significance

At first glance, -bsort, -bstart, and -bstop may seem like low-level tweaks. In reality, they are the building blocks of enterprise scheduling strategy.

These options influence how load, heat, and power consumption are distributed across hardware, and they provide the basis for higher-level policies such as:

Energy-Aware Scheduling – fill one socket or die before activating another.

Thermal & Power-Density Balancing – distribute workloads evenly across nodes.

License- or Cost-Aware Placement – schedule on specific CPU’s first.

Cache & Memory-Bandwidth Optimization – keep related processes close to shared caches or NUMA regions.

In GCS, JSV (Job Submission Verifier) scripts can dynamically adjust these settings to enforce global policies across the cluster.

4. Looking ahead

This post closes the “mechanics” phase of the binding series. In the next article, we’ll apply everything we’ve learned to real enterprise use cases — combining sorting, filtering, and range selection to implement:

• Energy-optimized cluster configurations
• Thermal-balanced compute fabrics
• Cost- and license-aware job scheduling

What seems like three small options today will soon become the core tools for advanced resource optimization.

OCS and GCS v9.0.8 are now available. As usual, the packages can be downloaded from the HPC-Gridware download page, and the source code is available on the Cluster Scheduler GitHub project page.

The list of fixed issues mentioned in the Release Notes can be found here:

Improvement

CS-739 qstat -j output should contain job state, start time, queue name, and host names

Task

CS-1407 Add SUSE SLES 15 support in support matrix of release notes

CS-1440 Add qtelemetry licenses to GCS 3rdparty licenses directory

CS-1470 do memory testing on V90_BRANCH for the 9.0.8 release

Sub-task

CS-1394 Add start_time of array jobs tasks to qstat -j

CS-1395 Cleanup of job states and show states also in qstat -j output

CS-1396 Show granted host information in qstat -j output

CS-1404 Show granted queues in qstat -j output

CS-1410 Show priority in qstat -j output even if it is the base priority

Bug

CS-671 qrsh truncates the command line and/or output at 927 characters

CS-1019 sge_execd logs errors when running tightly integrated parallel jobs

CS-1270 Installation script clears screen in case of an error which make issues harder to debug

CS-1381 qacct complains “error: ignoring invalid entry in line 436” for accounting records with huge command line entry

CS-1386 man page for sge_share_mon is missing

CS-1403 sge_ckpt man-page is in wrong section (1 instead of 5)

CS-1422 endless loop in protocol between sge_qmaster and sge_execd in certain job failure situations

CS-1424 qmod -sj on own job fails on submit only host

CS-1429 sge_qmaster can segfault on qdel -f

CS-1434 clearing error state of a job leads to event callback error logging in qmaster messages file

CS-1435 rescheduling of jobs requires manager rights, documented is “manager or operator rights”

CS-1436 qmod man pages says it requires manager or operator privileges to rerun a job, but a job owner may rerun his own jobs as well

CS-1451 option -out of examples/jobsbin//work is broken

CS-1476 Go DRMAA does not set JoinFiles() correctly

CS-1477 In Go DRMAA TransferFiles() does not set all values

Please let me or the HPC-Gridware team know if you have any questions.