by Guest on 2026/02/21 11:12:55 PM
This is more of a what's going on question - tixati 3.42 64 bit on windows 11
2 drives
ssd as temp files drive
ssd as dest drive for finished files
When a lot of files are coming in (say, anything over 10) they all download quite quickly (8mb to 50mb a sec)
Once a file starts moving from the temp drive to the dest drive the transfers move at about max 1mb a sec
According to taskmanager
temp drive is read speed 1-2Mb a sec, write speed is about 0-8Mb a sec) as i'm looking at it now
dest drive is read speed 4-6Mb a sec, write speed is about 0-2Mb a sec) as i'm looking at it now
Tixati isn't set to do anything after finished tasks like rechecking, just move the files from temp to dest
The files just pile up one after another in 'moving' state
However, if i just copy a completed file from temp to dest at the same time as this, the copy takes about 2 seconds vs the 5 minutes plus for tixati to do it
Is there anything I can do at my end to improve the speed, or is it just a limitation or tixati
Looking at it in process monitor there are a lot of threads at almost 0% and 1 using a full cores capacity
Is it thrashing network and files on the same core?
Or all the uncached IO it does?
by Guest on 2026/02/24 06:57:14 AM
It's hard to tell, by the time it gets into this state theres a whole pile of 99% downloaded files waiting to finish,files are changing to completed and adding into the queue and download speed has dropped to a few Mb/s
Stopping them at this point doesn't seem to speed anything up until the number of 'moving' files have almost finished
It's like theres a choke point in the disk routines and once you go past it you just have to wait for everything to get past the bottleneck
While tixati is struggling, the drives themseleves are still totally useable and work at almost their rated speeds, internet still works as fast as usual
The only interesting things I can see are
1 tixati thread is running at 100%
Process monitor shows a lot of the IO are unbuffered writes
As an analogy it looks a lot like 10 people standing around at work while 1 person is running about trying to do 50 things at once
Like I said though, it's just a curiosity question
It'd be interresting to see if options to not use unbuffered changed anything or if theres some internal single threaded queue that everything has to go though
by Guest on 2026/02/24 08:31:17 PM
try running some diagnostic graphs and logs, like the CPU, system log, file access. it might help narrow down where the bottle neck is.
by Guest on 2026/02/25 07:43:09 AM
I asked Gemini AI and this is what it told me.
This is a classic "Tixati I/O bottleneck" scenario. What you are seeing—one core pegged at 100% while the drives barely move—is a strong indicator that Tixati is struggling with File Allocation and Sparse File handling on Windows 11.
When you copy a file manually, Windows uses a large-buffer sequential copy. When Tixati moves a file, it often tries to maintain file integrity and sparse attributes, which can lead to "synchronous I/O" where the CPU waits for the drive to acknowledge every tiny chunk of data before sending the next one.
Here is what is likely happening and how to fix it:
1. The "Sparse File" Conflict
Tixati, by default, often uses "Sparse Files" to save space for incomplete downloads. Windows 11's NTFS driver sometimes struggles when moving a large sparse file from one physical SSD to another, as it tries to "re-calculate" the empty space during the move.
The Fix:
Go to Settings > Files > Local File Maintenance.
Look for "Pre-allocate all files" and ensure it is checked.
Disable "Use Sparse Files" if it is enabled.
Note: This won't fix files currently moving, but it will prevent the "thrashing" on all new downloads.
2. Disk I/O Multi-Threading
Tixati is notoriously "single-threaded" when it comes to disk operations. If one move operation is stuck in a "Wait" state (checking a hash or waiting for a disk header), it can bottleneck the entire queue.
The Fix:
Go to Settings > Files > Disk Cache.
Increase the Disk Cache size. If you have 16GB+ of RAM, set the limit to 1024 MB or higher.
Ensure "Flush files immediately" is Unchecked. You want Windows to manage the write-back cache, not Tixati.
3. Antivirus "Double-Scanning"
When Tixati moves a file from SSD A to SSD B, Windows 11 sees this as a "New File Creation" on the destination drive. Your Antivirus (likely Windows Defender) is probably intercepting the stream to scan it in real-time. Because Tixati moves data in smaller chunks than a standard Windows Copy, the AV scanner has to "hook" into the process thousands of times per second, eating up that single CPU core.
The Fix:
Add an Exclusion in Windows Defender for both your Temp folder and your Destination folder.
Add an exclusion for the tixati.exe process itself.
4. Check "File Piece" Buffering
If you have "Piece Sequential Downloading" turned on for many files, Tixati is constantly jumping around the disk to write pieces. When the move starts, it may still be trying to "hash" the file while moving it.
The Fix:
In Settings > Transfers > Files, look for "File Move Priority." * If it’s set to "Background," try setting it to "Normal" or "High."
Summary of the "Single Core" Issue
The reason you see one core at 100% is likely Kernel Time. The CPU isn't "calculating" anything; it is stuck in a loop managing the I/O requests between the two SSDs because Tixati isn't using the Windows "CopyFileEx" API (which is what the OS uses for fast copies) but is instead reading and writing the bytes manually to ensure no data is lost.
Try this right now: Pause all active downloads for 60 seconds. Does the "Moving" speed suddenly jump up? If it does, Tixati is simply hitting a bandwidth limit in its internal I/O scheduler.
