LineaChiara

A number is useful
when you know how it was measured.

LineaChiara sends requests from the device opening the page. The web app is independent, and the Windows script is a separate optional tool. Neither produces a certified assessment of the access line.

Session protocol

  1. Initial HTTP reachability check to the measurement destination, excluded from idle statistics.
  2. Optional Cloudflare metadata and reachability checks to two DNS-over-HTTPS (DoH) endpoints.
  3. Zero-payload HTTP requests for idle latency and variability.
  4. Download with one, two or four streams and concurrent latency requests.
  5. An 800 ms pause, then upload with the same concurrency setting and latency measurements.
  6. Session close, optional local storage and downloadable reports.

Block sizes adapt to observed timing. Upload data is random; personal documents are not transmitted. Requests omit credentials and referrers and ask to avoid caching. Received download bytes are checked against the requested payload.

Optional data-capped profiles

The default measures for 10 seconds per direction, adjustable to 5, 10, 20 or 30 seconds, without an MB cap. The following table only applies to the optional data limit.

ProfileIdle samplesWindow per directionMaximum reserved payload
Quick106 seconds25 MB
Complete2010 seconds100 MB
Extended4018 seconds300 MB

Download receives 70% of the budget, upload 30%. Each request reserves its allocation before being sent, even if it later fails. In-flight requests may continue for their remaining timeout, up to six seconds. Headers, TLS, retransmissions and small control messages are additional. Counters are not the provider’s billed traffic. A fast connection may exhaust the budget before a representative window is collected.

Formulas

  • Aggregate throughput: successfully completed bytes × 8 / total phase duration, across all concurrent streams. Duration includes connection setup, HTTP time and failed requests. Individual request rates are not added together.
  • HTTP latency: median application-level duration, from before fetch until the response body has been read. Includes browser and server work. No assumed server time is subtracted.
  • HTTP jitter: mean of |t[n] − t[n−1]| for consecutive valid samples to the same endpoint, without bridging timeouts or separate speed cycles. Not the RTP jitter of a call.
  • p95: interpolated 95th percentile of sorted observations. Small sample counts limit its usefulness.
  • Loaded increase: median latency during a transfer direction minus idle median. Negative values remain visible.
  • Standard deviation: square root of the mean squared distance from the mean over the observed valid sample population.

DNS, connection, TLS and first-byte timings come from Resource Timing when the browser exposes them. Missing timing can mean a reused connection, caching or cross-origin restrictions. Connection time may include TLS. Missing data is not interpreted as zero or a fault.

Monitoring and interruptions

Monitoring runs cycles at least five seconds apart. It queries the chosen destination and Google DoH in sequence, each with a four-second timeout. Slow cycles delay the next one. The graph shows the main destination; the table contains both. These paths do not represent the entire Internet. We record request failures, not exact outage duration between samples or contractual availability.

Cycles are serial and stop on cancellation, duration expiry or page closure. Browsers may throttle hidden tabs or suspend devices. No continuous background operation is promised.

Automatic observations

Rules are local, readable in the source and do not use a remote AI model. Internal thresholds of 15 ms jitter and 40 ms loaded increase are indicative, not compliance standards or service-level agreements. With fewer than three loaded samples in a direction, the bufferbloat warning rule is not applied to that direction. Reports separate evidence, interpretation and the next test; they do not automatically blame the provider.

Integrity, language and privacy

Timestamps use the device clock. The HTML report includes a SHA-256 fingerprint of the exportable session with the same IP option. This checks consistency, not authenticity or certification. Imported JSON is user-provided data. Review free-text notes before sharing. Switching language changes presentation and generated reports; stored samples, units, canonical field values and original event messages remain unchanged. User notes are not translated.

Technical sources

Method version 0.2 · 17 September 2026. External endpoints and browser policies may change.

Single, timed or continuous tests

A single test measures download and upload for 5, 10, 20 or 30 seconds each, in addition to initial checks. In-flight requests may take up to 6 extra seconds to finish. Timed observation lasts minutes, hours or days, with 24-hour, 3-day and 7-day presets plus a custom duration; “No end time” runs until Stop. Keep the page open and the device awake: browsers can suspend background work.

Full network repeats speed measurements at your chosen interval and observes stability between them. Stability only makes small HTTP requests every 5, 15, 30 or 60 seconds, according to your choice, without measuring download or upload speed. Speed tests never overlap. Time-based modes have no automatic MB cap and may use many GB. An optional data budget limits each speed measurement but does not end the observation.

Export interim reports without stopping observation. Memory retains at most 10,000 samples, 100 speed cycles and 2,000 recent events. Reports disclose discarded evidence: statistics describe the retained window, while traffic totals cover the entire session. History, cache and reports do not constitute an always-on monitoring service.

Hours, days and missing responses

No end time continues until you press Stop. Timed mode supports minutes, hours, days or a custom duration. Stability only is recommended for a full day: small requests without continuous large transfers. Full network can repeat speed measurements every 15, 30 or 60 minutes.

Hourly history records successful and failed requests, mean resting latency, jitter and speed cycles completed in that hour. Up to 2,160 hourly buckets and 1,000 periods are retained independently of 10,000 raw samples, 100 speed cycles and 2,000 recent logs. Reports disclose removed evidence. Missing hours are not filled with zeros and intermittent checks do not establish continuous uptime percentages.

We compare the selected server with Google and distinguish missing responses on one or both destinations. This cannot identify provider responsibility. Timers delayed or suspended for over 30 seconds produce a period without observations; recovery is confirmed only by a later successful check. Closing the page or powering off stops measurements. The screen-awake option depends on browser support and does not prevent system sleep.

If local retention is enabled, a checkpoint is saved at startup and approximately every minute of activity, when supported by the browser. Reopening can recover data up to the latest save. It does not invent missing measurements or restart traffic automatically. A normal stop saves to history. Download reports and JSON to archive long observations.

PDF reports ready to share

User and technical reports download directly as PDFs, branded with links to PHABDEV. HTML and Markdown are alternatives. Technical PDFs embed session.json and samples.csv. Compatible readers expose them in the attachments panel; if a browser hides attachments, download JSON and CSV separately. Your IP selection also applies to embedded files; free-text notes are not automatically redacted.

Alternative servers

Cloudflare remains the default. Compare it with the public Clouvider servers in Frankfurt and London listed in the official LibreSpeed directory. Shared resources: availability, capacity and conditions can change. No PHABDEV partnership is implied. We send no reports, notes or telemetry, but operators see diagnostic requests and your IP. The adapter uses garbage.php downloads in 1 MiB chunks and empty.php for uploads and latency. Different destinations can produce different results on the same connection.

Guides by problem