Im using Tixati mainly to upload rare legal stuff that I think is important to share.
I use Windows 8.1 Pro 64bit, and firewalls and port forwards are 100% sure to be correct.
Chancing Tixati.exe to newer version and back makes the upload speed almost halt
with tixati above 2.12 and coming back to using 100% of available bandwidth.
Results were the same without firewall and with direct connections from internet.

I have 3 network connections, one 15/50mb landline and two 100/50mb 4G connections,
that dont allow incoming connections. And in every connection is used 100% for uploading.
I have 3-5 Tixatis running to each of those connections, because I have so many torrents
that Im sharing (about 800 per Tixati).

Every update improved Tixati up to Tixati 2.12. After that Tixati used less processor and
seemed better in every way but for the most important part, uploading speed. Those 4G
connections didnt find peers that needed parts and thus upload speed was only under 10mbs
from the 40mbs (in other words the full possible capacity) previously. And the weird thing
was that my landline speed previously was in between 13-14mbs 99% of the time, but now it
was only 6-10mbs. If I had the upload capacity, it would have been propably 100-500mbs
previously but now it didnt use even the whole 15mbs capacity.

So what has happened to Tixati? Could it be fixed or am I "doomed" to use Tixati 2.12 forever?
Isnt uploading the foundation for P2P sharing? I would love to see someday button called
"automatic optimization for maximum uploading" in tixati. Although using Tixati 2.12 with
manually configured settings resulted unbeatable uploading speeds.

One tip, Tixati should be promoted to be the solution for 3G, 4G or any other incoming blocked
connections. It would be brilliant if googling solutions for 3G, 4G or incoming blocked P2P
downloading would result Tixati in the first page.

And lastly, I hope that there would be option to save information from every downloaded
torrent/magnet, and options to make that file external and options for behavior if trying
to download already once downloaded torrent. I have to use different Tixatis for downloading
and sharing, so it would help me a lot. And anything that helps moving completed torrents to
other Tixati to share, would help me and hopefully others that have hobby to share too.

Thanks for this report.  It will definitely be looked into further, and with your help maybe we can get a fix into the next release if there is indeed a problem.

If you have a minute, I have a few quick questions that would help narrow things down.

- Can you try toggling between v2.12 and v2.16 a few times to thoroughly verify the change happened between those versions?

- In v2.16, does it improve if in Settings > Transfers > General you disable 'Auto-manage slots' for both Downloads and Uploads?

- Does it appear that this is a problem of not enough peer connections, or that the connections themselves are going slower?

- Are there differences in the 'Peer Connections' number in the upper-right frame of the Home view?  Is v2.12 typically much higher or lower than v2.16?  Are there any observable differences in the per-transfer connected peer-seed counts?

Thanks again.  We'll do some testing on this side and see if we can spot anything too.

Also, in regards to your feature request at the end of your post, I know exactly what you're wanting to do.  Right now there is an option in Settings > Transfers > Meta-Info (at the bottom) that will append a magnet link to a text file every time a new transfer is started, but unfortunately that only gets you halfway there.

The other half of the solution isn't there just yet, and I can't make any promises, but I will give this some thought.

I was puzzled with Tixati 2.16 when it came (and every version since then) so I have already done
exactly what you wanted. The problem is the number of connections. I share 800+ torrents per Tixati,
and most of those have only few seeds and peers, but because of the amount of shares, I always have
about 20 negotiations going on (in my landline that allows incoming connections), and so because I
share the same stuff over 4G it too finds lots of peers to share. In my landline I had about 500
connections, but in Tixati 2.16->2.24 I had about 60% of that. But in my 4G I normally have about
250 connections, but after Tixati 2.16->2.24 I barely had any. Checking off the automatic slot
management didnt have any effect, or too slow to clearly notice. I can check these in great detail
in the following days, if that helps?

Because uploading speed was the priority, I have changed network settings. I have huge winsock
buffers, and max TCP window size (in 4G connections happen almost only with TCP). I made
them bigger every time I had to reboot, until I found out the best settings. I have winsock
buffers Small 65k, Medium 512k, Large 2048k, and winsock window 4096k. I know those are crazy
numbers, but it hasnt effect negatively. Global Max TCP window is 2mb, but I have auto heuristic
on, and auto-tuning level experimental. Everything else is about what BoostSpeed thinks optimal,
and what current TCP-Optimizer (speedguide.net) thinks optimal. But I have every network offload
settings on, to leave everything to Realtek drivers to handle. I have played with network settings
years, and to Tixati 2.12 I pretty much had to have optimal settings, it uses so completely all of
the upload bandwidth.


