1. The logic that had to decide which question to answer first

Murray Leinster’s “A Logic Named Joe” returns as the recalled work because the accidental super-logic does not just answer questions; it ranks them. The desktop’s compute scheduler has the same job. It has more candidate workloads than it can run, more constraints than it can satisfy, and only partial knowledge of what will fail next. The wondering is how it decides what runs now, what waits, and what moves.

This entry wonders about autonomous workload scheduling and migration.

2. The scheduling problem

A general-purpose desktop in LEO has multiple compute cells, each with its own power envelope, thermal headroom, memory, and radiation exposure. Customer workloads compete with platform tasks: attitude control, navigation, thermal management, communications, and housekeeping. The scheduler must decide:

  • which workload runs on which cell;
  • when a workload can start, given power and thermal budgets;
  • when a workload must be paused or throttled;
  • when a workload should move because its current cell is degrading.

The constraint is not just CPU time. A workload that fits in the schedule may still violate the thermal budget if another workload is already heating the same cell. A workload that fits thermally may still fail if the cell’s SSD error rate is climbing.

3. Migration without losing state

Workload migration in orbit is harder than on a data center floor. The destination cell may be across a network link with higher latency or lower bandwidth. The migration must preserve state: open files, in-memory data, partial results. A checkpoint/restart model is safer than live migration because it can be verified before the old instance is stopped.

The autonomy needs a rule for when migration is worth the risk. A cell with rising temperature or increasing memory errors is a candidate for evacuation. A cell scheduled for maintenance is a forced migration. A workload that can run more efficiently elsewhere is an optional migration. The scheduler should not move workloads constantly; each move is a chance to lose state or introduce inconsistency.

4. Coordination with other managers

Compute scheduling cannot be isolated from the rest of the platform:

  • The power manager sets the available envelope.
  • The thermal manager sets how long high-load runs can continue.
  • The communications manager sets when data products must be ready for downlink.
  • The ADCS manager sets which cells are available if pointing requirements affect compute placement.

A workload that is ready to run may still be delayed because the power manager is reserving capacity for an upcoming transmit pass. A workload that is running may be throttled because the thermal manager predicts an eclipse-induced cooling shortage.

5. What this changes

  • Workload scheduling is a multi-constraint optimization, not just a CPU allocation problem.
  • Migration must preserve state and be triggered by degradation, not by minor efficiency gains.
  • The scheduler must coordinate with power, thermal, communications, and ADCS autonomy.
  • The next entry will wonder about storage healing, tiering, and data integrity.