For me, it was what appears to be a bug in Tixati. and fopnu... at least in the BW reporting and limiting.

From a location with only 1 Mb/s (125 kB/s) ISP level on an ASDL line...

I set both tixati and fopnu to use max 48 KB/s UL BW each. neither fopnu nor tixati seem to honor that limit.

If they both did, together they would use 96 KB/s max, well under the 125 KB/s ISP service level.

I discovered that both actually uses significantly more than the BW limit and chart indicate, about 30% more for tixati and wildly more for fopnu at minimum UL BW setting of 1 KB/s.

When I set the fopnu limit to the absolute minimum of 1 KB/s, It is not reflected on the chart and Resource Monitor indicated it was actually using ~28 KB/s. Another thing, fopnu does not distinguish channel BW from transfer BW the way tixati does. It appears the fopnu BW limit only affects Transfers and channel traffic is not included or regulated. Could that be?

Perhaps they are only measuring and limiting actual packet payload and not any overhead? I don't know.

For weeks, really months on end, I would experience intermittent streams of channel disconnects and reconnects. Now it appears that will end.

My workaround is to set tixati UL BW limit to 38 KB/s. With that, I observe via Windows Resource Monitor that tixati is actually using 46-48 KB/s, which was my target. And I'll set fopnu limit to 32-48 KB/s and watch the effect when i get sufficient demand for downloads.

The other thought is, why is fopnu so sensitive to BW starvation? Can it be tweaked to adjust to less than optimal BW availability?

I don't think bandwidth is the root problem causing connection dropouts. i think the issue is more the mesh network making up the fopnu connection and chat network.
Its my opinion that since alot of the protocol relies on sending data back ant forth between connected peers across the network if there is a minor disruption the program may not but should try again or wait longer to get the data packet its waiting for. instead the connection fails and reconnects. maybe something the Devs could look into is adding delays and retries into the protocol so make it a bit more stable.
I have seen some users that have it bad and i experience it also, and i have a very stable and fast connection and many other connection dependent programs running constantly without dropouts.

Fopnu does seem to be quite sensitive, perhaps too much, to network variables.

After I reduced tixati's UPload BW limit to 38 KB/s I was good. Until today.

Normally I do not download much. But cleared some disk space (deduplication) and started a couple big torrents. I was away much of the day so did not notice. With these well seeded torrents, I was downloading quite fast for my ISP service level (12/1). But that calls for more outgoing BW to keep the incoming packets flowing.

Result was I found my fopnu client disconnecting from all channels very frequently. I lowered the Incoming and outgoing BW limits in tixati and my fopnu channel connectivity stabilize.

Next, I turned off the incoming limit on tixati, and started with a very low outgoing limit, 24 KB/s then incremented it by 8 KB/s up to 120 KB/s.  Channels became unstable long before I got to the 120 KB/s limit and it actually didn't get there, maxing out at about 90 KB/s, saturating the ISP limit.

Channel connections became very unstable when I raised the tixati out limit past 40 KB/s

How many peers are connected at any time during these episodes?

As you no doubt appreciate the mixture of peers, protocol layers, up/down bandwidth as well as some other factors all come into play and to be fair its a balancing act as the ideal default settings for a larger network might struggle with fewer peers or fewer uploaders, akin to load balancing on a server.

Keep experimenting and if you have time construct a small chart of settings, peers and transfers and if we are lucky a pattern might emerge to speed up a reworking of the algorithm.

Sorry, I do not know what peers you are referring to.

The "Peers in the network" count on the bottom status line of fopnu?  The peers in a fopnu channel? And for that, incoming connection? Outgoing connection? (And I forgot which panel is which on fopnu and they are not labeled.)

Another big problem for me is not having much information as to how things work. Without that I am a bull in the china shop stumbling around.

One of my eureka moments came in all this when I discovered that the BW limiters and graphs are not really hard limits or indicative of what's really going on, how much BW is actually being used. My system monitors show both are using significantly more BW than set. Without accurate BW usage info, it is hard to set limits to stay within the ISP levels and also allow for other users to have some BW.

And my initial reference to tixati I am now thinking is misplaced. After all my observations and testing, I am thinking that this is simply a BW depletion/exhaustion issue. And the conditions created by Tixati was merely one way to create the BW exhaustion.

If I am on track with that, then I am thinking that fopnu merely has to be more aggressive in demanding more of a share of whatever BW is available or balance it's internal allocation of what process gets priority. I note that Tixati has a setting for channel bandwidth priority that is lacking in fopnu. My setting for tixati channels is "below normal" and it seems to maintain channel connections quite well.

I am doing these tests on a rather small (by some standards) service level, on a rural ASDL connection with a ISP service level of 12 mb/s IN and 1 mb/s out. Since I do not typically download at this location, the outgoing level has been my focus for optimization.

In my now thought to be misguided belief that tixati was the culprit, much of my testing and settings adjustment was there. Aside from learning not to believe the BW limits and graph are accurate, after testing numerous had limit settings, I found that using tixati's AUTO BW control to dynamically adjust to conditions to be the best solution for me. With it enabled, I could even disable the hard IN and Out limits and the AUTO-set limits it applied would for the most part not allow BW exaustion to the point of interfering with fopnu channel connections.

Finally getting a better grasp on all this, leads me to the next issue. What about when someone joins the wifi and starts using their smartphone for whatever? I am now recalling the typical complaint "I can't connect" or "My pages are so slow to load". Then my first reaction was to shut down tixati and or fopnu to free up some BW. Internal self-regulation would seem to be better.

I'm thinking we need absolute max limit controls and the dynamic Auto-BW control (configurable like in tixati)