Questions: DP value, RAM sizing, checkpointing

[Zreaptrix]

Hi pscamillo,

I came across PSCKangaroo through the BitcoinTalk forum and wanted to reach out with a few questions. First, I really appreciate the work you've put into this, the checkpoint system and concurrent mode stand out as genuine improvements over RCKangaroo for long runs.

My setup: I currently have one RTX 5070 Ti and 16GB system RAM, and I'm planning to add a second 5070 Ti down the line. A few questions if you don't mind:

1. Checkpointing: Does a clean Ctrl+C save everything (both the TAME table and WILD state) so a resume picks up with zero wasted work?

2. DP value and RAM: I've been reading RetiredCoder's forum posts and got a bit confused. My understanding is: higher DP = fewer distinguished points generated but each one is more "valuable", and more RAM = larger TAME table = better collision probability. Is that right? And on DP vs timeframe, I think both a lower DP run and a higher DP run ultimately accumulate the same total number of entries in the table, it's just a matter of how long it takes to get there? So my real question is: Does a higher DP setting with the same RAM limit as a lower DP run simply take longer to fill the same table, meaning it covers more total keyspace hops to get there, or does it end up exploring the same amount of keyspace as a lower DP run, just spread over a longer timeframe?, covering ground that the lower DP shorter run wouldn't reach? And on the qualifying DP point, since kangaroo paths are deterministic once started, if a tame and wild path would have collided at a point that doesn't qualify as a DP under the current threshold, the kangaroo hops straight past it silently. But since the paths are deterministic, would that missed collision still show up quickly once either kangaroo eventually lands on a qualifying DP nearby, or is it gone forever unless they happen to cross again at a valid point?

3. RAM upgrade: Is it worth upgrading from 16GB to 64GB or 128GB for Puzzle 135, and how much does the larger TAME table actually improve my odds?

4. Adding RAM mid-run: If my TAME table fills at 16GB and I later upgrade to 64GB, can I load my existing checkpoint and continue with the larger limit, or does the table need to be rebuilt?

I know Puzzle 135 is essentially a lottery for my system, I'm just trying to make sure I'm not leaving odds on the table with the wrong configuration. Thanks again for building this.

[pscamillo]

Great questions! Let me address each one:

1. Checkpointing:
Ctrl+C saves the TAME table and WILD checkpoint. On resume with -loadwild wild_checkpoint.dat, TAMEs are restored. However, WILDs are not preserved — they restart from new random positions. This is fine because WILDs are stateless checkers — their value is in the hops they perform against the TAME table, not in their positions. Zero wasted TAMEs, WILDs restart fresh.

2. DP value and RAM — this is the key question:

Higher DP means fewer DPs stored per hop, but each DP represents a longer walk. The TAME table fills slower, but each entry covers more "ground."

Your intuition is mostly right, but with an important nuance:

• Same RAM, different DP: Both fill the same table eventually. Lower DP fills faster but entries are "shorter walks." Higher DP fills slower but entries are "longer walks." The total keyspace explored when the table is full is similar — what changes is the granularity of your coverage.
• The real trade-off is collision detection delay. With lower DP, a collision is detected sooner after it happens (fewer hops between DPs). With higher DP, there's a longer delay between when a TAME-WILD collision occurs on the walk and when both paths hit a DP to be detected. This delay doesn't lose the collision — it just means more hops happen before detection, slightly increasing the K factor.
• Missed collisions: No collision is "gone forever." When a TAME and WILD cross at a non-DP point, they follow identical deterministic paths from that point. Both will eventually hit the same next DP — and that's when the collision is detected. The DP is just the detection mechanism, not the collision itself. Higher DP = longer average delay to detection, but collisions are never lost.

For your 16 GB system, use DP=16. Lower DP (12-14) generates more CPU load and heat. Higher DP (20+) wastes table capacity. DP=16 is the sweet spot for thermal stability and table efficiency.

3. RAM upgrade:
With 16 GB, your TAME table holds ~800M entries (after OS overhead, -ramlimit 10).
With 64 GB, ~3.5B entries (-ramlimit 50).
With 128 GB, ~7.4B entries (-ramlimit 120).

