NetQuickCheck technical documentation

Data sources and interface selection

NetQuickCheck combines system sampling, active network probes and derived statistics. System sampling provides interface, wireless and process connection information. Active probes capture a target's response to a request. Derived statistics turn observations into rates, percentiles and charts.

Tasks with a selected interface bind their requests to it. TCP, UDP and direct HTTP requests use Network.framework interface binding; ICMP probes use the system command's interface argument. Automatic routing lets macOS choose the path, and automatic HTTP requests follow system session and proxy policies. The selected interface is saved with the results to support comparisons across Wi-Fi, Ethernet and other available interfaces.

Current network and quick checks

Interface readings and transfer rates

Current Network reads interface status, addresses, gateway and DNS, together with wireless readings for the connected Wi-Fi network. Transferred bytes come from 64-bit system routing interface counters. Receive errors, send errors and receive queue drops are retained separately.

Receive rate (B/s) = Increase in received bytes between samples ÷ Sample interval (seconds)
Send rate (B/s) = Increase in sent bytes between samples ÷ Sample interval (seconds)
Bit rate (Mbps) = Byte rate × 8 ÷ 1,000,000

Rates describe average transfer volume during the sample interval. MiB/s uses 1,048,576 bytes per unit; Mbps uses one million bits per second. Interface counters and counters aggregated by app cover different sets of traffic.

The sequence of a quick check

Quick check confirms the local connection, probes the gateway, queries DNS, checks Internet connectivity, requests HTTPS and then checks egress information. The current implementation allows 8 seconds for the whole check. Each active step can use up to 2 seconds of the remaining budget, and results update as each step finishes.

The gateway step attempts a TCP connection to gateway port 443. Both a successful connection and an explicit connection refusal confirm a response from the gateway; the original connection result is also retained. DNS, Internet and HTTPS steps record their own responses to help examine each part of the connection path.

Wi-Fi scanning and wireless metrics

Wireless scanning uses CoreWLAN to obtain nearby access points' SSID, BSSID, primary channel, band, channel width and received signal strength. The available channel catalog comes from the current wireless interface. Broadcast information elements add security capabilities, Wi-Fi standards, country codes and other details. Access to identifiers such as SSID and BSSID follows macOS location permission rules.

RSSI, noise and signal-to-noise ratio

RSSI and noise use dBm, a logarithmic power measure relative to 1 milliwatt. An RSSI value closer to 0 means a stronger received signal. When both readings are valid, the app calculates signal-to-noise ratio:

SNR (dB) = RSSI (dBm) − Noise (dBm)

For example, RSSI of −55 dBm and noise of −92 dBm give an SNR of 37 dB. The current calculation accepts readings from −127 to −1 dBm. If either reading is missing, SNR remains empty.

Wireless signal monitoring has two sampling sources. Local mode periodically reads the connected Wi-Fi network; nearby mode repeatedly scans selected access points. Charts retain the time of each reading, and access point identities distinguish different wireless signals.

Broadcast channel utilization

When an access point broadcasts a valid BSS Load information element, the app converts its channel utilization field from 0–255 to a percentage: field value × 100 ÷ 255. This preserves the meaning of the broadcast value. The channel overlap chart uses the frequency coverage and power model described below.

Channel coverage and evaluation

Converting channels to frequency ranges

Channel evaluation builds frequency ranges from band, primary channel and channel width. For 2.4 GHz channels 1–13, center frequency in MHz is 2407 + 5 × channel number; channel 14 maps separately to 2484 MHz. For 5 GHz, it is 5000 + 5 × channel number. A 20 MHz range extends 10 MHz to either side of the center; wider channels combine subchannel blocks supported by the catalog.

Candidates are generated by band and channel width, and every subchannel in a candidate must exist in the current catalog. The app evaluates 20 and 40 MHz combinations on 2.4 GHz, and 20, 40, 80 and 160 MHz combinations on 5 and 6 GHz. Scan records are merged by band and BSSID. When BSSID is missing, the scan record identifier serves as the fallback identity to avoid counting the same access point twice.

When channel width or direction information is incomplete, the app retains confirmed and possible coverage separately. Ranges shared by all possible positions are confirmed coverage; the rest remain possible coverage. Each access point is counted once.

Calculating overlap power from logarithmic signal readings

Signal strength is converted from dBm to relative linear power, then weighted by the fraction of frequency overlap. For access point i and candidate c:

Pᵢ = 10 ^ ((RSSIᵢ + 100) ÷ 10)
wᵢ,c = Total overlapping bandwidth ÷ Total modeled access point bandwidth
Poverlap,c = Σ (Pᵢ × wᵢ,c)

The +100 term provides a shared relative power reference. When channel width is uncertain and overlaps the candidate range, the weight is conservatively set to 1. Both signal strength and coverage width therefore contribute. A 10 dB RSSI difference corresponds to a tenfold linear power difference.

Ranking candidates

