Author Topic: Bandwith Usage and Excess flood on /join  (Read 12275 times)

Offline IownYou

  • First timer
  • *
  • Posts: 2
    • View Profile
Bandwith Usage and Excess flood on /join
« on: March 22, 2003, 01:49:20 am »
Hi,

Im probably the largest irc network that uses ultimate (around 2500 users)

But im experiencing some problems:

Ultimate has an incredible high bandwith usage if you compare it with other ircds

2) If users want to join chans wich are around 800+, they get excess flood, and not just one user, lets say 20% of them gets that

Offline ShadowMaster

  • Chief Codemonkey
  • Administrator
  • ********
  • Posts: 3136
    • View Profile
    • http://www.shadow-realm.org/
Re: High bandwith + Excess flood
« Reply #1 on: March 22, 2003, 03:24:36 am »
Quote from: "IownYou"

Im probably the largest irc network that uses ultimate (around 2500 users)


The current largest known IRC network to run UltimateIRCd out there today have a max client count of 6000 users.

Quote

Ultimate has an incredible high bandwith usage if you compare it with other ircds


This have been covered in several threads already.
Server <-> server bandwith can be compressed, and server <-> server traffic is really the only place you will see a difference between IRCd's. Why? Because there is no difference in how different IRCd's send data to the client. They are ALL, every single one of them restricted by how the RFC for IRC specifies how data MUST be sent to the client.

Claims that UltimateIRCd uses more bandwith than IRCd x, or IRCd y using more bandwith than IRCd t are for the most parts myths.

There may be minute differences in server <-> server bandwith usage, but server <-> server bandwith usage accounts for only a minute fraction of a servers bandwith usage.

Example:
Uptime 2 days 6 hours for all servers in example due to recent restart for namechange.

Routing hub doing routing for 3 client servers + US hub
Network handeling between 4000 and 6000 clients, past few days stats closest to 4000 clients.

<<Stats>> Sent total :  105.82 Megabytes
<<Stats>> Recv total :   27.87 Megabytes
<<Stats>> Server send:  100.69 Megabytes ( 0.5 Kb/s total,  0.4 Kb/s current)
<<Stats>> Server recv:   74.51 Megabytes ( 0.4 Kb/s total,  2.1 Kb/s current)

Thats approx 75 megabytes per day in server <-> server traffic on a large network on a busy hub.

A 600 client server:
<<Stats>> Sent total :   10.95 Megabytes
<<Stats>> Recv total :   44.72 Megabytes
<<Stats>> Server send:    2.32 Gigabytes (12.3 Kb/s total, 18.9 Kb/s current)
<<Stats>> Server recv:  147.60 Megabytes ( 0.8 Kb/s total,  1.1 Kb/s current)

The 600 clients have only sent to the server 147 megabytes total in 2 days, but the server have sent 2.32 gigabytes of traffic to the clients.

The reason this particular server have a fairly high bandwith usage for clients is the type of channels on the network (large FServ channels which have a lot of activity) and most of the clients on the server sitting in such channels.

Most people seem to forget that text actually takes up a lot of bandwith when you have to send a lot of it. The larger your client server gets, the busier channels those clients sit in.. the more bandwith will have to be transferred.

Your next problem seems to indicate your server is in this exact situation with clients sitting in large channels.

The extreme bandwith usage client <-> server compared to server <-> server is also the reason that the next IRC protocol level, which is alledgedly being worked on by the major networks in cooperation with client authors is to deal primarily with reducing the bandwith usage. Both by removing the need for servers to send full prefixes and possibly introducing server <-> client compression.

If you take the time to look at what the server actually have to send to a client on every single message to a channel you will gain a better understanding on why bandwith usage is as high as it is.

You will notice that when Nick1 sais Hi in #Channel, it doesnt mean the server only have to send:
:Nick1 PRIVMSG #Channel :Hi\r\n

But it has to send:
:[email protected] PRIVMSG #Channel :Hi\r\n

To further illustrate it, to send that two Char message to each client on that channel, the server have to send the message which in the extreme cases can be up to 154 chars long. 152 of those chars are the PREFIX and cr/lf (Carriage Return/LineFeed)

:Nick(32)!(1)User(10)@(1)host(63) (1)PRIVMSG(7) (1)Channel(32) (1):(1)Hi(2)\r\n(2)

http://www.shadow-realm.org/forum/viewtopic.php?t=1201&highlight=bandwith
There is another thread covering this in some detail but i cant seem to find it atm.

Quote

2) If users want to join chans wich are around 800+, they get excess flood, and not just one user, lets say 20% of them gets that


The only real workaround for this is to increase the sendq's for the user classes or educate your users.

Whats occuring is that upon joining a channel, many clients will issue a /who #Channel which will generate in the case of an 800 client channel, 800 long lines of text which are sent to the client.

If the clients connection to the server is unable to handle that quite large amount of data fast enough, their sendqueue will fill up, and once the sendqueue fills up completely they are disconnected from the server as the server will see the client as unable to process the data its sending.

Smarter clients do /names #Channel upon join which is a more friendly and safe manner to obtain data on who is in a given channel or not.