In tixati I have changed these socket settings, everything else is Compatible (DEFAULT)

udp_rcvbuf_def = 1048576 // def=65536 min=4096 max=1048576
udp_sndbuf_def = 1048576 // def=16384 min=4096 max=1048576

upc_sndwnd_maxpkts = 16384 // def=510 min=10 max=16384
upc_sndwnd_maxpkts_mtu_percent = 500  // def=50 min=5 max=500
upc_rcvwnd_maxpkts = 16384 // def=510 min=10 max=16384
upc_rcvwnd_maxpkts_mtu_percent = 500  // def=50 min=5 max=500


Im pretty sure I tried default settings without improvement. I have 3 connections, and I have
3, 4, 5 running tixatis per connection/computer. And 800-1000 torrents, and about 1,5TB, per Tixati.


I wanted to inform everything I could before 'debugging' so if you want me to do tests, just tell
me what do you want me to do. Im willing to repeat my previous tests and collect exact data, if that
further helps. And Im willing to change network settings etc. outside of tixati. Anything for the cause =)

There are a few minor tweaks in v2.25 (released today) which may or may not help with this.

If not, can you try out v2.14-a1 ?

I had a close look at the changes made between 2.12 and 2.16 but haven't come up with anything solid yet, just some educated guesses.  If we can narrow it down to the exact alpha-version where this problem started, that would be very helpful.

Here are links to the alpha versions (standalone):

http://www.tixati.com/download/tixati-2.14-a1.win-64bit.zip
http://www.tixati.com/download/tixati-2.14-a2.win-64bit.zip
http://www.tixati.com/download/tixati-2.14-a3.win-64bit.zip
http://www.tixati.com/download/tixati-2.14-a4.win-64bit.zip

Thanks again.  I'm sure with your help we'll be able to figure this out before the next release.

I will test those 2.14 alphas, and the new 2.25 version.

I said it before and but I say it again with better details. I have three internet connections,
each having their own computer, and in each of those computers Im running 3-5 Tixatis, every Tixati
having their own user account to separate them. And in each Tixati Im sharing about 800 torrents,
everyone having "Constant Seeding" and "Super Seeding" on, and also everyone having "All Peers Stay Unchoked"
marked too (I know Im little "funny" :D)


And maybe I have to confess that everyone has also "Ultra High Priority" and "10x Peer Allowance".
Its remnant for the beginning, when I had only one Tixati running and I used it also to
download stuff that didnt ment to be shared like the others. Now I just cannot kick the habit
while I know it doesnt help.

I report my observations as soon as I can.

Thanks very much.

If we didn't get it for 2.25, and you try those alphas, keep an eye on the numbers in the Home view, particularly the 'Peer Connections' in the top-right frame, and 'Negotiating' in the bottom-right frame.

Im getting weird results on my 4G connection. Because I got 5 Tixatis running with that computer,
I tried my luck and runned 2.14a1, a2, a3, a4 and 2.25 all together and Im puzzled because it seems
that a2 and a3 had both about 150 connections while a1, a4 and 2.25 had only couple connections.

Because all tixatis have different torrents that they share, there are some natural differences, but
these results seem very clear. It seems like a2 and a3 are as good as 2.12, while a1, a4 and 2.25 are
as bad as every version since 2.12. In 4G connection there are no incoming connections, so upload
speed correlates with peer connections.

Im running more thorough tests with landline connection, so it will take little more time. But I
remembered one strange thing, while 2.12 had 1200 DHT connections, every version after 2.12 had only
about 700-800 DHT connections. But I'll report more after testing all of 2.14 alphas and 2.25.

I really hope your educated guess was that those a2 and a3 versions should have worked as good as 2.12.
If that result is complete mystery, tell me and I'll tests every version separately, running five copies
of the same version at the same time.

This wasn't what I was expecting.  But that's OK, we'll get this figured out one way or another...

