IClock

module interface

Interface for clock models.

Summary

A clock provides a separate "clock time" axis and scheduling primitives that mirror OMNeT++’s simulation-time scheduling, but are driven by the clock’s own rate, offset, and adjustments. Client modules interact with the clock via the IClock(1,2) C++ interface; events are transparently (re)scheduled on behalf of the client and delivered when the clock’s condition is met.

Key semantics (see IClock(1,2) for exact definitions)

The clock defines a mapping C(t) from simulation time to clock time that is non-decreasing in t. Explicit adjustments (step/offset/origin change) may introduce jumps; rate/drift changes affect the slope.
Conversions handle discontinuities with a lower/upper bound convention (C++ methods take a lowerBound flag to disambiguate).
Absolute scheduling (“at clock time c”): arrival simulation time shifts if the clock is stepped or its origin is changed later; rate/drift changes also affect it.
Relative scheduling (“after clock duration Δc”): arrival simulation time is insensitive to later absolute steps but still affected by rate/drift changes.

Typical use

Instantiate a clock module (implementing this interface) as a submodule.
Pass its module path to users (e.g., NICs, protocol modules) via a parameter.
In C++, derive users from ClockUserModuleBase / ClockUserModuleMixin to call scheduleClockEventAt()/scheduleClockEventAfter(), and the conversion helpers computeClockTimeFromSimTime()/computeSimTimeFromClockTime().

Notes -----

Using a per-interface or per-node clock allows modeling clock skew/drift and observing their impact on protocol timing (e.g., link-layer backoffs, TSN gates).
See also ~IOscillator for the underlying tick-counting abstraction used by some clock models.

<b>See also:</b> ~IOscillator

Inheritance diagram

The following diagram shows inheritance relationships for this type. Unresolved types are missing from the diagram.

Implemented by

Name	Type	Description
IdealClock	compound module	Ideal clock: clock time equals simulation time.
MultiClock	compound module	Multi-clock aggregator and switch.
OscillatorBasedClock	compound module	Oscillator-driven clock.
SettableClock	compound module	This module represents a settable (step-able) clock with adjustable oscillator compensation.

Used in compound modules

Name	Type	Description
EthernetSwitch	compound module	EthernetSwitch models a Layer 2 Ethernet switch with support for various IEEE 802.1 protocols and features. It provides frame forwarding based on MAC addresses and implements multiple switching technologies.
MultiClock	compound module	Multi-clock aggregator and switch.
NetworkInterface	compound module	Serves as the base module for all network interfaces.
NodeBase	compound module	The fundamental infrastructure for all network nodes focusing on non-communication aspects of network nodes.
SettableClock	compound module	This module represents a settable (step-able) clock with adjustable oscillator compensation.

Properties

Name	Value	Description
display	i=block/timer

Source code

//
// Interface for clock models.
//
// Summary
// -------
// A clock provides a separate "clock time" axis and scheduling primitives that
// mirror OMNeT++’s simulation-time scheduling, but are driven by the clock’s
// own rate, offset, and adjustments. Client modules interact with the clock via
// the IClock C++ interface; events are transparently (re)scheduled on behalf of
// the client and delivered when the clock’s condition is met.
//
// Key semantics (see IClock for exact definitions)
// ------------------------------------------------
// - The clock defines a mapping C(t) from simulation time to clock time that is
//   non-decreasing in t. Explicit adjustments (step/offset/origin change) may
//   introduce jumps; rate/drift changes affect the slope.
// - Conversions handle discontinuities with a lower/upper bound convention
//   (C++ methods take a `lowerBound` flag to disambiguate).
// - Absolute scheduling (“at clock time c”): arrival simulation time shifts if
//   the clock is stepped or its origin is changed later; rate/drift changes also
//   affect it.
// - Relative scheduling (“after clock duration Δc”): arrival simulation time is
//   insensitive to later absolute steps but still affected by rate/drift changes.
//
// Typical use
// -----------
// - Instantiate a clock module (implementing this interface) as a submodule.
// - Pass its module path to users (e.g., NICs, protocol modules) via a parameter.
// - In C++, derive users from ClockUserModuleBase / ClockUserModuleMixin to
//   call scheduleClockEventAt()/scheduleClockEventAfter(), and the conversion
//   helpers computeClockTimeFromSimTime()/computeSimTimeFromClockTime().
//
// Notes
// -----
// - Using a per-interface or per-node clock allows modeling clock skew/drift and
//   observing their impact on protocol timing (e.g., link-layer backoffs, TSN gates).
// - See also ~IOscillator for the underlying tick-counting abstraction used by some
//   clock models.
//
// @see ~IOscillator
//
moduleinterface IClock
{
    parameters:
        @display("i=block/timer");
}

File: src/inet/clock/contract/IClock.ned