View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0004126unrealircdpublic2012-10-05 05:032012-11-24 20:42
ReporternenolodAssigned Tonenolod 
PrioritynormalSeveritymajorReproducibilityN/A
Status resolvedResolutionfixed 
Product Version3.2.9 
Fixed in Version3.4-alpha1 
Summary0004126: [patch] new i/o recordkeeping code / evented i/o
DescriptionHello,

Attached is a patch implementing a new I/O recordkeeping system. This will allow us to move to evented I/O for 3.2.10.

The code is based on Mowgli's, with some ircd-specific features added.
TagsNo tags attached.
Attached Files
unreal-fdtable.patch (14,876 bytes)
3rd party modules

Activities

nenolod

2012-10-05 05:57

reporter   ~0017139

Last edited: 2012-10-05 05:57

 Patch added. Please integrate into the tree, as my evented i/o stuff depends on this.

It has been tested on Linux and FreeBSD, Windows probably needs the new symbols added to wircd.def.

nenolod

2012-10-05 06:02

reporter   ~0017140

I will continue my work on my own mercurial tree, like before, I will push this to bitbucket.

Once the evented I/O patches are completed, I will add them to this bug. Thusly, do not close this bug once the recordkeeping patch is integrated!

nenolod

2012-10-05 07:33

reporter   ~0017141

As a sneak preview, http://rabbit.dereferenced.org/~nenolod/patches/unreal-fd_select-try1.patch contains an implementation of evented I/O for poll(2). Nothing is hooked up to it in this patch, but it should work.

Going to commit this and push it to my bitbucket tree momentarily. Then I will hook up c-ares to the new I/O loop and see how things go. If that goes well, then I will move over the plaintext client handler next, and rewrite the remote includes code to register itself with the new I/O loop (which will resolve the bug related to it crashing when used with poll(2) if there are too many clients).

syzop

2012-10-06 12:37

administrator   ~0017153

Ok. Sorry for my lack of positive feedback, as I'm currently working on getting a test release for 3.2.10 :).
At a later stage I'll check things out and get back to you, but this may be months from now. If your goal is to make the I/O code actually readable and restructure things we can see if that can be put in 3.2.11, that would be nice. Right now that code is the worst readable part of UnrealIRCd (but it works...), but I read on IRC you already noticed... ;)

nenolod

2012-10-08 17:24

reporter   ~0017157

Here is an early cut at the new I/O code: http://rabbit.dereferenced.org/~nenolod/unreal-newio-without-fdtable.patch

What doesn't work 100% still:

- SAFELIST (might actually work, haven't tested it)
- remote includes (easy enough to fix)
- SSL (works sort of, but needs work to use the eventloop more efficiently)

Things that still need to be worked on:

- flush_connections() should go away, instead we should do edge-triggered writes like in charybdis (oops, i gave away one of our secrets on how we beat ratbox on i/o throughput ;))
- SSL / STARTTLS / etc eventloop integration

I think this is a 3.2.11 thing, as we're to a point where we just need to get things hammered out a little more.

nenolod

2012-10-26 08:48

reporter   ~0017204

Update on this... http://bitbucket.org/nenolod/unreal has a fully working ircd with the new i/o code. read_message() has been removed entirely.

I am going to start removing the remaining components of the fdlist code shortly, since it is no longer relevant. This leaves the question of what to do with the remaining heavy traffic mode code (which primarily determined what fdlists to check). Is it relevant anymore? My tree outperforms 3.2.10 even in heavy traffic mode by several magnitudes in terms of CPU to message throughput ratio... so I think HTM can just go away now with the fdlist code.

Once all of that is done, I am going to start looking at the spamfilter code. I think that there are some anticipatory optimizations we can make.

syzop

2012-10-27 14:07

administrator   ~0017208

If you are right in 0004127 that there's a better solution than HTM, then as far as as HTM is concerned the fdlists can go. HTM is rarely triggered or actually used AFAICT.
The fdlist code is also used to prioritize (I think?). If this is no longer necessary because your code already deals with high traffic scenarios then the fdlists can go too.
Prioritizing reading is not too important, it's far more important to execute commands of clients at different priorities and with delay (the whole reason fake lag and things like dbuf exists).
If there's no reason to have fdlists around, please remove them, as they are only annoying to keep track of ;)

As for performance, it'd be nice if you could share any (reliable) test results with us :)

Sorry for not taking a better look at what you did so far, I realize you are doing a lot of work! I'll certainly get back to you at a later stage... I'd *like* to say tomorrow, but.. I'm pretty sure I won't be able to. Just want to say, keep up the good work.

nenolod

2012-11-12 11:55

reporter   ~0017224

Another update on this.

http://bitbucket.org/nenolod/unreal now has a tree with the entire 2.8 eventloop removed.

In regards for CPU usage, with the fully async tree, running 10000 chat bots across 30 channels (each sending a message every 50ms) and spamfilter disabled, CPU usage spikes between 3-5%. On HG tip, the usage is much higher than that... about 40% CPU on my server (which is a dual Opteron 4162-EE machine).

This also cleans up a lot of hairyness with the eventloop in general. There's a few optimizations which can be made, such as tracking whether or not writes would block and postponing them. There's also TCP_CORK which may be interesting to play with, but it's not portable.

In regards to integration, I think the best approach is just to pull my tree into HG tip after 3.2.10 is released and call it 3.3 at this point. The changes made here are worthy of going from 3.2 to 3.3 in my opinion.

This work of course does not do much to deal with badly composed spamfilters -- if you have a crap spamfilter the IRCd is still going to crap out until it is removed.

nenolod

2012-11-24 20:42

reporter   ~0017242

Most of this is in 3.4.

Issue History

Date Modified Username Field Change
2012-10-05 05:03 nenolod New Issue
2012-10-05 05:56 nenolod File Added: unreal-fdtable.patch
2012-10-05 05:57 nenolod Note Added: 0017139
2012-10-05 05:57 nenolod Status new => has patch
2012-10-05 05:57 nenolod Note Edited: 0017139
2012-10-05 06:02 nenolod Note Added: 0017140
2012-10-05 07:33 nenolod Note Added: 0017141
2012-10-06 12:37 syzop Note Added: 0017153
2012-10-08 17:24 nenolod Note Added: 0017157
2012-10-26 08:48 nenolod Note Added: 0017204
2012-10-27 14:07 syzop Note Added: 0017208
2012-11-12 11:55 nenolod Note Added: 0017224
2012-11-24 20:41 nenolod Assigned To => nenolod
2012-11-24 20:41 nenolod Status has patch => assigned
2012-11-24 20:42 nenolod Note Added: 0017242
2012-11-24 20:42 nenolod Status assigned => resolved
2012-11-24 20:42 nenolod Fixed in Version => 3.4-alpha1
2012-11-24 20:42 nenolod Resolution open => fixed