on the prefix view page, add a table that lists all announcements and withdrawals for that prefix in reverse chronological order, cap it at 24h or 100 items, whichever is longer. make sure it has an asn column.
on the prefix view page, add a table that lists all announcements and withdrawals for that prefix in reverse chronological order, cap it at 24h or 100 items, whichever is longer. make sure it has an asn column.
clawbot
self-assigned this 2026-10-22 20:35:28 +02:00
Question for sneak: which history should the prefix page keep?
The feed sends about 11,000 prefix announcements and withdrawals a second; your instance has counted 4 billion since 22 October, about a billion a day. Most are the same change repeated: when one network changes its routing, each of the 1,400 RIS peers sends its own update for every prefix it affects. Keeping every update of the last 24 hours means a billion rows on disk and twice today's database writes. Today's route tables already lose updates past 20 million rows, so this cannot be built as asked.
Options:
Origin changes only (recommended): the table lists, newest first, each time an AS starts announcing the prefix (its first peer announces it) and each time it stops (its last peer withdraws it). Each row has time, announced or withdrawn, origin AS and how many peers carry it. Kept for 24 hours or the last 100 rows, whichever holds more, apart from the routing table so pruning never touches it. Small enough to keep for every prefix.
The newest 100 updates per prefix, every peer's own announcement or withdrawal with peer, origin AS and AS path, and no 24-hour rule. Up to 150 million rows (about 15 GB), and twice today's writes, which the prefix handler may not keep up with.
As asked: every update of the last 24 hours. About a billion rows; not workable on this hardware.
Until you answer, the other work continues.
Model: opus-5-5
**Question for sneak:** which history should the prefix page keep?
The feed sends about 11,000 prefix announcements and withdrawals a second; your instance has counted 4 billion since 22 October, about a billion a day. Most are the same change repeated: when one network changes its routing, each of the 1,400 RIS peers sends its own update for every prefix it affects. Keeping every update of the last 24 hours means a billion rows on disk and twice today's database writes. Today's route tables already lose updates past 20 million rows, so this cannot be built as asked.
Options:
- **Origin changes only** (recommended): the table lists, newest first, each time an AS starts announcing the prefix (its first peer announces it) and each time it stops (its last peer withdraws it). Each row has time, announced or withdrawn, origin AS and how many peers carry it. Kept for 24 hours or the last 100 rows, whichever holds more, apart from the routing table so pruning never touches it. Small enough to keep for every prefix.
- **The newest 100 updates per prefix**, every peer's own announcement or withdrawal with peer, origin AS and AS path, and no 24-hour rule. Up to 150 million rows (about 15 GB), and twice today's writes, which the prefix handler may not keep up with.
- **As asked**: every update of the last 24 hours. About a billion rows; not workable on this hardware.
Until you answer, the other work continues.
Model: opus-5-5
clawbot
removed their assignment 2026-10-26 21:19:47 +01:00
sneak
was assigned by clawbot2026-10-26 21:19:47 +01:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
on the prefix view page, add a table that lists all announcements and withdrawals for that prefix in reverse chronological order, cap it at 24h or 100 items, whichever is longer. make sure it has an asn column.
Question for sneak: which history should the prefix page keep?
The feed sends about 11,000 prefix announcements and withdrawals a second; your instance has counted 4 billion since 22 October, about a billion a day. Most are the same change repeated: when one network changes its routing, each of the 1,400 RIS peers sends its own update for every prefix it affects. Keeping every update of the last 24 hours means a billion rows on disk and twice today's database writes. Today's route tables already lose updates past 20 million rows, so this cannot be built as asked.
Options:
Until you answer, the other work continues.
Model: opus-5-5