# wall clock time Published articles for wall clock time. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## A Backward NTP Clock Step Delayed a Python Scheduler's Measurements by Nine Days DevFeed: [A Backward NTP Clock Step Delayed a Python Scheduler's Measurements by Nine Days]() Original publisher: [Read original article]() Author: Philipp Lehmann (philipp.lehmann@gruppe.ai) Published: 2026-09-14T07:00:00Z Content type: tutorial Language: en Sources: [Philipp Lehmann]() Topics: [Python](), [Linux](), [systemd](), [Single Board Computer]() Tags: [embedded](), [linux](), [ntp](), [python](), [reliability](), [scheduler](), [single-board-computer](), [systemd](), [time](), [wall-clock-time]() ### AI overview A Python scheduler on an embedded Linux device silently stopped running after NTP corrected the system clock backward by about nine days. Because it used wall-clock time to measure elapsed time, the scheduler waited roughly nine days before running again. The article explains why a monotonic clock is the appropriate fix and mentions testing with an injected clock jump. ### Source excerpt time.time() vs time.monotonic() in a Python scheduler: a backwards NTP step delayed runs by nine days. Monotonic durations and a jump-injecting test. ## How Prisma Compute Keeps Time Accurate in Long-Running Applications DevFeed: [How Prisma Compute Keeps Time Accurate in Long-Running Applications]() Original publisher: [Read original article]() Author: Alexey Orlenko Published: 2026-06-26T00:00:00Z Content type: article Language: en Sources: [Prisma]() Topics: [Prisma](), [Firecracker](), [virtual machines](), [cloud-infrastructure](), [Linux Kernel]() Tags: [compute](), [firecracker](), [linux-kernel](), [long-running](), [prisma](), [ptp](), [time-synchronization](), [wall-clock-time]() ### AI overview This article explains how Prisma Compute maintains wall-clock accuracy in long-running applications running in Firecracker microVMs. It discusses clock handling during snapshot restore, partial support for restore detection, and measured drift in VMs that remain awake. ### Source excerpt How Prisma Compute keeps wall-clock time accurate in long-running Firecracker microVMs, using the host-paired KVM PTP clock instead of an in-guest NTP daemon. ## Branch Prediction: Why an if Inside a Hot Loop Costs Milliseconds DevFeed: [Branch Prediction: Why an if Inside a Hot Loop Costs Milliseconds]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-03-21T00:00:00Z Content type: tutorial Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [cpu](), [Hardware]() Tags: [branch](), [branch-prediction](), [cpu](), [cycles](), [loops](), [optimization](), [performance](), [pipeline](), [pipelining](), [sorting](), [systems](), [wall-clock-time]() ### AI overview This tutorial explains how CPU pipelining and branch prediction affect performance in hot loops. It describes the cost of mispredictions and suggests sorting data to create predictable branch patterns or using branchless techniques and loop unrolling, while recommending measurement on the target workload. ### Source excerpt CPUs pipeline instructions and speculate on branch outcomes. A misprediction discards the speculative work and flushes the pipeline at roughly 10 to 20 cycles. In a million-iteration loop with random branch outcomes, those flushes dominate runtime. Sorting the data so the branch resolves the same way for long runs, or removing the branch entirely with a mask or 0/1 multiplier, is what recovers the time. ## Tracking Wall Clock, On-CPU, and Off-CPU Time for Android Performance DevFeed: [Tracking Wall Clock, On-CPU, and Off-CPU Time for Android Performance]() Original publisher: [Read original article]() Author: Amanjeet Singh Gurtatta Published: 2021-07-18T21:35:43Z Content type: tutorial Language: en Sources: [Amanjeet Singh]() Topics: [Android](), [Process](), [cpu]() Tags: [android](), [cpu](), [cpu-time](), [mobile-performance](), [off-cpu-time](), [performance](), [regression](), [wall-clock-time]() ### AI overview This Android performance tutorial explains wall-clock, on-CPU, and off-CPU time, including how to measure them at the process or thread level and how to choose an appropriate monotonic clock API. ### Source excerpt The post talks about the different types of time to look for: wall clock time, on CPU time and off CPU time ## Is the Mean Really Useless? DevFeed: [Is the Mean Really Useless?]() Original publisher: [Read original article]() Author: Marc Brooker Published: 2017-12-28T00:00:00Z Content type: article Language: en Sources: [Marc Brooker's]() Topics: [Electrical engineering and computer science (EECS)]() Tags: [1-7](), [2](), [allows](), [aws-lambda](), [capacity](), [capacity-planning](), [computer](), [cpu](), [cron](), [graphs](), [jitter](), [monitoring](), [outliers](), [sampling](), [statistics](), [systems](), [wall-clock-time]() ### AI overview The mean can conceal outliers and time-dependent behavior, so it cannot by itself describe system performance. The text illustrates how wall-clock-aligned sampling can report either 100% or 0% CPU for a once-per-minute job; per-minute summaries (mean 1.7%, median 0%, 99th percentile 100%) still obscure the pattern. Yet means support capacity reasoning: in a serial system, throughput is the inverse of mean latency, and Little's Law (L = λW) links long-term average concurrency, arrival rate, and time in the system. Mean request or packet size also helps estimate total resource use because multiplying the mean by the count recovers the sum. Percentiles, medians, maxima, graphs, and other statistics reveal different aspects, but no single summary is sufficient; choose the measure for the operational question. ### Source excerpt Is the Mean Really Useless? Don't be too mean to the mean. "The mean is useless" is a commonly-repeated statement in the systems observation and monitoring world. As people correctly point out, the mean (or average1) tends to hide information about outliers, tends to be optimistic for many metrics, and can even be wildly misleading in presence of large outliers. That doesn't mean that the average is useless, just that you need to be careful of how you interpret it, and what you use it for. All descriptive statistics are misleading All descriptive statistics are misleading, and potentially dangerous. The most prosaic reason for that is that they are summaries: by their nature they don't capture the entire reality of the data they are summarizing. There is no way for a single number to capture everything you need to know about a large set of numbers. Anscombe's quartet is the most famous illustration of this problem: four data sets that have very different graphs, but the same mean and variance in 𝑥 and 𝑦, and the same linear trend. Thanks to Albert Cairo and Autodesk, there's an even more fun example: the datasaurus dozen2. There are other, more subtle, reasons that descriptive statistics are misleading too. One is that statistics in real-world computer systems change with time, and you can get very different results depending on how those changes in time align with when you sample and how long you average for. Point-in-time sampling can lead to completely missing some detail, especially when the sampling time is aligned to wall-clock time with no jitter. In this example, we've got a machine that runs a periodic job (like a cron job) every minute, and it uses all the CPU on the box for a second. If we sample periodically, aligned to the minute boundary, we'll think the box has 100% CPU usage. Instead, if we sample periodically aligned to any other second, we'll think it completely idle. If, instead, we sample every second and emit a per-minute summary we'll get a mea