Dolphin Clocks for Dolphin Mar78

This memorandum discusses improving clock handling and runtime accounting in the TOPS20 operating system, particularly for the "Dolphin" hardware.

Current Clock System Issues:

• TOPS20 uses 1-millisecond (ms) and 10-microsecond (us) clocks, with the 1ms clock primarily used for accumulated runtimes and the 10us clock for higher precision.
• Reading the high-precision clock is inefficient, requiring an instruction and subsequent division for conversion.
• Synchronizing the software-maintained 1ms clock with the high-precision hardware clock introduces significant overhead and can lead to inaccuracies.
• Current software routines for calculating incremental runtime (GETHRT) are complex, involve multiple steps, and require temporarily disabling scheduling.

Proposed Hardware Improvements: The document recommends new hardware support to address these issues:

1. Multiple Hardware Clocks: Provide directly readable hardware clocks at desired frequencies (e.g., 1 KHz for 1ms units and 100 KHz for 10us units) to eliminate software conversion overhead and improve accuracy.
2. Process Runtime Clock: Implement a dedicated hardware clock (preferably 100 KHz) that:
   • Is automatically loaded with process runtime on context switches.
   • Can be configured to exclude overhead functions (e.g., page fault handling).
   • This would simplify incremental runtime measurements and provide more accurate accounting.

EBOX/MBOX Accounting (Charging):

• The existing EBOX/MBOX accounting, an attempt at reproducible charging, has proven problematic due to lack of reproducibility, inconsistency across machines, and unsuitability as a runtime substitute.
• The memo explicitly rejects the idea of a highly granular, instruction-level constant charging scheme due to its extreme complexity, lack of universality, and the fundamental belief that system cost is primarily time-based (lease payments, operation time) rather than work-unit based.
• It concludes that EBOX/MBOX meters have limited utility, but the MBOX meter might be useful for user program optimization if its cost is low.

Overall Conclusion: The primary recommendation is to provide efficient and reproducible runtime accounting through dedicated hardware support. Attempts at more general, constant, instruction-level accounting are deemed too difficult and of questionable value, with nothing beyond the EBOX/MBOX meters being warranted.