Hi, I’m running bird 1.6.3 on FreeBSD 11.1-RELEASE. I see many “I/O loop cycle” in my logs: root@budic:~ # tail -F /var/log/messages | grep 'bird:' Jan 12 15:53:30 budic bird: I/O loop cycle took 10101 ms for 4 events Jan 12 15:54:30 budic bird: I/O loop cycle took 10227 ms for 5 events Jan 12 15:55:29 budic bird: I/O loop cycle took 9270 ms for 4 events Jan 12 15:56:28 budic bird: I/O loop cycle took 9101 ms for 6 events Jan 12 15:57:30 budic bird: I/O loop cycle took 10187 ms for 7 events Jan 12 15:58:28 budic bird: I/O loop cycle took 9315 ms for 3 events Jan 12 15:59:28 budic bird: I/O loop cycle took 9273 ms for 3 events Jan 12 16:00:29 budic bird: I/O loop cycle took 9170 ms for 3 events Jan 12 16:01:29 budic bird: I/O loop cycle took 9064 ms for 3 events Jan 12 16:02:29 budic bird: I/O loop cycle took 9561 ms for 7 events By reading http://bird.network.cz/?get_doc&v=16&f=bird-3.html I don’t understand very well what that means. I tried to disable the two BGP sessions where I receive the IPv4 fullview (I was still receiving it via iBGP during this time) but it didn’t change anything. Also, I don’t see the router droping packet nor routes; I just see the message in the logs. What can I do to avoid it? (other than increasing the timeout) Thanks, -- alarig
On Fri, Jan 12, 2018 at 04:32:00PM +0100, Alarig Le Lay wrote:
Hi,
I’m running bird 1.6.3 on FreeBSD 11.1-RELEASE.
I see many “I/O loop cycle” in my logs: root@budic:~ # tail -F /var/log/messages | grep 'bird:' Jan 12 15:53:30 budic bird: I/O loop cycle took 10101 ms for 4 events Jan 12 15:54:30 budic bird: I/O loop cycle took 10227 ms for 5 events Jan 12 15:55:29 budic bird: I/O loop cycle took 9270 ms for 4 events Jan 12 15:56:28 budic bird: I/O loop cycle took 9101 ms for 6 events Jan 12 15:57:30 budic bird: I/O loop cycle took 10187 ms for 7 events Jan 12 15:58:28 budic bird: I/O loop cycle took 9315 ms for 3 events Jan 12 15:59:28 budic bird: I/O loop cycle took 9273 ms for 3 events Jan 12 16:00:29 budic bird: I/O loop cycle took 9170 ms for 3 events Jan 12 16:01:29 budic bird: I/O loop cycle took 9064 ms for 3 events Jan 12 16:02:29 budic bird: I/O loop cycle took 9561 ms for 7 events
By reading http://bird.network.cz/?get_doc&v=16&f=bird-3.html I don’t understand very well what that means.
I tried to disable the two BGP sessions where I receive the IPv4 fullview (I was still receiving it via iBGP during this time) but it didn’t change anything.
Hi This is most likely a result of periodic scan of kernel routing table containing 680k routes of BGP feed. I measured it recently on FreeBSD 10 to be about 2.4 s on relatively powerful hardware. Not sure why you have 9-10 s instead (slower behavior on FreeBSD 11 or just different hardware). Unfortunately, i don't think you can do much with it. You can increase 'scan interval' of kernel protocol so it happens less often. But it is still relatively harmless. We should make these scans asynchronous so they do not block main I/O loop. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Hi, Thanks for the clarifications :) On lun. 15 janv. 16:56:12 2018, Ondrej Zajicek wrote:
This is most likely a result of periodic scan of kernel routing table containing 680k routes of BGP feed. I measured it recently on FreeBSD 10 to be about 2.4 s on relatively powerful hardware. Not sure why you have 9-10 s instead (slower behavior on FreeBSD 11 or just different hardware).
The CPU is and AMD GX-412TC SOC.
Unfortunately, i don't think you can do much with it. You can increase 'scan interval' of kernel protocol so it happens less often. But it is still relatively harmless. We should make these scans asynchronous so they do not block main I/O loop.
Here is my configuration of the kernel protocol: protocol kernel { # learn; # Don't remove routes on BIRD shutdown persist; # Export to the kernel. export all; preference 110; } As I’m not importing any route from it, is it possible (or a good idea) to completely disable this scan with 'scan interval' or to put a very huge parameter? -- alarig
participants (2)
-
Alarig Le Lay -
Ondrej Zajicek