(I'm going to assume a faster machine as well, because I'm running BiglyBT on a 2-core Athlon 64 box from like 2007.) Which is why I was hoping the options changes would at least improve the lag stats. Now, you have much higher activity levels in BiglyBT than I do, but you also have a much better connection. On my system, no lag ever seems to register there under any circumstances. In your previous screenshot, it showed quite a bit of lag on Scrape attempts. What do the Tracker graphs look like, with the updated settings? That's the trigger for that message, ultimately: The lines on the lower-left "Update Lag" graph rising too high. The message probably needs to be changed, the assumption that lag issues are caused by a lack of concurrency is clearly incorrect. So the system is still asking me to increase the concurrency. Though I am currently far from using my 500/500 Fibre to a high load. My goal with my system is to Seed as much as possible as fast as possible. And at 128 I still have it higher than the 25 you suggested. And you can see the Distributed Database show 462k users. The Network Meter has higher numbers as it shows Overhead and other traffic. Reported in both the program, and on my Network Meter gadget.
![vuze does not update trackers vuze does not update trackers](https://mac-cdn.softpedia.com/screenshots/Reflex-Epic_13.png)
And the fun part is I have 500/500 Fibre, and using a program that can download video from various sites, that I just got. So now upload performance has dropped and has a range is 20 Mbit/s - 70 Mbit/s. Those trackers are showing as Error: Offline (No data received) or Error: Failed (Connection timed out: connect).
![vuze does not update trackers vuze does not update trackers](https://mac-cdn.softpedia.com/screenshots/Instamac_1.jpg)
In the last few months, in spite of new torrents on RARBG containing usually only their own Trackers. I have seen BiglyBT reach upload speeds over 250 Mbit/s upload, though more typical is 120-160 Mbit/s.
![vuze does not update trackers vuze does not update trackers](http://www.tuttologia.com/forumtutor/ZZ48FB4591.jpg)
Oh and give you an idea of how much I am seeding and queue settings: But it still tells me to increase the concurrency. Notice I didn't go all the way down to 25, I used 128, down from the 1024 before. Tried the numbers you suggested, here is what it looks like: (Along with not scraping inactive torrents.) My stats graphs always look about like Ok, I am getting this again. Personally, I use 15 seconds for the connect timeout, 35s for the read timeout, and a concurrency of 25. Short timeouts ensure that busy trackers or ones that are having network connectivity issues can be treated the same as offline trackers, and passed over in favor of more responsive ones. The whole point of having multiple trackers for each torrent is that connecting to any one of them is unimportant - there's always the next one on the list. I'd probably drop that way, way down - if a tracker isn't able to respond to a connection attempt within a few seconds, even if the connection would eventually succeed, it's probably so overloaded (or having other issues) that you're better off just bailing on it and moving to the next one in the list. With that kind of window, every attempt to contact an unresponsive tracker is going to potentially delay a subsequent connection to a working tracker by up to 120 seconds.
![vuze does not update trackers vuze does not update trackers](https://news-cdn.softpedia.com/images/news2/Vuze-Updated-with-New-Features-on-Mac-Windows-Linux-409412-2.jpg)
"Manage tracker activation to reduce load" could also possibly help (though I don't know if that will affect scraping at all).Īlso possibly related: Two minutes is an incredibly long connect timeout. If you have a significant number of inactive torrents (and it seems you do, specifically all of the torrents in various "Queued" states), there's not a lot of value to scraping them all. I'd probably start with turning off "Scrape torrents that aren't running", personally.