I have a "small" 1 MB/s upload limit on my ASDL line.
Running both fopnu and tixati on that is pushing the limits.
When I was experiencing intermittent streams of disconnects/reconnects on some fopnu channels, I noticed that stopped when I closed tixati.
I had both fopnu and tixati UL limits set to 48KB/s, totaling 96 KB/s, well under the ISP's 125 KB/s service level.
Then I discovered tixati was actually using well over 60 KB/s while the BW chart indicated a smooth 48 KB/s
My workaround is to set the tixati BW limit lower to 36-38 KB/s and the monitor shows with that setting it is actually using ~48 KB/s, my target.
I'll adjust fopnu also along those lines since it appears it also uses more BW than the set limit.
by Guest on 2019/06/13 04:10:16 PM
I suspect the bandwidth setting is meant to control just file data transfer - you are forgetting that there may be significant protocol overhead on top to control the connections, requesting parts, negotiating availability etc.. That's what is probably throwing off your calculation.
I am very aware of packet overhead.
My problem arose because I assumed that the BW limit controls and chart was for the total, data plus overhead.
It apparently was not designed that way or there is a bug in the calculations.
Either way, I think a hard, TOTAL limit is needed. Perhaps as an optional setting, for users to choose which they need/prefer?
All I know is that my intuition failed me. again. I have been struggling for months trying to figure out my fopnu client channel connection instability, then finally stumbling on this as being contributory.
Not knowing really what specifically causes that, I am suspecting that fopnu also needs to be tweaked to make it a little more aggressive on whatever the process is to keep it connected. While my ISP bw is usually quite reliable, I would expect at times it can't deliver the usual BW. And as I run to the max (or 80%), it would be nice if fopnu would be able to maintain during the occasional drought.
