MSMatt SmallingInfrastructure Modernization

Learning Project - Infrastructure Services

Chron0s Phase 2 - Enterprise Time Architecture

The build evolved from a Raspberry Pi GPS/GNSS clock into an enterprise-style time hierarchy for identity, virtualization, firewall, backup, storage, AI infrastructure, and security monitoring systems.

Validation Commands Back to Projects
Status Operational
  • FocusEnterprise time architecture
  • HardwareRaspberry Pi 5 + GPS/GNSS
  • UpstreamChron0s-01 / 192.168.50.245
  • Distributionmein01 / 192.168.50.5
  • StorageNVMe boot
  • StatusChron0s Phase 2 Complete

Project Goal

Build a reliable time layer that supports identity, logging, backups, and security monitoring.

Goal

Chron0s-01 started as a Raspberry Pi 5-based GPS/GNSS time server, but the project goal became larger: build a reliable infrastructure time hierarchy for the homelab.

Why It Matters

Time sync is one of those quiet infrastructure services that usually only gets attention when it breaks. Phase 2 makes it visible, testable, centrally distributed, and easier to trust.

Executive Context

Time synchronization is quiet infrastructure until identity, audit trails, or incident response need it.

Business Problem

Time needed a trusted hierarchy

Inconsistent or legacy NTP references create risk for identity, logging, backups, security monitoring, auditability, and troubleshooting.

Decision Made

Centralize enterprise distribution

Evolve Chron0s from a Raspberry Pi GPS/GNSS clock into a time hierarchy using Meinberg distribution and Active Directory alignment.

Outcome

Core systems integrated

Established Chron0s as the GPS-backed source, Meinberg as the distribution layer, and validated core infrastructure clients.

Risk Reduced

Better timestamp trust

Reduced risk from inconsistent time sources, weak log correlation, unclear NTP dependencies, and fragile timestamp assumptions.

Operating Improvement

Visible and testable time service

Improved infrastructure trust through centralized distribution, validation commands, client integration checks, and planned redundancy and monitoring.

Final Architecture

Chron0s-01 is the GPS-backed source of truth; Meinberg is the enterprise distribution layer.

The goal was not simply to build a Raspberry Pi GPS clock. Chron0s Phase 2 turns that clock into an infrastructure time hierarchy where core systems consume time from Meinberg instead of depending directly on the Raspberry Pi.

Authoritative Time Path
  1. GPS Satellites
  2. Chron0s-01 - 192.168.50.245 - Raspberry Pi 5 + GPS/GNSS
  3. mein01 - 192.168.50.5 - Meinberg NTP Distribution Layer
  4. DC1 - 192.168.50.3 - PDC Emulator
  5. DC2 - 192.168.50.4
  6. Infrastructure clients
GPS Source Chron0s provides accurate GPS-backed time from the Raspberry Pi 5 and GNSS receiver.
Distribution Layer Meinberg centralizes NTP distribution, participates in peer selection, and keeps Internet fallback available.
Active Directory DC1, the PDC Emulator, syncs from Meinberg while Active Directory continues to use its native hierarchy.
Infrastructure OPNsense, prox1, prox2, ark-core, pbs-01, TrueNAS SCALE, and Security Onion consume time through the distribution layer.
UpstreamGPS Satellites -> Chron0s-01 / 192.168.50.245
DistributionChron0s-01 -> mein01 / 192.168.50.5
Identitymein01 -> DC1 PDC Emulator / 192.168.50.3 -> DC2 / 192.168.50.4
Networkmein01 -> OPNsense Firewall
Virtualizationmein01 -> prox1 and prox2 Proxmox cluster nodes
AI Platformmein01 -> ark-core AI Infrastructure Host
Backup and Storagemein01 -> pbs-01 and TrueNAS SCALE
Securitymein01 -> Security Onion, left in observation mode after communication was verified
Architecture Diagram Planned GPS satellites -> Chron0s-01 -> mein01 -> Active Directory, firewall, Proxmox, AI host, backup, storage, and Security Onion

Design Philosophy

GPS accuracy belongs upstream; stable distribution belongs in the enterprise layer.

  • Chron0s provides accurate GPS-backed time.
  • Meinberg provides enterprise time distribution.
  • Active Directory continues to use its native hierarchy.
  • Infrastructure systems consume time from Meinberg instead of directly from the Raspberry Pi.
  • The design preserves GPS accuracy, centralized distribution, Internet fallback, reduced Raspberry Pi dependency, and easier troubleshooting.
Before and after the Phase 2 time architecture work.
Before After
Public NTP sources GPS-backed authoritative source
Inconsistent infrastructure configuration Centralized Meinberg distribution
Legacy and unknown NTP references Consistent infrastructure synchronization
No GPS-backed source Enterprise-style time hierarchy
Limited architecture evidence Documented and validated architecture
Evidence Planned Chron0s chronyc sources and tracking output
Evidence planned - Chron0s chronyc sources and tracking
Evidence Planned Meinberg peer selection with Chron0s reachability at 377
Evidence planned - Meinberg peer selection and reachability 377
Evidence Planned Security Onion chronyd observation mode output
Evidence planned - Security Onion chronyd observation output

Future Enhancements

Keep the time layer boring, redundant, and observable after Phase 2.

  • Chron0s-02 secondary GPS source
  • PPS validation and optimization
  • Prometheus/Grafana monitoring for Chron0s
  • NTP drift dashboards
  • Infrastructure-wide time monitoring
  • Automatic alerting on Chron0s failures

Validation Results

