UltimateIRCd Support > UltimateIRCd 3.0 Support

Bandwith Usage and Excess flood on /join

(1/2) > >>


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


--- Quote from: "IownYou" ---
Im probably the largest irc network that uses ultimate (around 2500 users)

--- End quote ---

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

--- End quote ---

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.

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)

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
--- End quote ---

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.

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 :)

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

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.


[0] Message Index

[#] Next page

Go to full version