Opened 3 years ago

Last modified 3 years ago

#6133 new Bug

Suspicious getMaxAtomCount() behavior

Reported by: Mingliang Owned by: jordan
Priority: High Milestone: None Set
Component: libtransmission Version: 2.92
Severity: Major Keywords: getMaxAtomCount
Cc:

Description

In peer-mgr.c, getMaxAtomCount (const tr_torrent * tor) {

return MIN (50, tor->maxConnectedPeers * 3);

}

That means a torrent's atom pool will be pruned to no more than 50 peers, which sounds odd. Before svn r13797, getMaxAtomCount() should return a value definitely >55 transmission defaults a torrent's peer limit to 50, so getMaxAtomCount() returning a value <= 50 (the latter 50 includes unreachable peers) seems to make the actual connections much fewer than (the default connected peer limit) 50.

I guess the MIN here should actually be MAX

Change History (2)

comment:1 follow-up: Changed 3 years ago by cfpp2p

ticket:2430#comment:5 Peer atom pool grows too large
https://trac.transmissionbt.com/changeset/9582/trunk/libtransmission/peer-mgr.c
r9582 Peer atom pool grows too large" --
r11265 remove jump discontinuities in getMaxAtomCount
r13798 tweak getMaxAtomCount()

comment:2 in reply to: ↑ 1 Changed 3 years ago by Mingliang

Replying to cfpp2p:

ticket:2430#comment:5 Peer atom pool grows too large
https://trac.transmissionbt.com/changeset/9582/trunk/libtransmission/peer-mgr.c
r9582 Peer atom pool grows too large" --
r11265 remove jump discontinuities in getMaxAtomCount
r13798 tweak getMaxAtomCount()

The ticket mentioned did explain the necessity of pruning the atom pool.
I agree too, but just the 'MIN' now in getMaxAtomCount() seems illogical.
As we can see, both r9582 and r11265 set the number to be something like 3-5 multiples of maxConnectedPeers, which looks not "too large" and also logical if we expect maxConnectedPeers of connections.
But the 'MIN' in r13798 actually limit the atom pool to be 50 at most, under which we are likely to achieve only 30 real connections at most (if we don't have incoming), whatever maxConnectedPeers was set by user. Say, whether we set maxConnectedPeers=50 (transmission's default value is 50) or 80, and always get less than 30, that's somewhat disappointing...
So I think that "MAX(50, tor->maxConnectedPeers*3)" was the intended behavior but not 'MIN', since atom pool size of (maxConnectedPeers*3) seems far from "too large" and logical if we actually want to achieve around maxConnectedPeers connections.

Note: See TracTickets for help on using tickets.