Stage 1,000,000 discoveries an hour for the next deployment

http 300000, https and ssh 250000, ftp and smtp 100000. Every rate recomputed to
hold its existing window rather than spend it, the same method as the last two
steps: 98/82/94/132/132 keeps all five runs within 20s of where they are, so the
cron layout and flock margins are untouched.

Measured at 800000 first, one full cycle: 67% CPU average, ~70% peak, drift +0.70%
to +0.98% on the long protocols, no skipped ticks, 7442 hosts an hour. http came
out of that step with 527s of margin having *gained* 25000 candidates.

Two things get materially bigger and neither has been seen at this size. Peak ZMap
send 322pps -> 406pps. Discovery grabs 7444 -> 9150 an hour, +23%, and grabs are
what move CPU - the last three candidate steps cost about 2 points each, so ~70% is
the expectation. That is an extrapolation from three points, and variables.tf
already records two CPU projections that were confidently wrong, so it is written
down as something to measure rather than to rely on.

Not applied. Rides along with the next change that rolls the instance, same as the
74pps did.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Author: joocer

terraform/variables.tf

@@ -302,18 +302,42 @@ variable "scan_protocol_budgets" {
     at 82+66+75, plus one banner at 99). Grabs, which are what actually move CPU here,
     rise about 20% on the discovery side - roughly 6290 to 7550 an hour - and 8% in
     total once refresh's fixed 9900 is counted.
+
+    800000 -> 1000000, same method again: every rate recomputed to hold its window.
+
+      http  250000@82 3052s -> 300000@ 98 3064s   margin  536s
+      https 200000@66 3033s -> 250000@ 82 3052s   margin  548s
+      ssh   200000@75 2670s -> 250000@ 94 2663s   margin  937s
+      ftp    75000@99  761s -> 100000@132  761s   margin 2839s
+      smtp   75000@99  761s -> 100000@132  761s   margin 2839s
+
+    Measured at 800000 before this step, one full cycle: CPU 67% average and ~70% peak,
+    drift +0.70% to +0.98% on the three long protocols, no skipped ticks, 7442 hosts an
+    hour discovered. http came out of the previous step with 527s of margin having
+    gained 25000 candidates, which is what 82pps bought.
+
+    Two things get materially bigger here and neither has been observed yet at this
+    size. Peak ZMap send goes 322pps -> 406pps. Discovery grabs go 7444 -> 9150 an hour,
+    +23%, and grabs are the thing that actually moves CPU - the three previous candidate
+    steps each cost about 2 points, so ~70% is the expectation, but that is an
+    extrapolation from three points and this file records two earlier CPU projections
+    that were both wrong. Measure it; do not trust the number.
+
+    If CPU does land near 80% or drift starts eating the ~540s margins, this is the
+    point where the answer stops being tuning: refresh already holds a fixed 9900 grabs
+    an hour and c6g.xlarge doubles the cores.
   EOT
   type = map(object({
     candidates = number
     rate_pps   = number
     minute     = number
   }))
   default = {
-    http  = { candidates = 250000, rate_pps = 82, minute = 6 }
-    https = { candidates = 200000, rate_pps = 66, minute = 6 }
-    ssh   = { candidates = 200000, rate_pps = 75, minute = 6 }
-    ftp   = { candidates = 75000, rate_pps = 99, minute = 10 }
-    smtp  = { candidates = 75000, rate_pps = 99, minute = 50 }
+    http  = { candidates = 300000, rate_pps = 98, minute = 6 }
+    https = { candidates = 250000, rate_pps = 82, minute = 6 }
+    ssh   = { candidates = 250000, rate_pps = 94, minute = 6 }
+    ftp   = { candidates = 100000, rate_pps = 132, minute = 10 }
+    smtp  = { candidates = 100000, rate_pps = 132, minute = 50 }
   }
 }