Windows 11, Tixati 3.42, downloading a large torrent (353 GB) directly to an external USB hard drive.

My internet connection delivers ~25 MB/s, which is more than the drive's sustained write speed. What happens:

1. The disk write queue backs up, Windows reports the drive at 100%+ active time.
2. Tixati has no back-pressure mechanism - it keeps downloading at full speed as if nothing is wrong.
3. Eventually the download speed collapses and Tixati locks up completely: UI frozen, the process cannot be closed normally and has to be killed from Task Manager. On one occasion a write was stuck so hard in the kernel I had to physically unplug the drive to clear it.
4. After killing the process, a force re-check of 353 GB is required, which takes many hours on a slow drive.

Workarounds I'm using now: manual download speed limit set below the drive's write speed, and incomplete piece storage moved to an internal SSD. This helps, but a manual global limit is a poor tool - it wastes bandwidth when the disk keeps up and doesn't protect when it doesn't.

Request: Tixati should monitor its own disk write queue/latency and automatically throttle incoming data when the storage device can't keep up (similar to the "Disk overloaded" handling in other clients), instead of pushing until the I/O thread wedges and the whole client has to be killed.

Try updating to the newest release, v3.44 and see if you still have these problems. The v3.43 release was a major update and many things were fixed and improved.

You can set torrent-specific bandwidth limit that is low enough for the drive. It is always applied, no matter what other, general limits are.

Of course, you might say that you need to download 5 or 10 torrents at once to that drive, and have its write performance balanced automatically between all of them. Than we might say that you live a strange life. But who doesn't?

Maybe you will not need to limit your download speed if you enable write cache for that disk as shown here:  
https://www.youtube.com/watch?v=1kSXOYXexMI&t=16s  
Make sure to choose the right disk.  
For the change to take effect, you will have to close Tixati and unplug the disk, or just reboot the computer.

I face the same issue also, even with write cache enabled it occurs sometimes (not that common tho), it's hard to cap 1gbps with Tixati for several reasons, this being one of them, I never delved much into this issue, but I'll see if I can come up with something.

My setting is the following:
Standalone Tix (around 1000 transfers) in (NVME) WD Blue SN570 1TB | Downloads to (HDD) ST4000VN006-3CW104

Tixati v3.44 Standalone
Windows 10 Enterprise LTSC
Version 21H2
OS Build 19044.7548

Ohhhhh I wonder if this is what was happening to me.  I'm also on v3.42.  I recently upgraded my home internet to 2GB with unlimited data and am getting downloads a LOT faster and I'm downloading a crap ton more than I was before and am also writing to an external USB drive.  My laptop kept hanging and crashing but would recover without rebooting.  I thought it was my external drive that was the issue so I built a VM on my NAS to offload the duty to and that has generated another thread on this forum about move on complete.  On that VM I'm running 3.44.  I'll try updating the version on my laptop and see if that solves the hanging crashing behavior.  The VM doesn't experience that behavior, but has another issue with move on complete.

Ok, after some changes and testing, I guess it's one of those cases where Tixati's complexity becomes a problem.
Changed download location from the HDD to an SSD and messed a bit with the Piece Creation Limiter:
Stop piece create on same-download count above              1500
Stop piece create on same-download MB above                 5000
Stop piece create on same-download pending save count above 450
Stop piece create on same-download pending save MB above    400
Stop piece create on global count above                     60000
Stop piece create on global MB above                        8000
Stop piece create on global pending save count above        2000
Stop piece create on global pending save MB above           4000

This works for my specs and bandwidth, around 96MiB/s peaks, no lock-ups, and piece dumping from RAM is very fluid, may not apply to every case.

Reduced Stop piece create on same-download pending save count above from 450 to 150

Tixati Initial RAM usage 2.3GB
Tixati Highest RAM usage 3.1GB
Peaks 98MiB/s 93MiB/s 97MiB/s 99MiB/s 90MiB/s 85MiB/s

CPU: Ryzen 9 5900XT @ 4.2Ghz
RAM: G.Skill 32GB (16x2) Aegis DDR4 3200MTS (F4-3200C16D-32GIS)
Storage: WD Blue SN570 1TB (NVME/Tixati)
Storage: Crucial MX100 256GB (SSD/Downloads)
Storage: Seagate IronWolf 4TB (HDD/Downloads moved to when finished)

added in list of unresolved issues https://forum.tixati.com/support/8374

the difficult methods by zarkbit should not have to be done. there needs to be a single setting