Think about tuning the script cache/sigcache ratios #10754

1. 
   TheBlueMatt commented at 4:57 pm on July 6, 2017: contributor

   After #10192, we have two separate caches, which are in memory blocks of equal size. This is likely not the best possible tuning, but sadly its tricky to get right because the sigcache is now used more as a DoS protection/reorg speedup and less as a cache used in normal operation. See-also, @JeremyRubin’s suggestion of using the same table and further discussion at, eg, #10192 (comment).
2. 
   gmaxwell commented at 4:47 am on July 9, 2017: contributor

   I am astonished that as many random memory access as we’re making for these things is actually well tuned. I’d really like to understand how 8 way fanout is optimal, if it is, since that amount of memory latency should significantly slower than e.g. four way fanout into buckets of two esp with caches much larger than L3. Reports were that it wasn’t which suggests to me that something is wrong, either in our implementation or in my understanding of the hardware, maybe our hash function is too slow and thats obscuring it.

   Another thing to look at is tuning the eviction/epoch counter part.

3. 
   JeremyRubin commented at 5:18 am on July 9, 2017: contributor

   Greg I think your understanding is deficient, the actual expected number of probes should be a lot closer to 1 for signatures that exist. This is because a recently inserted transaction should be close to it’s first hash-index and a recently inserted transaction is more likely to be mined.

   If you want to simulate the worst case you should write a benchmark that tests the cache with a block that has all previously unseen signatures/transactions.

4. fanquake added the label Brainstorming on Sep 6, 2018
5. fanquake added the label Resource usage on Sep 6, 2018

Contributors
TheBlueMatt gmaxwell JeremyRubin

Labels
Brainstorming Resource usage