Alexander Kolesnik wrote: > Hello Pablo, > > Thanks for the answer! > >>> /etc/ulogd.conf: >>> rmem=442368 > PNA> ^^^^^^ > PNA> Rising this value will delay hitting ENOBUFS. This is the size of the > PNA> receiver buffer. > > 1. "delay" means I will get ENOBUFS in any case (early or later)? Yes, but as said, you can tune different parameters to make it harder to happen, like rising qthreshold, reducing cprange, setting a lower nice value for ulogd. > 2. What ENOBUFS does depend on? Packets per second? Bytes per second? > Amount of iptables/shaping rules? CPU performance? On the queue size, bytes/s sent to ulogd and on how slow ulogd is reading messages. > 3. Is there any way to calculate or predict the high limit of > traffic rate/number of rules/etc when the system will still manage to > process ULOG without alerting with ENOBUFS? I don't know any, at least yet. > 4. ipcad buffers (I suppose this is the same as rmem for ulogd) is set > to 4M: > /etc/ipcad.conf: > buffers = 4194304; > But I'm still losing ULOG messages. Does that mean I have to rise this > value more? Rising the value to the infinite is not either a solution, you'll hit ENOBUFS sooner or later. -- "Los honestos son inadaptados sociales" -- Les Luthiers -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
