New default channel directives (proposal) - Help and Support

Help and Support
Ask a question, report a problem, request a feature...
<< Back To Forum

New default channel directives (proposal)

by notaLamer on 2021/07/24 06:44:58 PM

These channel directives do significantly reduce the required bandwidth (IN and OUT):
Careful setting: ##ctrl:sr=161,159,157,155,123&ir=27
Aggressive setting: ##ctrl:sr=500,1206,271,305,260&ir=167
I do not see any downsides compared to default and it's troublesome to ask each big channel owner individually to apply them. The settings have been in effect for over 2 months. I'd like to see them implemented as the new defaults for channels (or similar).

Bandwidth savings? Depends on channel, but can be 50% (from ~20KB/s to 10) or 600% (from 6KB/s to 1) depending on channel size and settings applied.

How the above was derived:
"Normal" and below usually are not long-term users, it's appropriate for them to have a lower refresh interval
"Trusted" usually are but aren't changing their shares often
Users above that are heavy-duty and may change their shares more often, hence slightly faster propagation time.

I know this is arbitrary and can be changed at will to more appropriate values.
However: I tried to select the individual numbers such that they'd not have multiple common multipliers i.e. on average no more than 1 (max. 2) groups are updated at the same time. This simple principle is not followed by https://support.tixati.com/channel%20directives default values.

The full explanation as posted in Tixati User Group Channel is copy-pasted below.

Time: May 2nd, 2021
From: notaLamer
Topic: Tixati Channel bandwidth optimization via directives - Results!
This is important to everyone who wants to host their own channel! Spare your users from high bandwidth: read on!

There's a wiki page that details so called 'channel directives' that control channel behavior: https://support.tixati.com/channel%20directives

If you dig deeper you will find there're settings controlling how often information is shared between joined users. This directly affects the bandwidth consumed by a channel.
And yes: it's possible to reduce the bandwidth. drastically!

> 'Why am I sending/receiving 3 times as much data in the omega channel compared to any other channel.'
> There are 189 people in there compared to this channel, and still 3 times as much data. I know 30KB/s isn't "A lot" but I have pretty limited bandwidth.

hehe :)

Currently TUG is at ~9-13KB/s, 170 users, 57k shares. It used to be at over 20KB/s. Not many can afford to idle in such a channel 24/7.

Today I tested dsc:cqtrmrfvac3nta3ndtoo3n2trq6wxa6aef7bleragj4evcjvcscq?dn=Tixati%20User%20Group%20-%20Help%20and%20Support and dsc:sc5u346if5uic4vwxjqrwyzt36sfg3bqf3rdk2jjeqakj7fa7qdq?dn=Another%20World%20Is%20Possible by joining with a fresh Tixati 2.81 client without port-forwarding (behind NAT).

TUG has an older version of the settings applied. Ask a manager/owner for current. Gotta be along the lines of ##ctrl:sr=161,159,157,155,123&ir=27
To my knowledge, dsc:2u7altl2sd2qy7h2d6emmabxpyutnpsqunkkmufmlrhdgcgpu4ua?dn=Sexati has latest: ##ctrl:sr=500,1206,271,305,260&ir=167 (4.6k shares, 36 users, ~1.1KB/s)
Same settings were now applied to Another World is Possible.

Note: TUG's current settings are already a big improvement over default.

=== Findings

Channels stabilized at after 30 minutes:
- TUG: 170 users, 57k shares, 7 / 9 KB/s bandwidth (down/up)
- AWIS: 314 us, 93k sh, 5 / 7 KB/s

Latest settings: Twice as many users, 1.6x shares and much less bandwidth! Win-win!

Forum/Chat/Private messages are instant despite these changes.
Channel join, MOTD, chat were instant.
Information tab was fetched immediately (the burning logo in ASCII took some time to be downloaded though)

Stop reading here if you are convinced and apply the settings to your channel now :)

It'd be nice to know what kind of improvement it made (please capture the new figures ~20min after applying new settings)

