<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">sed ´s/colors/cores´</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em ter., 2 de mar. de 2021 às 12:34, Douglas Fischer <<a href="mailto:fischerdouglas@gmail.com">fischerdouglas@gmail.com</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:"courier new",monospace;font-size:small">This is very good news!<br><br>I know you said "This is a ball park guess", but I confess that I was a little scared by the proportion of extra CPU usage (30/48 -> +60%).<br>I also know that you said that the code is still "currently not releasable", but I'm curious to know a little more about how this multi-threading was handled.<br><br><br>Just to illustrate:<br><br>Single-Core CPU on BGP is known to be a problem for many engines and vendors.<br><br>One of the vendors developed a "creative" way to do this load distribution in multiple colors.<br>As I understood it, they made a kind of Affinity CPU by BGP-Peer.<br>In a way that each peer has a BGP process, and that process is "semi-tied" to a core.<br>And they created a mechanism to redistribute these affinities from time-to-time based on the amount of BGP messages per second exchanged on each peer.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em ter., 2 de mar. de 2021 às 10:13, Maria Matejka <<a href="mailto:maria.matejka@nic.cz" target="_blank">maria.matejka@nic.cz</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi!<br>
<br>
On 3/1/21 1:26 PM, Marcelo Balbinot wrote:<br>
> <br>
> Hi, I already asked this question at some point,<br>
> but I am curious about the evolution ..<br>
> About multi thread support (multi-core cpu use).<br>
> Is this still a possibility?<br>
<br>
Yes, it is. Be prepared that this will also raise memory usage (current <br>
estimates are about >+10% memory) and overall CPU usage (compared to <br>
single-thread execution) due to needed synchronization and buffers.<br>
<br>
This means that if you now consume 20G of memory and 30 minutes of <br>
single core time to converge the main table on a rather big node, you're <br>
going to consume, let's say, >22G of memory and 3 minutes of 16-core CPU <br>
(summing to 48 minutes of CPU time). This is a ball park guess, do not <br>
take me much seriously. It may be better, it may be worse.<br>
<br>
Anyway, there is some code (currently not releasable) that will get to a <br>
preview release soon. We'll highly appreciate testing from any user <br>
around. Stay tunad!<br>
<br>
Maria<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><font size="2"><span style="font-family:"courier new",monospace">Douglas Fernando Fischer</span><br style="font-family:"courier new",monospace"><span style="font-family:"courier new",monospace">Engº de Controle e Automação</span></font><div style="padding:0px;margin-left:0px;margin-top:0px;overflow:hidden;color:black;text-align:left;line-height:130%;font-family:"courier new",monospace"></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><font size="2"><span style="font-family:"courier new",monospace">Douglas Fernando Fischer</span><br style="font-family:"courier new",monospace"><span style="font-family:"courier new",monospace">Engº de Controle e Automação</span></font><div style="padding:0px;margin-left:0px;margin-top:0px;overflow:hidden;color:black;text-align:left;line-height:130%;font-family:"courier new",monospace"></div></div>