Short answer: you can’t “prove” intent, but you can collect pretty strong evidence that somewhere past your LAN the link is batching/scheduling your traffic (common on cable/GPON/DSL or when a shaper/policer is in play). Here’s how to test it cleanly.

# What “bundling” would look like

* You send tiny packets at steady spacing (e.g., every 1–2 ms).
* They **arrive** in clumps (many back-to-back packets) followed by small idle gaps (e.g., 5–20 ms), repeating.
* The clump size and gap are fairly consistent and **don’t** match your sender’s spacing.

# Control the variables first

1. **Wire only** (no Wi-Fi).
2. **Use UDP** probes to avoid TCP behaviors (Nagle, delayed ACKs).
3. **Disable NIC offloads on capture hosts** so your pcap isn’t faked by GRO/LRO/TSO:
   `sudo ethtool -K eth0 gro off gso off lro off tso off`
4. **Avoid your router’s own shaper** during the test (disable SQM/cake/fq\_codel shaping for a minute, or test well below line rate).

# Minimal experiment (client → VPS)

You need a Linux box at home and a cheap VPS (or a friendly server) on the Internet.

**On the VPS (receiver):**

```bash
sudo tcpdump -ni eth0 udp port 5555 -w /tmp/rx.pcap
```

**On your home box (sender):**

* Send a perfectly regular stream of small UDP packets:

```bash
nping --udp -p 5555 --data-length 32 --rate 500 -c 10000 <VPS_IP>
# 500 pps ≈ every 2 ms
```

Stop tcpdump and pull `/tmp/rx.pcap` to your PC. In Wireshark:

* View → Time Display Format → “Seconds since previous captured frame”.
* Make an **IAT (inter-arrival time) histogram** (Statistics → I/O Graphs: graph packets/s and add a graph of `delta time displayed`).
* If you see **stair-step patterns** like “8–16 packets at \~0 µs spacing” then a \~10 ms gap, repeating, that’s batching.

# Isolate where it happens

Do the **same capture at three points**:

1. **LAN side** of your sender (just to confirm you transmit evenly).
2. **WAN side** of your home router/ONT (MikroTik example):

```
/tool/sniffer/start interface=<wan> filter-ip-protocol=udp filter-port=5555 file-name=wan.cap
# run nping
/tool/sniffer/stop
```

3. **Remote VPS** (as above).

Compare inter-packet gaps:

* Even at (1) but clumpy at (2) → your **router/ONT** (local shaping or DOCSIS/GPON upstream scheduler) is creating bursts.
* Even at (2) but clumpy at (3) → **beyond your last-mile** (ISP/core shaping/policing) is doing it.
* Clumpy already at (1) → your **sender** (OS/app) or NIC offloads are batching.

# Optional higher-precision checks

* **OWAMP/TWAMP (owping/twamp)**: measures **one-way** delay (needs NTP/chrony sync) so you can see periodic delay spikes that line up with the clumps.
* **iperf3 -u** at modest, fixed bitrate plus a pcap on the receiver to visualize bursts under load.
* Try multiple destinations (VPS in different ASNs). If the clump pattern stays the same, it’s likely **last-mile scheduling** (e.g., DOCSIS request/grant cycles, GPON TDMA windows, DSL interleaving/shaper).

# What it might actually be

* **Last-mile schedulers** (DOCSIS/GPON/5G) transmit your upstream in **bursts** by design.
* **Token-bucket shapers/policers** (ISP or CPE) release traffic in **quantized bursts** once tokens accrue.
* **Your own gear**: SQM off → bigger bursts; SQM on (cake/fq\_codel) → smoother spacing. NIC **GRO/LRO** can *look* like bundling in captures.

# “Proof” standard

If you show: (a) steady transmit spacing, (b) consistent burst pattern only after the last-mile/ISP hop, and (c) the pattern persists to multiple remote nets and times of day, you’ve built solid, operator-grade evidence that your packets are being **batched/paced** beyond your LAN.

If you want, tell me your router/ONT model (you’ve used MikroTik before) and I’ll tailor exact capture commands and a quick Wireshark “recipe” for the histogram/graphs.