-

Surprisingly, the channel shares peaked before 30min. It looks like the client clears up old user info although it is still propagated by other users (who have retained this data and not yet removed).

AWIS: 12min in, 118k shares
TUG: 9min in, 83k shares

Maybe this marks the point when ALL share data has been successfully fetched and if we observe for longer (30min mark), we will see Tixati will eventually remove stale data of long offline users.

Both channels peaked at around 80KB/s download when fetching share info albeit at different times.

=== Explanation

As far as I understand these...

sr: share rate. How often in seconds are shares rebroadcast? Per-group settings
ir: information rate. How often in s is channel information rebroadcast? Gotta be responsible for MOTD/Information tab at least

Now neither info nor shares change often. We don't need to update them often. It's unclear how long previously broadcasted messages are retained 'in the network' and whether new users can start sharing immediately when they change theirs.
However since most users stay connected to channels 24/7, it's more important to keep bandwidth low, at the expense of update propagation taking like 3-10 minutes.

There's also the "maximum broadcast rate" (mr) ... I deleted my explanation attempt. This needs clarification from the dev. If it's in "broadcast/minute" then why are normal users allowed 30bc/min but stars and mod+ only 10bc/min?

Anyway these settings are a great optimization and you should give them a try! Report any issues if you encounter them.

Thanks for reading to the end :)

by Bugmagnet on 2023/10/09 02:51:52 PM

The short version:

Testing in a large channel, 250+ users online, 5,000+ users offline, sharing over 200,000 magnet links, using the default values for directives:
## ctrl:ir=15&sr=60,40,30,18[,12]&mr=30,30,20,10[,10]&pr=45&dl=normal&sttl=10y
the background channel BW was:
result: avg 16 KiB/s IN, 9 KiB/s OUT

Several variations were tested but these 2 are the most informative:

## ctrl:ir=313&sr=757,677,569,449,313&mr=31,29,23,13,11&pr=47&dl=normal&sttl=10y
result: avg 6 KiB/s IN, 5 KiB/s OUT

##ctrl:ir=313&sr=757,677,569,449,313&mr=31,29,23,13,11&pr=767&dl=normal&sttl=10y
result: avg <4 KiB/s IN, <4 KiB/s OUT

The latter resulted in a 75% reduction on BW IN and >50% on OUT from the default values. That's a keeper for me for now, unless I see some degradation of any search/browse functions or other delays in channel messaging.

Interestingly, changing the pr value from 47 to 767 had a very significant effect. I didn't experiment much with the mr values, only modified them to use prime numbers to avoid syncing peak BW effects.

The TLDR version:

I would hope to build on notaLamer's ideas...but I need more clarification on the settings.

The tixati support page provides some very brief descriptions:

Set the information broadcast rate (seconds/broadcast):

##ctrl:ir=15

Set the share broadcast rate (seconds/broadcast for normal,trusted,vip,star,mod+):
##ctrl:sr=40,30,20,15,12

Set the maximum broadcast rate (broadcasts/minute for normal,trusted,vip,star,mod+):
##ctrl:mr=30,30,20,10,10

Set the minimum broadcast rate (seconds/broadcast):
##ctrl:pr=50 (default is maximum of all "sr" parameters + 10 )

Ctrl directives can be combined on one line:

##ctrl:ir=15&sr=40,30,20,15,12&mr=30,30,20,10,10&pr=50&dl=normal

Set user cache lifetime (v2.89)
##ctrl:sttl=123

Set extra parameter (must be signed) created for a specific channel:
##extra:f82bx77h3hdniqmz883hs7bx8x

First, I'd like to address an apparent bug that has existed since at least v3.11 and continues through v3.19

When adding the Directives from the ADD+ menu, the following default line is added to the "Information" config tab:
ctrl:ir=15&sr=60,40,30,18&mr=30,30,20,10&pr=45&dl=normal&sttl=10y

