Post your hubstats

Discussion and questions about hub software
blastbeat
Member
Posts: 53
Joined: 10 Jan 2008, 19:56
Contact:

Re: Post your hubstats

Post by blastbeat » 08 Jan 2009, 12:23

ok, tested adchpp too:

http://home.arcor.de/blastbeat/hubstress/adchpp.JPG

ram usage seems fine, cpu usage grows with usercount

Pietry
Senior Member
Posts: 328
Joined: 04 Dec 2007, 07:25
Location: Bucharest
Contact:

Re: Post your hubstats

Post by Pietry » 16 Jan 2009, 20:26

Ok but any crash? Or memory and cpu usage compared to the other hubsofts ?
Just someone

blastbeat
Member
Posts: 53
Joined: 10 Jan 2008, 19:56
Contact:

Re: Post your hubstats

Post by blastbeat » 17 Jan 2009, 15:40

tested on winxp amd3000+ 1gb ram
the test bots only connected to the hub and didnt receive any further messages
(with will cause full send buffers in worst case as in luadch happened)

peak cpu usage:
uhub: ~ 5 - 10%
adchpp: growing to ~ 50% at 3000 users
dshub: ~ 90%
luadch: ~ 70%

peak ram usage:
uhub: 6 mb
adchpp: 25 mb
dshub: 97 mb
luadch: 210 mb

notes:
- dshub dropped users after a while, which is in my opinion the correct behaviour, but the cpu was very high and dshub didnt react when i closed all connected test bots at once
- adchpp: it was only possible to connect about 10 bots in 2 - 3 seconds, it took a while to connect all 3000 users
- uhub was very fast but crashed; dj_offset said the win version is unstable at the moment
(so a test on *nix would be good)
- luadch consumed to much ram and at bot 1500 it took longer and longer to connect;
disconnecting all users at once caused i very high cpu/ram usage

Pietry
Senior Member
Posts: 328
Joined: 04 Dec 2007, 07:25
Location: Bucharest
Contact:

Re: Post your hubstats

Post by Pietry » 17 Jan 2009, 18:29

Hmm thanks for testing. Although it would be interesting to see if the bots talk a little bit or search , how the softs are handling the problem... :)
Just someone

blastbeat
Member
Posts: 53
Joined: 10 Jan 2008, 19:56
Contact:

Re: Post your hubstats

Post by blastbeat » 17 Jan 2009, 20:58

yes i also thought about extending it. but the main impact seems to be login of users
because of broadcasted infs.
i suggest to strip as much inf parameters as possible and sending additional information only at request. for example the cid. normal users dont need it, some clients even dont show it

Dj_Offset
Member
Posts: 53
Joined: 15 Sep 2008, 21:48
Location: adcs://adcs.uhub.org:1511
Contact:

Re: Post your hubstats

Post by Dj_Offset » 18 Jan 2009, 15:11

uhub has a limited_bandwidth configuration option, which strips off most of the INFs broadcasted.

Sulan
Junior Member
Posts: 16
Joined: 19 Jan 2009, 20:33

Re: Post your hubstats

Post by Sulan » 19 Jan 2009, 21:52

Pietry wrote:Would be interesting to test ADCH++ as well...
r131 takes 2000 users with the hubstress tool without any problem

Pietry
Senior Member
Posts: 328
Joined: 04 Dec 2007, 07:25
Location: Bucharest
Contact:

Re: Post your hubstats

Post by Pietry » 20 Jan 2009, 10:59

I'm also interested in chat delay, or with many DRES ( which are really a pain in the *** for the hubsoftware )....
Just someone

Dj_Offset
Member
Posts: 53
Joined: 15 Sep 2008, 21:48
Location: adcs://adcs.uhub.org:1511
Contact:

Re: Post your hubstats

Post by Dj_Offset » 21 Jan 2009, 13:56

Why is DRES so painful for hubs? They are direct messages and as such do not matter much for total send bandwidth (compared to broadcast messages).
Besides, it is low value information (relatively), so a hub should feel free to drop them in case of "emergency", when the alternative is to drop a user due to excessive send queue.

Dj_Offset
Member
Posts: 53
Joined: 15 Sep 2008, 21:48
Location: adcs://adcs.uhub.org:1511
Contact:

Re: Post your hubstats

Post by Dj_Offset » 21 Jan 2009, 14:28

I have updated my adcrush utility, so now it will operate on 4 activity levels:
* 0 = polite
* 1 = normal
* 2 = agressive
* 3 = insane

It will connect an optional number of fake clients to an ADC hub, and perform these options "randomly" with random delay (length depending on activity level) for each client:
* connects and disconnects (randomly)
* send chat messages (BMSG, but only if enabled)
* send private messages (EMSG)
* send searches (BSCH or FSCH)
* send search results (DRES)
* send CTM or RCM messages
* send INF updates

I have had it hammer uhub at "insane" level with 3000 users overnight, and all I got was a *very* long log file.

I have a few more additions to make to it, and it will be released along with the next uhub release.

Post Reply