Libtorrent 2.0.9

[Paralel]

Has anyone tested this with Deluge 2.1.1? Better, worse, the same? Still needs to be reigned in to stop it from eating every bit of memory it can? Still randomly causing an artificial limit on download speed for some people?

[ambipro]

The memory issue is probably going to be an ongoing issue for a long time in 2.x libtorrent, it's part of it now (memory mapped files that are downloading)...whether they incorporate a way to limit its run away effect anytime soon is something only the dev's know. For Windows, check the plugins forum for wslimit (mhertz wrote it at my request before i switched to unraid linux), there are a few linux tips there too if i recall.

As far as dl performance, I've not noticed any changes, but I've been consistently maxing my connection speed for years anyway. Sorry I can't help you on that front.

[Paralel]

Ok, sounds about status quo then. I always like to check since weird bugs show up every so often. I was hoping the devs had prioritized a solution to the memory mapped situation, but I think its one of those "Wish in one hand..." situations. Fortunately for all of us Windows people mhertz solved the issue with his plugin, so it isn't a serious issue, but it would be nice if they resolved it. Thanks for the reply.

[ambipro]

I actually think they view it as an improvement (memory-mapped files) and intended behavior...in theory. It should allocate memory to applications and background processes ahead of the libtorrent allocation for downloading files (this is the only time it uses this large amount of memory from my experience). My reading, and mhertz seemed to echo this when we spoke about it at length prior to working together on the plugin, he didn't think they intended to change it much.

Perhaps they'll add some limitations on memory usage, but as I said it's not supposed to prevent the memory from being used by other applications if the OS requests it from what I understand.

[Paralel]

I actually think they view it as an improvement (memory-mapped files) and intended behavior...in theory. It should allocate memory to applications and background processes ahead of the libtorrent allocation for downloading files (this is the only time it uses this large amount of memory from my experience). My reading, and mhertz seemed to echo this when we spoke about it at length prior to working together on the plugin, he didn't think they intended to change it much.

Perhaps they'll add some limitations on memory usage, but as I said it's not supposed to prevent the memory from being used by other applications if the OS requests it from what I understand.

The problem with the way it is implemented is that the memory mapped allocation was created with Linux memory management in mind. Linux has no problem overcommitting to a memory allocation request, whereas Windows does not allow overcommitment. As such, with a large enough torrent, or enough individual torrents involved, it will actually ask for more memory, real or virtual, than Windows is capable of committing, As a result Windows will throw an Out_Of_Memory blue screen as it exceeds memory management capabilities. People have actually been able to show they have run into it (although we aren't exactly talking about the typical end user). In Linux people have demonstrated the current libtorrent asking for a memory allocation of several hundred gigs (which, again, isn't likely for the average user), which for Linux isn't a problem, but for the average Windows system, this behavior isn't reasonable, let alone possible for most people since they are unlikely to even have that much free space on the drive designated for their swap file. So, the discussion is how to make memory mapped allocation continue to work as is for Linux, while preventing a possible OOM scenario in Windows given the difference in memory management between Linux and Windows, all without causing a negative impact on performance or other issues. That seems to be where the current discussion is stuck.

As far as how it is working with 2.1.1, the results for me so far have been excellent. I am seeing a considerable improvement over previous 2.0.x versions.

[greg2step]

Is there a link where to download 2.09 as PYD file already compiled? Previous threads have links for previous versions.

Thanks in advance

[mhertz]

Here's 2.0.9 and 1.2.19, in x64 and x32: libtorrent-windows (Prebuilt versions from pypi website, just extracted and renamed - same source used by official releases, though in hindsight should have just posted links to pypi, as not good downloading stuff from others if can be avoided - virustotal-report with sha-256 file-checksums etc)

About your other thread, I just wanted to quickly say that i'm gonna update the outdated high-performance seed preset in ltconfig and post a build in it's forum-thread, but just have been to lazy to do it, but will one of these days(Edit: Done). None of your three fields posted are changed though. Sorry have no info on how performance/limits are on windows, or tweaking advice really.

[greg2step]

Thanks @mhertz for the links. I swapped it in place of 2.08 and no issues, perhaps seeing higher speeds, but I can't tell for sure. certainly no downside I can see.

I am going to be adding RAM to my system, hoping to adjust settings between wslimit and ltconfig to get deluge to use more cleanly

Thanks

Greg

[mhertz]

You're welcome buddy, good to hear and thanks for posting back