Notice that only 4 values are provided for both sr= and mr=. The 5th value for MOD+ users is omitted. (A bug)

notaLamer makes I think a good point about selecting values for these various settings that if they are the same or multiples of another, they would sync and perhaps cause BW peaks.

Being pedantic, I think using unique prime numbers for all these settings would avoid that. I just have no idea how significant it is but it is worth considering. I modified all of the directive values to use prime numbers and tested that way.

As I manage several large channels on tixati, reducing the channel background bandwidth levels is important to me and I suspect many other users who might have low ISP limits also.

My hope is that one day https://support.tixati.com/channel%20directives will be enhanced with more detailed, newbie friendly descriptions will be added for each of the settings.

Fantasy request:
When fixing the bug in the ADD Directives menu, might it be more optimal to add separate default value options for small, medium and large channels?

So for information broadcast rate, which currently default to ir=15, what effect would setting it to 167 have? What benefits? What harms?
Who is re-broadcasting this "Information" data? All joined users? or only certain upper level users?

For the share broadcast rates which default to sr=40,30,20,15,{12?}, what impact would setting these to something like sr=757,677,569,449,313 have? What benefits at what costs?
Also, what is this "share" data and which users are (re)broadcasting such share information? All users? The sharing user? Users of a certain level?

As to the maximum broadcast rate default of mr=30,30,20,10,10, what data is being broadcast that is being controlled by this setting?
Am I understanding this that "Normal" level users can only broadcast whatever it is once in 30 minutes?
What are the benefits/costs for low versus higher intervals?

Next, what is this minimum broadcast rate, "pr=50" "(default is maximum of all "sr" parameters + 10 )"
If unset in the config, and the highest sr is 757, would this then be auto-set internally to 767?
What does it do? What is the purpose? What effect would setting it to max sr+100 instead of 10?

Finally, the setting for user cache lifetime seems simple, the period of time each user's share information is kept in cache, so sttl=123 would mean 123 days after the user was last seen, their listing would disappear from search and browse results right?

But not so fast.. What the hell is this extra parameter about? for???
extra:f82bx77h3hdniqmz883hs7bx8x looks rather cryptic to me, as if it is some hidden tag.
What is it and why is it in my channel config? I assume it has nothing to do with ID or tracking but I would like to know what it does, how it is used and how the value is created? Does a user enter their own values for this or what?

As noted, Ctrl directives can be combined on one line and for now, after just a little experimenting while in the dark as to the deeper implications of altering the default values, I settled on this config for all my channels, big and small:

##ctrl:ir=313&sr=757,677,569,449,313&mr=31,29,23,13,11&pr=[b]767&dl=normal&sttl=10y

On a very limited ISP line, I appreciate the >50% reduction in outgoing BW and the 75% reduction on incoming BW for the background channel functions.

I'd like to understand the settings more and experiment more but for now, That's All Folks!

by Bugmagnet on 2023/10/10 03:55:03 AM

Quick follow up.

The extreme changes I made in the channel config for Directives had a bad side effect.

For simply idling in a channel they were great. But these settings impact many other channel functions that I did not test and with 4 different settings: ir, sr, mr and pr... I as yet do not understand the function of each and how they might interact.

The drastic reduction in bandwidth usage for idling in a channel was wonderful. But I now know one bad side effect.

I closed tixati then restarted it. And the problem was glaring. I watched as the users began populating each of the channels I sit in. and it took about 15 minutes in one large channel for all the already joined users to show up as being present on my client.

I don't know which setting(s) might affect that but more understanding and more experimenting is needed to refine the values for each.

So I'm back to work on this.

by notaLamer on 2023/10/11 02:29:33 AM

so sttl=123 would mean 123 days

I have no idea if it stands for seconds, hours or days. It was me who added the line to support page only based on the changelog.

Thank you a lot I agree with everything. More information for optimization is needed. Nobody likes the amount of bandwidth big channels take by default.

Add Reply

<< Back To Forum