Make sure that the count is a zero modulo the new mask before
scaling, otherwise the next time until a measure triggers
will take only 1/2 as long as accounted for. This caused
the 'min time' to be potentially off by as much as 100%.
Github-Pull: #9200
Rebased-From: e0a9cb25b0af87723d50cb8d8cffa10f1ebf7dcc
Previously the benchmark code used an integer division (%) with
a non-constant in the inner-loop. This is quite slow on many
processors, especially ones like ARM that lack a hardware divide.
Even on fairly recent x86_64 like haswell an integer division can
take something like 100 cycles-- making it comparable to the
runtime of siphash.
This change avoids the division by using bitmasking instead. This
was especially easy since the count was only increased by doubling.
This change also restarts the timing when the execution time was
very low this avoids mintimes of zero in cases where one execution
ends up below the timer resolution. It also reduces the impact of
the overhead on the final result.
The formatting of the prints is changed to not use scientific
notation make it more machine readable (in particular, gnuplot
croaks on the non-fixedpoint, and it doesn't sort correctly).
This also hoists out all the floating point divisions out of the
semi-hot path because it was easy to do so.
It might be prudent to break out the critical test into a macro
just to guarantee that it gets inlined. It might also make sense
to just save out the intermediate counts and times and get the
floating point completely out of the timing loop (because e.g.
on hardware without a fast hardware FPU like some ARM it will
still be slow enough to distort the results). I haven't done
either of these in this commit.
When a BIP152 HB-mode peer is in the least preferred position and
disconnects, they will not be by ForNode on the next loop. They
will continue to sit in that position and prevent deactivating
HB mode for peers that are still connected.
There is no reason for them to stay in the list if already gone,
so drop the first element unconditionally if there are too many.
Fixes issue #9163.
Github-Pull: #9199
Rebased-From: ca8549d2bd32f17f8b69d1edbe3f2976fba504b4
Note that this is not a major issue as, in order for the missing
lock to cause issues, you have to receive a GETBLOCKTXN message
while reindexing, adding a block header via RPC, etc, which results
in either a table rehash or an insert into the bucket which you are
currently looking at.
Github-Pull: #8995
Rebased-From: dfe79060a62c8de098e75d527d97b99c3b10de50
75ead758 turned these into crashes in the event of a handshake failure, most
notably when a peer does not offer the expected services.
There are likely other cases that these assertions will find as well.
Github-Pull: #8862
Rebased-From: 905bc68d05595f41cca36b3df83accd10c00cc48
We should learn about new peers via address messages.
An inbound peer connecting to us tells us nothing about
its ability to accept incoming connections from us, so
we shouldn't assume that we can connect to it based on
this.
The vast majority of nodes on the network do not accept
incoming connections, adding them will only slow down
the process of making a successful connection in the
future.
Nodes which have configured themselves to not announce would prefer we
not violate their privacy by announcing them in GETADDR responses.
- Ignore GETBLOCKTXN requests for unknown blocks
Don't disconnect peers, or else we leak information that could be
used for fingerprinting.
- Ignore CMPCTBLOCK messages for pruned blocks
Also ignores CMPCTBLOCK announcements that have too little work. This is to
prevent disk-exhaustion DoS.
Github-Pull: #8408
Rebased-From: 1de2a46632946990a7863020b61172232f8c5796 1d06e49834814eed45e07393dcffd7b6683311b2
We send a newly-accepted peer a 1000-entry addr message, and then only use
vAddrToSend for small messages. Deallocate vAddrToSend after it's been used for
the big message to save about 40 kB per connected inbound peer.
Optimistically test the latch bool before taking the lock.
For all IsInitialBlockDownload calls after the first to return false,
this avoids the need to lock cs_main.
An orphan whos parents were rejected is never going to connect, so there
is little utility in keeping it.
Orphans also helpfully tell us what we're missing, so go ahead and treat
it as INVed.
This prevents higher order orphans and other junk from
holding positions in the orphan map. Parents delayed
twenty minutes are more are unlikely to ever arrive.
The freed space will improve the orphan matching success rate for
other transactions.
