-- RTT Analysis using TCP timestamp echo
-- Measures actual network RTT by tracking when our ts_val gets echoed back
-- For client-side captures: dst_port in (80,443) = outbound, src_port in (80,443) = inbound
WITH outbound AS (
-- Packets TO server (dst_port is well-known)
SELECT
t.frame_number,
f.timestamp as send_ts,
t.dst_port as server_port,
t.ts_val,
i.src_ip as local_ip,
t.src_port as local_port,
i.dst_ip as remote_ip
FROM tcp t
JOIN ipv4 i ON t.frame_number = i.frame_number
JOIN frames f ON t.frame_number = f.frame_number
WHERE t.ts_val IS NOT NULL
AND t.dst_port IN (80, 443, 8080, 8443)
),
inbound AS (
-- Packets FROM server (src_port is well-known)
SELECT
t.frame_number,
f.timestamp as recv_ts,
t.src_port as server_port,
t.ts_ecr,
i.dst_ip as local_ip,
t.dst_port as local_port,
i.src_ip as remote_ip
FROM tcp t
JOIN ipv4 i ON t.frame_number = i.frame_number
JOIN frames f ON t.frame_number = f.frame_number
WHERE t.ts_ecr IS NOT NULL
AND t.ts_ecr > 0
AND t.src_port IN (80, 443, 8080, 8443)
),
-- Match: find when our ts_val was echoed back by the server
rtt_samples AS (
SELECT
o.frame_number as send_frame,
MIN(i.frame_number) as recv_frame,
o.server_port,
o.send_ts,
MIN(i.recv_ts) as recv_ts
FROM outbound o
JOIN inbound i
ON o.local_ip = i.local_ip
AND o.local_port = i.local_port
AND o.remote_ip = i.remote_ip
AND o.server_port = i.server_port
AND i.ts_ecr = o.ts_val
AND i.frame_number > o.frame_number
GROUP BY o.frame_number, o.server_port, o.send_ts
),
rtt_values AS (
SELECT
server_port,
EXTRACT(EPOCH FROM (recv_ts - send_ts)) * 1000.0 as rtt_ms
FROM rtt_samples
WHERE recv_ts > send_ts
)
SELECT
server_port,
hdr_count(hdr_histogram(rtt_ms)) as samples,
ROUND(hdr_min(hdr_histogram(rtt_ms)), 2) as min_ms,
ROUND(hdr_percentile(hdr_histogram(rtt_ms), 0.50), 2) as p50_ms,
ROUND(hdr_percentile(hdr_histogram(rtt_ms), 0.75), 2) as p75_ms,
ROUND(hdr_percentile(hdr_histogram(rtt_ms), 0.95), 2) as p95_ms,
ROUND(hdr_percentile(hdr_histogram(rtt_ms), 0.99), 2) as p99_ms,
ROUND(hdr_max(hdr_histogram(rtt_ms)), 2) as max_ms,
ROUND(hdr_mean(hdr_histogram(rtt_ms)), 2) as mean_ms
FROM rtt_values
WHERE rtt_ms > 0 AND rtt_ms < 30000
GROUP BY server_port
ORDER BY samples DESC;
+-------------+---------+--------+--------+--------+--------+--------+--------+---------+
| server_port | samples | min_ms | p50_ms | p75_ms | p95_ms | p99_ms | max_ms | mean_ms |
+=======================================================================================+
| 443 | 315 | 1.0 | 75.0 | 263.0 | 349.0 | 3007.0 | 3007.0 | 177.27 |
|-------------+---------+--------+--------+--------+--------+--------+--------+---------|
| 80 | 6 | 70.0 | 71.0 | 72.0 | 72.0 | 72.0 | 72.0 | 71.17 |
+-------------+---------+--------+--------+--------+--------+--------+--------+---------+https://github.com/mtottenh/pcapsql
I was chatting with a colleague a while ago, and they wanted to run some SQL queries against a PCAP – aggregate by source IP, that sort of thing. They went looking and found PacketQ (DNS/ICMP only), Apache Drill's PCAP support (outer headers only), DuckDB has a PCAP reader community extension (same deal, limited to outer headers). You can always write a one-off script with scapy or gopacket,...
This is even worse on pages like the about page where it feels like only 1/3rd of the screen is available for scrolling/reading text; it just feel totally hostile to browse.
“Please won’t someone think of the children” s/children/those of us with small hands and correspondingly small phone screens/
I'm a principal lead on Akamai's Linux Performance Team, and we're actively hiring talented engineers to join our team!
What we do: We're a specialized group of software engineers who tackle complex performance challenges across Akamai's entire product stack. While many know us for our CDN, over two-thirds of our revenue now comes from security and compute products - you'll be working on problems that directly impact millions of users across our cloud platform and security solutions.
Recent projects we've shipped: - Hardware offload of network firewall rules for massive performance gains - eBPF tracing implementations across one of the world's largest CDNs
Experience that would be valuable: - Linux kernel development experience - eBPF expertise - DPDK knowledge - Strong systems programming background - Passion for performance optimization and debugging
Why join us: You'll work on cutting-edge performance problems at internet scale, collaborate with brilliant engineers, and have the flexibility of remote work across EU and US time zones. Your work will directly impact how the internet performs for millions of users.
Contact: [email protected]
Internally a number of the engineers are scratching our heads at this one.
- weekly 1:1 with our line manager
- weekly Team meeting (15 minutes of status updates, rest of the time talking over project ideas or other LoB)
- shared team chat room on Webex teams.
Both meetings are video optional but most folks choose to hop on video.
That’s it. It works well, and there is minimal bureaucracy.
But guardicore’s website is just full of marketing fluff with very little detail.
Hopefully someone from either Akamai or guardicore lurks here and can explain
You send the device a circular list of descriptors (pointers) to a region of main memory.
In order to send data to the device, you write your network packet to the memory region associated with the pointer of the current ‘head’ of the descriptor list.
So far, you have a ring of pointers, one of those pointers points to a location you just wrote to in ram.
You then tell the device that the head of the list has changed (as you just wrote some data to the region that the head of the list is pointing to - so it can consume that pointer), the device then goes ahead and copies the data from ram into an internal buffer on the card. Once the data is consumed, the tail pointer of the ring buffer is updated to indicate that the card is finished with that memory region.