I observed a weird effect since long time, but now tested for it back and forth:
- Tixati may show upload rates of e.g. 10+ MBit/sec when minimized (checked via Win10 Task-Manager
- in the moment the Tixati window is no longer minimized, the upload rate drops by 80-90%
- minimizing Tixati let the rate climb again to the old level.
The PC has 8 cores, tons of memory and no know bottlenecks.
Any ideas ?
TXs and cheers
Michael

what version of tixati?

what tab is tixati on when you un-minimize the program?

does the drop vary with different tabs up? like the home tab or the bandwidth tab ...

do you have any tixati diagnostic windows running?

what version of tixati? 2.58

what tab is tixati on when you un-minimize the program? Transfer

does the drop vary with different tabs up? like the home tab or the bandwidth tab ... Just tried again:
Transfer Tab: DROP
Home Tab: climb up again
Channels: DROP
Home Tab: climb up again
Bandwidth: stays high
DHT: stays high
IP Filter: stays high
Scheduler: stays high
Settings: stalling 10 secs, drop to zero, slow recovery

do you have any tixati diagnostic windows running? not that I am aware of

Hope this helps - seems to be an issue of the Transfer and Channels tabs

Good luck an kind regards
Michael

on the transfers tab, what tab is displayed at the bottom? does it make any difference in the drop?

does it make any difference if a torrent is selected or nothing is selected?

do you have any peer properties windows open?

do you have logging turned up?

how many torrents do you have in the program? running and total.

how many channels are running?

what tab is displayed at the bottom of the chat window? does it make any difference in the drop?

does it make any difference if a channel is selected or nothing is selected?

on the transfers tab, what tab is displayed at the bottom? does it make any difference in the drop?
ANY bottom tab triggers the DROP


does it make any difference if a torrent is selected or nothing is selected?
Nothing selected: no difference - DROP


do you have any peer properties windows open?
No


do you have logging turned up?
You mean "Event logging" settings ? Then switching them off completely, all of them, does not change the effect: DROP


how many torrents do you have in the program? running and total.
About 30 in total; typically about 5 show some activity, the others have zero transfer


how many channels are running?
3 channels have a green line


what tab is displayed at the bottom of the chat window? does it make any difference in the drop?
I have not used channels and chat for months, just tried, no difference - DROP


does it make any difference if a channel is selected or nothing is selected?
No

try running the cpu usage diagnostic graph.
help->Diagnostics->CPU Usage->All

once stable, make the drop happen and see what the graph displays.

then run whatever graph is affected most to narrow it down.

The UI part is dominating the graphs when the problematic Tixati tabs are visible.
But how on earth can UI overhead kill network throughput ??
The PC has 6 cores idle, as well as GBS of physical memory.
Smells like UI and transport core are not properly decoupled on programming level, right ?
TXs and cheers
Michael

i assume you mean the GUI and not the WebUI.

if you run the GUI detail chart what is affected most?

from the all graph what exactly drops?

if you run that detail chart, what is affected most?

Blue and yellow lines change synchronously with visible versus minimized, in the lower pane.
In the upper pane, the blue one fits nicely visible versus minimized, while the yellow one is more like random all the time.
All other colors are rounding error.
Good luck!

Any idea how you will fix this ?

Any activity to fix this ?

mbe -> did you upgrade to version 2.59?

if it is still happening do what KH said on another thread:

Well done, massive improvement - for sure this is no longer a meltdown as before! There might be a 40% penalty, but given the natural fluctuations, that may be "noise". I would need to test with a hugh transfer in LAN to verify, but no my priority now. I like the new version. Thank you.

The problem is back - on Windows (not on Linux). Having GBs to do, in LAN via GB network (see my other recent post - the overall throughput is tiny, even when UI of the host part is hidden), the total "out" drops below 700k/s when the UI is visible.
I have a screenshot available as requested:
(pic removed by Mod and sent to Devs--please repost the pic with file names and IPs blurred)

Good luck in fixing ...
TXs and cheers
Michael

OK, here's the link to the blurred version of the screenshot: https://www.dropbox.com/s/ebkjnluyk2lxcya/2020-07-13%2008_34_06-Tixati-GUI-CPU-bl.jpg?dl=0
All data shown in the original is not sensitive, BTW: the files are all public domain, and the IP addresses were either local of have very soon been changed by a router rebbot triggered by firmware update. But I understand the policy in general ...
Thank you.

Anybody has any idea how to fix this ??

I meanwhile tried rtorrent which delivers TEN times the throughput than Tixati - same network, same PCs.
Funny enough this applies to Tixati source -> rtorrent target, as well as rtorrent -> rtorrent.
Serious advice to the Tixati devs: keep UI operations SLIM, i.e. at a minimum any UI updates need reasonable intervals. I sense you update once per second. Crazy overhead. And I would assume that such performance impact ignoring philosophy hits in many more places you would know better than I can.

Well done - upload dropping seems history - thank you!