Phase 2 was accepted only after GPS, distribution, client integration, and Security Onion communication were checked.

Chron0s

GPS-backed source stable

GPS lock maintained, 3D FIX confirmed, satellites tracked continuously, chronyd synchronized, NTP service enabled, vcgencmd get_throttled = 0x0, and the platform remained stable for more than 24 hours.

Meinberg

Distribution layer validated

mein01 successfully consumed Chron0s, reachability reached 377, and Chron0s participated in peer selection.

Integrated Systems

Core infrastructure moved to Meinberg

DC1, DC2, OPNsense, prox1, prox2, ark-core AI Host, PBS, and TrueNAS were successfully integrated.

Security Onion

Communication verified, observation continues

Security Onion communicated with Meinberg and chronyd detected it, but initially classified Meinberg as a falseticker due to disagreement with long-established public pool sources. Connectivity and NTP communication were verified, then left in observation mode.

Hardware Used

The first job was getting a stable Pi 5 NVMe platform before worrying about time accuracy.

Raspberry Pi 5

Base platform for the time server.

NVMe boot drive

Boot storage for the Pi 5 build.

Pi 5 NVMe HAT/ribbon

PCIe/NVMe connection stack used during the rebuild.

u-blox M10 GR-U01

USB GPS/GNSS receiver used as the time source.

USB-C power

USB-C power supply with a known-good USB-C cable.

Temporary Wi-Fi

Wi-Fi was used during setup. Wired Ethernet is planned later.

Build Notes and Troubleshooting

The NVMe drive looked suspicious at first, but the evidence kept pointing back to power, cable, or Pi behavior.

01

Initial Symptoms

Initial boot worked, but the first Pi showed EXT4 filesystem issues, input/output errors, and commands disappearing.

02

NVMe Health

The Lexar NM790 SMART report was clean: SMART passed, Critical Warning 0x0, Media and Data Integrity Errors 0, and Error Information Log Entries 0.

03

Ribbon Reseat

Reseating the Pi 5 PCIe/NVMe ribbon helped temporarily, which kept the connector path in the suspect list.

04

Second Pi

Moving the NVMe/HAT stack to a second Raspberry Pi 5 and switching to a known-good USB-C cable resulted in stable operation.

05

Working Theory

Pi #1 had shown throttled=0x50000. Pi #2 showed throttled=0x0. The likely cause was power/cable instability or Pi #1 hardware behavior, not the NVMe drive.

Useful Validation Commands

These are the quick checks that separate a hunch from an actual build log.

Command Set

Platform, GPS, PPS, and chrony checks

vcgencmd get_throttled
vcgencmd measure_temp
mount | grep " / "
dmesg | grep -i nvme
dmesg | grep -iE "error|i/o|ext4"
sudo smartctl -a /dev/nvme0
chronyd -v
gpsd -V
cgps -s
gpspipe -r | head
gpspipe -w -n 20
ls -l /dev/pps*
sudo ppstest /dev/pps0
chronyc sources -v
chronyc tracking

GPS/GNSS Validation

The GPS receiver came up cleanly and proved live satellite data near a window.

Device Path

/dev/ttyUSB0

The GR-U01 appeared as a USB serial device at /dev/ttyUSB0.

USB Bridge

Prolific PL2303

The receiver presented through a Prolific PL2303 USB serial bridge.

Receiver

u-blox M10

gpsd detected the u-blox M10 receiver.

Fix

3D FIX

GPS achieved a 3D fix near a window. cgps showed satellite count, latitude/longitude, altitude, and 3D FIX.

Live Data

NMEA and JSON

gpspipe confirmed live NMEA/JSON output from gpsd.

PPS Status

GPS time works. PPS exists as a device, but the pulse is not validated yet.

Observed

/dev/pps0 existed, and ppstest found the PPS source, but it timed out waiting for pulses. gpsd also reported pps:false.

Current Decision

Current status: GPS time works; PPS device exists but PPS pulse is not yet validated. PPS investigation is deferred to a later phase.

Matt's Notes

Enterprise time distribution turned out to matter more than the GPS hardware by itself.

What surprised me

  • The GPS receiver was easier than the platform stability issues.
  • Most effort went into power, storage, and NTP architecture rather than GPS itself.
  • Enterprise time distribution turned out to be more important than the GPS hardware.

What broke

  • EXT4 filesystem corruption on the original Pi.
  • Input/output errors.
  • Historical undervoltage events.
  • Security Onion initially rejected Meinberg as a falseticker.

What I learned

  • Accurate time is infrastructure.
  • GPS is only one piece of the solution.
  • A distribution layer like Meinberg simplifies everything.
  • Observability and validation are critical.
  • Time synchronization affects security, virtualization, logging, backups, and troubleshooting.

What I would do differently

  • Validate power delivery before building services.
  • Check vcgencmd get_throttled immediately.
  • Build the time hierarchy first instead of treating Chron0s as an isolated project.
  • Document architecture decisions as they are made.

Current Status

Chron0s Phase 2 is complete and operational.

Chron0s-01 is stable as the GPS-backed upstream source, mein01 is distributing time, Active Directory keeps its native hierarchy, and the core infrastructure systems have been validated against the new enterprise-style time architecture.

Future Enhancements

Add redundancy, telemetry, drift visibility, and alerting around the completed Phase 2 architecture.

  • Chron0s-02 secondary GPS source
  • PPS validation and optimization
  • Prometheus/Grafana monitoring for Chron0s
  • NTP drift dashboards
  • Infrastructure-wide time monitoring
  • Automatic alerting on Chron0s failures