I should point out that there is another situation that you may be
noticing. During parallel initial block download the node performs load
balancing across the active nodes and from a reserve of any unallocated
hashes. When load is split from the channel with the most work to a
channel with no work, the latter is restarted. Otherwise we would
receive the previously-requested blocks on both channels. But this
eventually results in out of order requests to the faster peer (the one
that was empty and therefore picked up half the load of the slowest).

There is no way to fix the ordering because the preceding requests have
already been made. I believe this results in typical clients dropping
the faster channel. In other words both channels get dropped. This
starts to churn pretty heavily toward the end of the sync. From a
performance standpoint it's not a significant issue, maybe a 10% hit or
so. The peers really shouldn't drop the channel simply because blocks
are being requested out of order, but that's my best guess as to what's
happening - since the behavior is very predictable.

I haven't had a chance to track it down in Core, etc. If this is treated
as bad behavior I would issue a pull request to Core to fix it, and if
it wasn't accepted I would just leave it. If someone wants to take on
this task that would be great :).

e

On 07/27/2016 05:46 AM, Police Terror wrote:
> ok, it was master branch btw.
>
> Once resume sync is done, then things should be much better.
>
> Eric Voskuil:
>> Version?
>>
>> FYI the odds of a successful connection are about 1 in 5. This is why version3 uses batch connection when generating connections from the pool.
>>
>> It is however possible that the pool can become starved of good connections, as the connections are supplied by peers (not just at startup) and there is no DoS protection. I have found that actual problems here are rare and given other more significant necessary work I haven't prioritized making the host pool more robust. The first step is to actually manage the pool, aging connections out, requesting more when needed, falling back to seed nodes at some point. I wouldn't restart to do this as it's very disruptive and there's really no reason to do so.
>>
>> e
>>
>> -----Original Message-----
>> From: Libbitcoin [mailto:libbitcoin-bounces@lists.dyne.org] On Behalf Of Police Terror
>> Sent: Wednesday, July 27, 2016 12:55 AM
>> To: libbitcoin@???
>> Subject: Re: [Libbitcoin] Large amount of failed connections
>>
>> Police Terror:
>>> I notice there's no longer a hosts.cache file. Has it been disabled
>>> because it was getting filled with bad hosts?
>>
>> This is wrong. Of course it was created when I stopped the node.
>>
>> However the node getting stuck cycling through hosts that don't work makes initial sync difficult.
>>
>> Maybe there can be a piece of code whereby if there isn't a connection after X attempts, then it will restart the bootstrap process and clear the hosts cache. How does that sound?
>> _______________________________________________
>> Libbitcoin mailing list
>> Libbitcoin@???
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/libbitcoin
>>
> _______________________________________________
> Libbitcoin mailing list
> Libbitcoin@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/libbitcoin
>