Im using centos5.1. I have alot of programs that use mmap and this is the first i've heard of an mmap bug in gcc 4.1.2-14 and its libraries.
On Jan 3, 2008 5:06 PM, Jonathan Dugan <[EMAIL PROTECTED]> wrote: > > > another data point: > > > 48 torrents, seeding 65GB, between 15-40 peers total: > > >>free > total used free shared buffers cached > Mem: 2076448 2024368 52080 0 22188 1813260 > -/+ buffers/cache: 188920 1887528 > Swap: 1614492 68 1614424 > > 2G total, 190M used total for the machine > > > top for this process: > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 4272 dugan 16 0 48612 38m 6.4m D 90 1.9 48:55.92 rtorrent > > > Running on Debian Etch with older version: "Rakshasa's BitTorrent client > version 0.6.4." > > > Regards, > Jonathan > > -- > > Jonathan Dugan, PhD > Matson Systems, Inc. > (650) 799-5369 > http://www.matsonsystems.com > > > > > On Wed, Jan 02, 2008 at 07:58:36PM -0500, In Incognito wrote: > > The memory issue im talking about is > > http://libtorrent.rakshasa.no/ticket/641. > > > > Most of my torrents have 2mb - 4mb piece sizes. And from watching > rtorrent > > it uses 3xPiece size for EVERY peer. This apparently does not change > even if > > you are just seeding. I have been playing around with max_memory_usage > and > > each peer in seed mode uses 3x the piece size. > > > > This is an absurd way of using memory. Most people connect to around 50 > > peers. Assuming there is absolutely nothing else loaded then ONE torrent > > needs 300mb. ONE. > > > > Now if piece sizes are 4mb, and alot of torrents are, then you even more > > memory for ONE torrent. > > > > Max_memory_usage is not a solution because the same structure is being > used. > > In fact without any sort of peer selection speeds suffer tremendously. > Im > > not sure why this hasn't been addressed. Since the last release there > have > > been nothing but petty changes and the addition of someone else's DHT > patch. > > > _______________________________________________ > > Libtorrent-devel mailing list > > Libtorrent-devel@rakshasa.no > > http://rakshasa.no/mailman/listinfo/libtorrent-devel > >
_______________________________________________ Libtorrent-devel mailing list Libtorrent-devel@rakshasa.no http://rakshasa.no/mailman/listinfo/libtorrent-devel
