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.

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

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)

http://www.shadow-realm.org/forum/viewtopic.php?t=1201&highlight=bandwithThere 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.

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.

I'm hoping some of the bandwidth problem will be solved by adding deaf usermodes. Needed --> Deaf clients (http://www.shadow-realm.org/forum/viewtopic.php?t=1434).

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 (http://www.mircscripts.org/comments.php?id=1387)

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

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.

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.