When the current access point can be identified, it is excluded so that ranking evaluates surrounding signals. The current ranking filters out DFS candidates. On 2.4 GHz at 20 MHz, the 1, 6 and 11 channel group is preferred, followed by comparisons of access points with missing RSSI, estimated interference power, total access point count and channel sequence.

When every candidate has comparable noise readings, noise is also converted to linear power and included. Otherwise, candidates are compared using overlapping signal power alone. Each candidate subchannel uses the middle of its sorted valid noise readings; the complete candidate takes the higher of those noise values.

Within the same band and channel width, the current configuration is preferred when it shares the best candidate's priority group and count of access points with missing RSSI, and its estimated power is no more than twice the best candidate's. A twofold linear power difference is about 3 dB. This reduces ranking changes caused by small differences.

Displaying overlap curves

Overlap curves calculate weighted power in a 20 MHz window around each channel center, then use logarithmic compression to map it to a relative display range of 0–1:

Display intensity = min(1, max(0, log₁₀(1 + Poverlap) ÷ 7))

This vertical axis represents relative overlap intensity derived from scan readings. If an overlapping access point lacks valid RSSI, that position stays empty and the curve is split. Confirmed and possible coverage remain separate.

Local network device discovery

Device discovery combines Bonjour, WS-Discovery, SSDP and TCP service probes. Bonjour supplies advertised service instances. WS-Discovery and SSDP add responses from compatible devices. TCP probes check service responses at addresses within the current scan range.

Current TCP probe ports are 80, 443, 445, 22, 631 and 9100, covering common web, file sharing, remote access and printing services. Requests use the selected interface. Observations retain their source, address and actual response.

Discovery merges observations from each source in batches, using device addresses and service evidence to organize names, types and services. Unavailable interfaces, access denial, timeouts and service responses are recorded separately. Cancelling or restarting a scan isolates late callbacks from the previous scan so they cannot affect the new results.

App traffic and connection ownership

Finding apps from the system connection table

App Traffic reads processes, protocols, local and remote endpoints, interfaces, connection states and byte counts from nettop. The app combines running application information, process parent relationships and executable paths to associate helper processes with their owning app.

Ownership matching first checks the process itself, then follows up to 16 parent processes. If no match is found, it uses the app bundle path containing the executable. Process identity also includes start time to distinguish reused PIDs.

Calculating each connection's change, then aggregating by app

Consecutive samples match connections by process, protocol, local endpoint, remote endpoint and interface. Rates are calculated only when the two byte counts belong to the same comparable connection, then aggregated by app.

Connection download rate = (Current received bytes − Previous received bytes) ÷ Time difference
Connection upload rate = (Current sent bytes − Previous sent bytes) ÷ Time difference
App rate = Sum of valid connection rates for the app and its associated processes

New connections establish a baseline first. A counter reset, interface change or sample gap greater than 15 seconds requires new comparable samples. If the system returns multiple identical rows that cannot be uniquely matched, the app retains those rows and leaves their rates empty so matching ambiguity does not appear as a traffic spike.

Remote connections and ICMP observations

App connection monitoring retains first and last seen times, state changes and traffic deltas, and independently probes discovered remote IPs with ICMP. Traffic, connection activity and ICMP results are aligned by time. The latency reading comes from the target IP's ICMP reply.

Ping and TCP probes

ICMP Echo and the no-response ratio

Ping resolves and fixes the target address for the probe, then sends an IPv4 ICMP Echo or IPv6 ICMPv6 Echo request. Continuous monitoring repeats according to configuration, recording actual sends, replies, missing replies and returned round-trip times.

No-response ratio = Probes with no reply ÷ Probes actually sent × 100%

Counts use the number of sends confirmed by system output. Resolution failures, permission denials and requests that could not be sent retain their specific status and do not enter the sent-probe denominator. Latency statistics use valid reply RTTs.

TCP port connections

After resolving the target, TCP port monitoring attempts a connection to the selected port and uses a monotonic clock to measure the time until success or an error. DNS resolution finishes first, and TCP connection timing is measured separately. Success, connection refusal, timeout and other system errors are retained separately to show how the same service port behaves over time.

DNS queries and response validation

DNS monitoring queries the selected server and record type, such as A, AAAA, CNAME, MX, TXT, NS, SOA or PTR. System resolution and explicit server queries follow separate paths. Automatic routing uses system resolution or dig according to the request; queries bound to a selected interface exchange packets over UDP port 53.

Direct queries generate a transaction ID and build the question name, type and IN class. Responses are checked for packet length, transaction ID, response flag, question count, name, type and class before parsing response codes, resource records and TTLs. The packet parser expands compressed domain name pointers.

NOERROR with records of the selected type, NOERROR without those records, NXDOMAIN, truncated packets and transport failures are recorded separately. PTR queries first convert the IPv4 or IPv6 address into its reverse lookup name. Timing covers the query and response parsing, and results retain the actual server and record contents.

HTTP response and stage timing

