Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Henry63

Pages: [1] 2 3
Generic / Re: Does DHT expose my real IP in anonymous mode?
« on: October 14, 2018, 05:16:26 PM »
You're at least partially expose. As soon as you're UDP makes a connection, the other side knows you're IP because that's how else could the other side respond.

Windows / Re: Many I/O errors, why?
« on: August 06, 2018, 03:31:05 AM »
Out of the box, I don't think Windows supports path names longer than 256 chars. If the mapped drive is pointing to a path on a remote machine where the remote machine would attempt to create a path longer than 256 chars, it'll probably fail.

Windows / Re: Other torrents drop out when a fast seeding torrent is added.
« on: February 22, 2018, 01:22:29 AM »
Seems I set the global speed limit to 3/8ths, then I unchecked uTP from the limit. I'm still using 3.3.16

Windows / Re: Sudden slow upload speed
« on: February 20, 2018, 11:55:55 PM »
My question is if it is within reason. I seed hundreds of popular linux ISOs on a dedicated fiber connection with SSDs and sometimes I see the upload drop as low as 30KiB/s for hours at a time. The monthly average is a pretty constant 15Mb/s, but at any given time it can be anywhere from 30KiB/s to 15MiB/s

Windows / Re: Other torrents drop out when a fast seeding torrent is added.
« on: February 20, 2018, 09:54:08 PM »
Some Linux seeders have horrendous bufferbloat and TCP will effectively DOS you with resends. I used wireshark to figure out why I was seeing high packet loss while downloading come Linux torrents myself. Turned out that some subset of the seeders had latencies up in 3,000ms rang. TCP assumed the packets were lost, but really they were just greatly delayed. Most TCP stacks do not rate limit resends. Nearly 50% of all of the packets I was recieving where duplicates.

My work around was to limit TCP transfer to 3/8th of my bandwidth. Even if 50% of the packets are dups, that would only be 6/8ths. uTP does not have this issue as it is latency sensitive.

See if limiting TCP downloads in the settings works for you.

Windows / Re: qBT 3.0.10 >500MB cache size can trigger crash + hashfails
« on: November 23, 2017, 02:34:37 AM »
I noticed when I went from mech drive to SSDs that having a large cache set in qBittorrent made it run slower and use more CPU. A possibility is the high CPU usage you're seeing may be related to a large cache.

As for the 5GiB vs 4GiB, that's total memory vs cached data. There's a lot more to allocating memory than just the data you want. There's alignments, pools, data-structure overhead, and other things that may be in addition to the 4GiB.

Windows / Re: Qbittorrent Pre-Allocate Writing Zeros
« on: November 22, 2017, 02:02:24 PM »
Writing zeros also wears out SSDs faster. It's better to just use the file system's ability to pre-allocate than to write data, then over-write it.

Windows - QA Department / Re: Unofficial 64-bit installer/archive 3.3.x
« on: October 29, 2016, 12:27:42 AM »
[...] can waste over 1 GB ram (using >5.5 GB total) if its cache grows large enough.

Which version was that ?

3.3.7 64bit can't go over 1.9gb.

With 3.3.6 and the versions before that I tested, I can set the cache to 4096MiB it will happily gobble up 6GiB of my memory. I have recently gotten another internet upgrade and with even a 600s cache, the hit-rate was not high enough to saturate my connection. I had to switch to using my SSDs.

I actually found that qBittorrent gets very slow as the cache gets larger. A 2x larger cache may take 10x longer before it can close. At 4GiB of data cached, it takes nearly 10 minutes for it to free up the memory, then close. With SSDs, I have limited it to 512MiB of cache and it closes instantly.

Windows - QA Department / Re: Unofficial 64-bit installer/archive 3.3.x
« on: August 15, 2016, 04:14:27 AM »
24 hours and 235GiB uploaded later, seems to be working fine with 3.3.6 w/ Lib 1.0
Update: 48 hours and 460GiB later

Windows - QA Department / Re: Unofficial 64-bit installer/archive 3.3.x
« on: August 13, 2016, 07:54:54 PM »
Yes to both seeding and OS Cache disabled. I have the Read cache set to 4096MiB and 600s, which is the max for both.

On this topic, how difficult would it be to increase the max cache size? Seeding has been pretty high today, hanging around 5-6MiB/s. I think I'll install 3.3.6x64 Lib 1.0 and see how it goes.

edit: Looks like I was using 3.3.5 lib 1.1   "use at your own risk". That may have been the issue. Not sure. But we'll see how 3.3.6 lib 1.0 does.

It's been faulting once per day every day. Like I said, It seems to run for a certain amount of time then crash for the exact same reason. In case it helps, I average about 8Mb/s upload 24/7.

qBittorrent runs for a good 18 or so hours, then crashes. It just happened again this morning.

Came home to find qBittorrent not running and this in my event log

Faulting application name: qbittorrent.exe, version:, time stamp: 0x5778185b
Faulting module name: ntdll.dll, version: 10.0.10586.306, time stamp: 0x571af2eb
Exception code: 0xc0000374
Fault offset: 0x00000000000ee6fc
Faulting process id: 0x16f9c
Faulting application start time: 0x01d1d6b8d6ab5929
Faulting application path: C:\Program Files\qBittorrent (x64 Edition)\qbittorrent.exe
Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll

SFC /scannow  showed no issues. This is the first time I've seen any program crash since I built my computer 1.5 years ago. I hope I don't have any memory issues.

Suggestions / Re: Disable TCP downloads or Uploads independantly
« on: April 23, 2016, 01:25:49 AM »
Seems that also hurt my ability to seed. Some people have some old clients.

Suggestions / Re: Disable TCP downloads or Uploads independantly
« on: April 22, 2016, 03:37:58 AM »
don't negotiate uBT

What is uBT?

Morning post. Caffeine hadn't kicked in yet. uTP

Pages: [1] 2 3