I just had a preliminary look at the changes between a1-2 and a3-4, but didn't see anything that sticks out too much.  Between 3 and 4 there is very little that should come into play, but between 1 and 2 is a bit more complex and will take a bit longer to check out.

I'll await your results, and I'll take a closer look at the diffs tomorrow... thanks again!

Its sad that I couldnt test the total data output, not this time, because 2.12 can use pretty much the theoretical max output.
Its far better than any P2P software, or combinations of them. Whatever combination of P2P programs I used,
and while those programs has full queues and uploading as fast as they can, adding Tixati 2.12 running too raise
average upload output from about 14.4mbs -> 14.8mbs. After all my test result came down, I was little surprised
that it wasnt as clear as it is when you look upload throughput. But those 4G results that have max few connections
are most of the time not uploading at all. And landline upload is also much slower, it seems that tixati-3 in
landline, I use it only for download, dont suffer from lacking connections, but those tixatis that are only for upload
does suffer. So those average results are much better than it should be when we look upload problems.
Also I dont understand why in this test DHT connections were almost exact in every version, at least when I tried 2.16
(and some other after that) I got only 800 DHT connections in every tixati in landline. And Im wondering did I mark my
running minutes incorrect in landline tixati v2.12 test, but maybe it dont record all received and placed connections,
because it uses all bandwidth for uploading..


Landline (ethernet 1gbs connection, 15/100mb throughput) Has 3 Tixatis running.
Tixati-1 has 900 seeds, 0 downloads
Tixati-2 has 0 seeds, 1300 downloads (most are dead most of the time)
Tixati-3 has 900 seeds, 0 downloads (seeds are newer than Tixati-1's)
Every Tixati has exactly the same configuration (ports ofcourse are unique) Some versions got tested longer,
and it gave them little better results,  because advertising those 900 seeds take a long time, but I think this
will give enough info.

** Because this doesnt support tabulators, I posted the results to pastebin **
** http://pastebin.com/9Z60tLCf  **

** And the 4G results in the end are in pastebin also **
** http://pastebin.com/SiQHSCsE  **

-------------------------------------------------------------------
Version2.122.14a12.14a22.14a32.14a42.25
-------------------------------------------------------------------
Tixati-1
Connections 1572334381833764
     DHT 118712091164116712201198
   Received 449090518100193514177193205722113346
     Placed 33643540250015305013536516634072147
-------------------------------------------------------------------
Tixati-2
Connections  1785933166910431504940
     DHT 11611157113910941188939
   Received 24330821462682687796669555880442
     Placed 408714390416365138851988527481
-------------------------------------------------------------------
Tixati-3
Connections 1562193841604374
      DHT 115811951198116612161156
   Received 361000405776168491143940176560104221
     Placed 25923230121012623610451914248762271
-------------------------------------------------------------------
Avg Connect 699462830462528359
    Avg DHT 116911871167112512081098
Avg Received 35113337950114823113360015928099336
 Avg Placed 212179249205985508459010957053966
-------------------------------------------------------------------
Runtime mins11931075388452521415
Received/min294353382296306239
 Placed/min178232254187210130
-------------------------------------------------------------------


4G Connection (about 30/50mbs) Has 5 Tixatis. Everyone has 800 to 1000 seeds and no downloads.
Tixati-1 has the oldest seeds, and Tixati-5 the newest.
Every Tixati has exactly the same configuration (ports ofcourse are unique)
Some versions got tested longer, and it may have some effect. Also the time of the day has effect on
4G connections throughput, but it shouldnt have big effect on connections. 4G is incoming blocked,
so Received/placed is irrelevant, but I collected DHT connections because I was curious about it.
These results seem too good for 2.14 alphas 1-3, because when I checked total
output, it was not as good as 2.12. But it could be that 4G was had too many
users at the time. Most of the time it allows for max upload though.

-------------------------------------------------------------------
Version2.122.14a12.14a22.14a32.14a42.25
-------------------------------------------------------------------
Tixati-1
Connections855414610610
     DHT168153162164158151
-------------------------------------------------------------------
Tixati-2
Connections882025618941
     DHT 170156171161144167
-------------------------------------------------------------------
Tixati-3
Connections9918011715712
     DHT168156168159157168
-------------------------------------------------------------------
Tixati-4
Connections13311711818901
     DHT174158174173181179
-------------------------------------------------------------------
Tixati-5
Connections8854647822
     DHT167155173163163164
-------------------------------------------------------------------
Avg Connect9912110014421
    Avg DHT 169156170164160166
-------------------------------------------------------------------

If you need further tests, let me know. This was little disappointing
because I thought that I would get clear results. But I hope that you
say that those 2.14 alphas should be as good as they are, and that I
just didnt look enough for the upload speeds =) I may have to do one
day upload amount comparison between 2.12 and 2.14a3 to know for sure.