Website monitoring sends HTTP or HTTPS HEAD requests and records the returned status code, final URL and duration. Automatic routing uses URLSession transaction metrics. With an explicit interface or resolution path, the direct HTTP implementation uses Network.framework connection reports and request timestamps.

Stage duration is the difference between end and start timestamps. A reused connection may have no new DNS, TCP or TLS stage; stages without valid timestamps remain empty. Redirects retain timing for each request. Total check duration is measured separately because it also includes resolution, redirects, scheduling and other actual overhead.

HTTPS uses system certificate trust validation and extracts the subject, issuer, validity period and SHA-256 fingerprint from valid certificates. HTTP status codes describe the server's response; transport errors describe the connection process. Both are stored separately.

Network path and hop-by-hop probes

Network path monitoring resolves and fixes the target address, then sends ICMP probes with IPv4 TTL or IPv6 Hop Limit increasing from 1. Intermediate routers may return time-exceeded replies, while the destination may return an Echo Reply. The app uses these responses to organize hop addresses and available timings.

Each round currently probes up to 16 hops. If a hop does not respond, later hops are still checked. A destination reply ends the round. Unreachable and policy-denied responses retain their original results. If an address is available without a valid duration, the address is kept and timing remains empty.

Throughput and responsiveness under load

Current Network: Apple networkQuality

Current Network runs macOS networkQuality and parses its structured results, including download, upload, idle latency and responsiveness under load in RPM. RPM means round trips per minute, as measured by Apple's tool; the app retains the returned value. Raw download and upload bit rates are divided by 1,000,000 for display in Mbps.

When an interface is selected, the speed test command includes its interface argument and checks the interface name returned in the result. If the system supplies only some metrics, those fields are retained and the others remain empty.

Monitor: endpoint and system speed tests

Each Monitor speed-test round runs download and upload tests against the selected Cloudflare or LibreSpeed endpoint, then runs Apple networkQuality. The two methods retain their own source, time and actual results. Endpoint downloads read test payloads; uploads use temporary data generated by the app. Average throughput is calculated from the bytes actually transferred and the elapsed time for that stage:

Throughput (Mbps) = Bytes actually transferred × 8 ÷ Elapsed time (seconds) ÷ 1,000,000

Requests use explicit test payloads, timeouts and cache policies, retaining transfer progress, target byte count and actual transferred bytes separately. Stage results distinguish completed, partial and failed transfers. Records retain the server and interface to support comparisons under the same conditions.

Continuous monitoring, charts and statistics

Independent sampling on a shared timeline

Monitor includes ten tool types: Ping, TCP, DNS, websites, network paths, speed tests, wireless signal, interface traffic, app traffic and app connections. Each task retains its own target, parameters and sample times. A shared time window aligns observations to compare latency, wireless readings, traffic and service responses over time.

Active probes and bandwidth transfers request separate resource quotas. The current default budget allows 8 concurrent probe operations and 2 concurrent transfers. Operations beyond the budget wait until a quota is released. Cancellation waits for the actual operation to exit before releasing its quota. Quotas apply to each individual probe or transfer; repeated tasks request them again for the next round.

Chart segments and relative changes

Charts connect points by sample time and segment identity, keeping interruptions separate and showing failures individually. Interpolation at viewport boundaries is used only for drawing; statistics use actual observations.

When relative latency spike markers are enabled, the app takes the median m of the preceding 5 samples in the same segment. A latency greater than max(3 × m, m + 5 ms) is marked. Wireless signal change markers compare readings with the recent median and mark differences of at least 8 dB. These rules locate changes relative to a recent baseline.

Median, P95 and variation

Statistics use valid, finite values in the time window, sorted in ascending order. For an odd sample count, the median is the middle value; for an even count, it is the mean of the two middle values. With no valid samples, statistics remain empty. P95 uses the nearest-rank method:

P95 = Value at position ceil(0.95 × n) in ascending samples
ICMP no-response ratio = Unanswered probes ÷ Probes actually sent
ICMP latency variation = Sum of absolute RTT differences between valid adjacent replies ÷ Number of valid adjacent pairs

App connection ICMP sessions accumulate percentiles using a histogram with 0.1 ms precision, independently of the raw history retention window. Valid replies from 0 to 2000 ms enter histogram buckets. Larger values enter an overflow count and contribute to the maximum; percentiles falling in the overflow range remain empty. Latency variation only pairs valid adjacent replies in the same segment with a gap no greater than 2.5 seconds.

Monitoring records and report export

Monitoring records save task parameters, targets, sample times, actual results and supporting evidence. Charts show changes over time, while reports organize observations for reading or further processing.

HTML

A readable report with task summaries, results and details.

CSV

Evidence organized into columns such as time, category, object, target, method, status, value, unit and details for spreadsheet analysis.

JSON

Structured records, configuration and results for further processing.

Long app connection sessions use segmented archives. Export first establishes a fixed archive read range, then streams archived data and the current in-memory tail so each export uses consistent data boundaries. Missing values, failures and cancellations retain their own states for review.