More TAMEs = proportionally more T-W collision probability per WILD hop. 128 GB gives ~9× more TAMEs than 16 GB — roughly equivalent to running 9 GPUs with 16 GB. For a long-term lottery run on Puzzle 135, the RAM upgrade is the single best investment you can make.

4. Adding RAM mid-run:
Currently, no — the table size is fixed at startup based on -ramlimit. Loading a 10 GB checkpoint into a 50 GB table would require rebuilding the hash table with different bucket sizes. You would need to restart with the new ramlimit, losing the existing TAMEs.

However, your old TAMEs only represented ~800M entries. With 64 GB you'll build 3.5B entries in ~3 days. The lost progress is minimal compared to the gain.

Recommended command for your current setup:

./psckangaroo -gpu 0 -dp 16 -range 134 \
  -pubkey 02145d2611c823a396ef6712ce0f712f09b9b4f3135e3e0aa3230fb9b6d08d1e16 \
  -start 4000000000000000000000000000000000 \
  -ramlimit 10 -concurrent 1 -checkpoint 4

Note: I removed -wwbuffer since 10 GB is tight — better to use all RAM for TAMEs.

When you add the second 5070 Ti, use -gpu 01 (multi-GPU is experimental but confirmed working at 5.75 GK/s with 2× RTX 5070).

Welcome aboard! 🦘

[Zreaptrix]

Thank you so much for the detailed explanations and your willingness to help, really appreciate it.

A few follow-up questions:

1. Collision detection delay: At 4+ billion hops per second, once a tame and wild path cross at a non-qualifying point, is the delay before both hit the next qualifying DP essentially a fraction of a second? Since the paths are deterministic from that crossing point, they'll both land on the same next DP very quickly regardless of DP setting, is that right?

2. My current RCKangaroo run: I've been running RCKangaroo for about 4 days at 4.45 billion hops per second with DP=23. At that rate my 16GB RAM would fill in roughly 7 days total. Should I wait out the remaining 3 days until the table is full before switching to PSCKangaroo, or have those 4 days been inefficient enough (sparse table, slow fill) that I'm better off restarting fresh with PSCKangaroo at DP=16 now?

3. Wild checkpoint clarification: You mentioned PSCKangaroo saves the wild checkpoint on Ctrl+C, but also said WILDs restart from new random positions on resume. What exactly does the wild checkpoint file preserve then if the WILDs themselves don't carry over?

4. RAM upgrade cost vs benefit: For maximising TAME table size on a budget, would server-grade 128GB DDR3 be a viable option, or would a DDR4/DDR3 64GB consumer board be a better balance of cost and performance? And does dropping to DDR3 speeds meaningfully hurt DP lookup and table access speeds, or is the bottleneck elsewhere and RAM speed largely irrelevant?

Thanks again.

[pscamillo]

Good follow-ups!

1. Collision detection delay:
Yes, essentially instant. At DP=16, the average distance between qualifying DPs is 2^16 = 65,536 hops. At 3+ GK/s, that's ~22 microseconds. Even at DP=23, it's ~2.8 milliseconds. The collision is never lost — the detection delay is negligible compared to the time to find a collision in the first place (years).

2. Your RCKangaroo run (DP=23, 4 days, 4.45 GK/s):
At DP=23, your DP rate is ~530 DPs/s. After 4 days: ~183M entries × 40 bytes = ~7.3 GB. Your table is roughly 46% full.

Two problems:

• RC has no -ramlimit. With 16 GB system RAM, it will OOM crash before the table fills — RC uses malloc without NULL check (verified in source). You're at risk right now.
• RC's table format (40 bytes/entry) is not compatible with PSCKangaroo's (16 bytes/entry). The TAMEs can't be transferred.

My recommendation: switch now. Those 183M entries at DP=23 took 4 days. PSCKangaroo at DP=16 with -ramlimit 10 will build ~670M entries (3.6× more) in about the same time, with crash protection and checkpoint. The 4 lost days are a small price for a safer, denser table.

3. Wild checkpoint clarification:
The file wild_checkpoint.dat is poorly named — it actually saves the TAME table (table[0] contents). "Wild checkpoint" was the original name from the codebase and stuck. WILDs themselves are not saved because they're stateless — their positions don't matter, only the TAMEs they check against. On resume, TAMEs load from the file, WILDs start fresh with new random positions. I should rename this in a future version to avoid confusion.