A /names for the very same channel will likely be somewhere between 5-10 lines long containing only the nickname and its status.

If you start doing the maths you will also see another reason why your seing high bandwith usage. A who reply contains large amounts of data, and some clients are requesting that data everytime they join the channel.

More or less ALL clients i know of can disable Who onjoin, and revert to names on join instead.

But as i said, the only way to avoid this is to have more leenient sendq's for your client classes.

We are looking at the possibility of output throtteling on WHO replies, but we are not sure this can be accomplished in a properly working fashion.
Clients could quickly find themselves spending several minutes just waiting for all the who data to be sent with such a system, so there are a few considerations to make in addition.
Search before posting - No support by PM or IM

Offline ShadowMaster

  • Chief Codemonkey
  • Administrator
  • ********
  • Posts: 3136
    • View Profile
    • http://www.shadow-realm.org/
Bandwith Usage and Excess flood on /join
« Reply #2 on: March 22, 2003, 03:26:23 am »
On a side note.. making this a sticky and moving to the apropriate forum in the hope people will read it and i wont have to keep answering the same things over and over again :)
Search before posting - No support by PM or IM

Offline IownYou

  • First timer
  • *
  • Posts: 2
    • View Profile
Bandwith Usage and Excess flood on /join
« Reply #3 on: March 22, 2003, 02:31:29 pm »
Ok, thanks cool respond

I have one other question, i have already readed something about this in another topic, but i dont know if there is any progress on it:

Can you limit the speed it sends the /who, this would be much better than making the sendq higher

Thanks in advantage

Offline ShadowMaster

  • Chief Codemonkey
  • Administrator
  • ********
  • Posts: 3136
    • View Profile
    • http://www.shadow-realm.org/
Bandwith Usage and Excess flood on /join
« Reply #4 on: March 22, 2003, 04:30:34 pm »
No, as i mentioned in my previous post, we are looking at the possibility of output throtteling, ie the rate at which the WHO replies are sent out at, but we still dont know how feasible that is.

So the only solution at present is to increase your sendq's when your network is hosting large channels. Alternatively educate users and have them disable Who onjoin.
Search before posting - No support by PM or IM

Offline Chrysalis

  • Here a lot
  • ***
  • Posts: 64
    • View Profile
    • http://www.irchighway.net
Bandwith Usage and Excess flood on /join
« Reply #5 on: March 25, 2003, 05:19:56 am »
another thing I have noticed is when doing /stats ? the value fluctuates a lot so its worth doing the command a few times to get a good idea of the current value, the recent addition of average value has helped a lot tho.
irc.irchighway.net - proud network using a great ircd

Offline erich

  • Needs to get out more
  • ****
  • Posts: 132
    • View Profile
Bandwith Usage and Excess flood on /join
« Reply #6 on: April 01, 2003, 09:13:39 am »
I'm hoping some of the bandwidth problem will be solved by adding deaf usermodes. Needed --> Deaf clients.

We got a channel of 1500+ users. It takes ALOT of the bandwidth. You should add a rule that the bots only may announce every 30 mins maximum. Announcing every 10 mins isn't needed at all. XDCC leechers are often using XDCC scripts. Like XDCCV

What also concerns me is the fact that eggdrops and iroffer seems to use the Who instead of Names. They definately requires you to raise SendQ. Is there any way to disable Who onjoin??

Uhm... I know the question ISN'T a UltimateIRCd support question. But I know that some of you are excellent supporters...  :P
Network Founder @ After-All.org
http://www.After-All.org

Offline ShadowMaster

  • Chief Codemonkey
  • Administrator
  • ********
  • Posts: 3136
    • View Profile
    • http://www.shadow-realm.org/
Bandwith Usage and Excess flood on /join
« Reply #7 on: April 02, 2003, 10:20:18 pm »
The old value which have always been there is the average value which wont fluctuate much unless you happen to have a massive flood going on.

The new value is the current usage which will fluctuate as bandwith usage rarely ever stays constant.

Deaf Clients should make its appearance in a31, but ive been unable to do any work as of late on anything due to moving, and being without my internet line doesnt help at all. (Currently on a Windows workstation on dialup)

As for iroffer and eggdrop im unsure. Forwarding to the apropriate authors/mailinglists is recomended. If its not currently possible a feature request mite be put in to have such an option added as it will cause bots to run into problems.
Search before posting - No support by PM or IM

Offline erich

  • Needs to get out more
  • ****
  • Posts: 132
    • View Profile
Bandwith Usage and Excess flood on /join
« Reply #8 on: April 03, 2003, 01:14:40 pm »
Quote from: "ShadowMaster"
Deaf Clients should make its appearance in a31, but ive been unable to do any work as of late on anything due to moving, and being without my internet line doesnt help at all. (Currently on a Windows workstation on dialup)

As for iroffer and eggdrop im unsure. Forwarding to the apropriate authors/mailinglists is recomended. If its not currently possible a feature request mite be put in to have such an option added as it will cause bots to run into problems.


Damn I miss you....  :wink:
Network Founder @ After-All.org
http://www.After-All.org

 

anything