Just wanted to let you know that it's 3:30 AM and I read all of this because I don't want to go to sleep yet and I'm hooked on this mystery novel.
I hope it gets resolved.
Cheers!

Im happy if you^^ think its mystery novel (and not a comedy).

Im willing to continue testing, and Im looking occasionally this thread if there would be new
things to test. And if my previous results gave any insight, it also would be nice to know.

Anyway, keep developing and if possible or appropriate, advertise Tixati for its capabilities
over 3G/4G and incoming blocked networks. Well, at least after you have figured out the problem =)

Still doing some tests and code-examination to figure this one out.  Stay tuned...

I did speed tests using Tixati 2.25 and other BitTorrent clients.
Results here:
http://forum.tixati.com/support/1833/

*Tixati v2.2.5 -- 55 MB/sec peak and sustained 30 MB/sec. ( maxes out a CPU core -- 25% of CPU's max as it has 4 virtual cores)

In the original poster's provided data, it seems the big difference is alpha-3 to alpha-4.

This makes perfect sense.  The only difference between these versions is the addition of the Queue Management feature.  So clearly that is what is having this effect on the number of connections.

When both the seeder and the downloader can't take incoming connections, they can still connect, but it takes some time for this to happen, because they both basically must be connecting outward toward each other at the same time (connection attempts create a temporary return-path mapping in your router's NAT table, so the other side's attempt then makes it through.)

So in this situation, where the is a ton of seeds and incoming connections can't make it in, the automatic rotation will put seeds back into standby before the timing aligns and a connection has a chance to make it in.

The solution would be to go into Settings > Transfers > General, and in the Queuing frame, turn off both "Auto-manage slots".  This effectively makes alpha 3 == alpha 4.  Or you could try clicking the details button next to those settings and tweak it out a bit, relax the timings.

Also v2.26 has a few optimizations that may help a bit when mega-seeding.

And v2.28 is going to have yet a few more minor tweaks (should be ready in a few weeks).

I will have to check out that. I think I turned off that feature to test if it was the cause, because it was the obvious possible cause.
But does that explain why 2.12 is still clearly the fastest uploader in 100% open connection too? If it is fixable with queue settings,
it would be great if there would be "maximum upload" preset in the future version =)

I will check out again what disabling auto queue do. I did check 2.26 couple of days ago, and it was the same as 2.16+ versions.
Well, faster downloader leaner and better in every way but uploading.

I will report what happens with disabling Auto slot management and after tweaking queue settings.

Turning off Auto Queue Management didnt have any effect that I could see.
It just seems to me, that it is not just Queue management that is slowing uploads,
I mean it seems like something else has changed in the "making of auto queue management."

2.12 uses much much more CPU and it seems like it is cruching as many packets as any way
possible, but versions since 2.12 seem like gentlemans that dont rush and only send packets
that clearly has bandwidth. Total throughput is higher with 2.12 even when there are plenty
enough connections and clients to upload with 2.27. And Im talking about 100% open ethernet
now. 2.12 has been the best uploading software in my 13 year P2P history, no combination
of any software has uploaded so fast. Because of that 2.27 seems so "slow" although its
almost as fast as most P2P softwares when they use 100% of bandwidth.

I have not yet had time to tweak those queue management settings. I hope that it prooves to
be the cure, but as I said above, it feels like something has been changed when that new
queue management was implemented. If Im wrong, I would appreciate if you would prove me
wrong. That would give me energy to tackle that queue management settings to find out
which would give the best results.

how many torrents are you seeding?

Good news!  I found the problem.

The fix is complete and will be included in v2.28, which will be out in a matter of days if all goes well.

Give it a try, let me know how it goes.

BUGMAGNET, I started this thread, so you can have all the info in the beginning if needed.

KH, Im very very happy if you did find the problem because these newer versions have
so many great improvements. I will report the results after next release =)