4. DDR3 vs DDR4/DDR5:
RAM speed is almost irrelevant for PSCKangaroo. The bottleneck is the GPU kernel (billions of EC point additions per second), not RAM access. The CPU-side hash table lookups are random access patterns that are latency-bound, and even DDR3 handles ~30K lookups/s without breaking a sweat (our DP=16 generates ~14.6K TAMEs/s).

Go for maximum capacity at minimum cost. A used server board with 128 GB DDR3 ECC would outperform a 32 GB DDR5 setup for this specific use case. The only thing that matters is how many 16-byte TAME entries you can fit.

One caveat: make sure the motherboard and CPU support the total RAM capacity. Some consumer boards max out at 64 GB even with DDR4.

Important: Make sure you pull the latest code before starting. We just pushed v59b which fixes a critical bug — concurrent mode was not storing TAMEs when batch sizes were small (DP≥16). Without this fix, the TAME table stays empty while the display shows an estimated fill rate.

git pull
make clean && make

This applies to everyone running concurrent mode.

[Zreaptrix]

Thank you for clearing everything up, genuinely appreciated.

Good to know about v59b, pulling and rebuilding now before starting.

On the RAM side, yes, I've been doing my homework on the different motherboard and CPU configurations, RAM capacity, limits per chipset, and PCIe lane allocations. On that note: I tested that PCIe Gen 3 x16 and Gen 4 x16 are effectively identical in real-world GPU compute performance for the 5070 Ti for these workloads, and that PCIe Gen 2 x1 shows roughly a 3% performance drop. For dual GPU I'd want at minimum Gen 3 x8 / x8 across both slots, with x4 on slot 2 being the acceptable lower bound for bandwidth, does that sound right?

One question before I start: I'm on Windows 10 IoT Enterprise LTSC which idles at around 4–5 GB RAM. The README mentions Visual Studio 2022 with CUDA 12.8 which I already have installed. Is compiling and running on Windows a straightforward path, or would switching to Linux give a meaningful performance advantage worth the effort? Given my Windows build already sits at a low idle RAM footprint I'm leaning toward just compiling on Windows unless there's a specific reason not to. Also on the recommended -ramlimit 10 for my 16GB system, would pushing it to -ramlimit 11 be safe given my idle footprint sits consistently at 4–5GB, or is that cutting it too close and risking instability?

[pscamillo]

PCIe bandwidth:
Correct — GPU compute for Kangaroo is not bandwidth-sensitive. The GPU does billions of EC point operations internally, and only sends ~14K DPs/s (at DP=16) back to the host — negligible bandwidth. Even PCIe Gen 2 x1 would barely matter. For dual GPU, Gen 3 x8/x8 is more than enough.

Windows vs Linux:
Windows works fine — the .sln/.vcxproj files are tested with VS2022 + CUDA 12.8. Performance difference vs Linux is negligible for this workload (GPU-bound, not OS-bound). Stay on Windows if that's your comfort zone.

One thing to watch on Windows: make sure your GPU is not being used for display output while running PSCKangaroo. If possible, use the integrated GPU for display and dedicate the 5070 Ti entirely to compute. This avoids Windows' GPU scheduler stealing cycles.

ramlimit 11:
With 4-5 GB idle footprint on 16 GB total, you have ~11 GB available. -ramlimit 11 should work, but I'd recommend -ramlimit 10 for safety margin. The OS can spike RAM usage during background tasks (Windows Update, antivirus scans, etc.), and if the system runs out of physical RAM it will start swapping — which kills performance and can cause instability.

Better safe than sorry for a run that will last months. The difference between 10 GB and 11 GB of TAMEs is ~6% more entries — not worth the risk.

Recommended command (Windows):

psckangaroo.exe -gpu 0 -dp 16 -range 134 ^
-pubkey 02145d2611c823a396ef6712ce0f712f09b9b4f3135e3e0aa3230fb9b6d08d1e16 ^
-start 4000000000000000000000000000000000 ^
-ramlimit 10 -concurrent 1 -checkpoint 4

Don't forget to pull v59b and rebuild before starting!

[Zreaptrix]

Thank you! I'll go with -ramlimit 10. Also, could you check my other open issue about the compile error when building on Windows? Thanks again!