<div dir="ltr">(added bird-users@ back, I didn't mean to remove them before)<div><br></div><div>Sorry that I missed that you'd already added the pull request. I merged it. we do need a way to specify exabgp vs bird, but that's just another thing to add.</div><div><br></div><div>I agree about containers and versions. Just haven't had time to think it through carefully. </div><div><br></div><div>The policy support is what bgperf had before I forked it. I don't use it, I don't know how to usefully test with it. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">One more feature I'd like to see, yet I'm not sure how to do this<br>properly – to make the measurement more accurate, the target should not<br>only run on its own machine, but bgperf with all the testers should also<br>watch their load, issuing warning when the bgperf suite may be the<br>bottleneck. This will probably help testing some hardware routers in a<br>somehow comparable way.<br></blockquote><div><br></div><div>I agree. My best quick hack for this is to make sure that there are extra resources on the CPU when running. That's why bgperf now tracks %idle. </div><div><br></div><div>As you can probably tell,  bgperf isn't a great architecture now, and I'm trying to get useful results as quickly as possible. So much could be done here.</div><div><br></div><div>thanks a lot!</div><div><br></div><div>Justin</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 31, 2021 at 2:30 AM Maria Matejka <<a href="mailto:maria.matejka@nic.cz">maria.matejka@nic.cz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello!<br>
<br>
On 8/31/21 1:29 AM, Justin Pietsch wrote:<br>
> I meant to ask if you'd compared exabgp to bird as testers? I'll try to <br>
> compare later if I have some time.<br>
Well, I have no exact numbers, I just implemented the bird tester and it <br>
seems to eat less memory and less time. You could probably run the same <br>
batch first with exabgp testers and then with bird testers, comparing <br>
how much this affects the results.<br>
<br>
> On Mon, Aug 30, 2021 at 4:27 PM Justin Pietsch <<a href="mailto:jpietsch@gmail.com" target="_blank">jpietsch@gmail.com</a> <br>
> <mailto:<a href="mailto:jpietsch@gmail.com" target="_blank">jpietsch@gmail.com</a>>> wrote:<br>
> <br>
>     This is fantastic!!!! Can you submit those changes as PRs to my<br>
>     bgperf? I'm working on moving it to a more permanent place. Then we<br>
>     can track issues! :)<br>
<br>
Well, yes, the tester exchange is already there pending:<br>
<br>
        <a href="https://github.com/jopietsch/bgperf/pull/1" rel="noreferrer" target="_blank">https://github.com/jopietsch/bgperf/pull/1</a><br>
<br>
and it seems that there are two more from somebody else.<br>
<br>
The tester exchange is anyway quite stupid and may need some similar <br>
code to MRT testers instead of what is there now.<br>
<br>
>     your suggestion for specifying branches used to work in bgperf, but<br>
>     I broke it in trying to get everything working. I moved some of the<br>
>     targets to just download prebuilt docker images, which makes it<br>
>     harder. Also with batch I'm not sure how to have multiple versions<br>
>     of the same container. Just more things to figure out, but that all<br>
>     makes sense.<br>
<br>
I think it would be better to have separate containers for different <br>
branches, yet I couldn't figure out how to do that, except for brutal <br>
solutions which were too disgusting to implement.<br>
<br>
Anyway, when BIRD is used as tester, it shouldn't imho change with the <br>
target, which is probably the main reason why I prefer separate <br>
containers for branches.<br>
<br>
One more thing – when running update -c, the container should also pull, <br>
not only checkout, imho. (Haven't had time to fix this yet.)<br>
<br>
>         * fixed policy configuration in BIRD (no clue whether it works with<br>
>         other stacks)<br>
<br>
This may need thorough examination first to formally define what the <br>
policies should mean. It would be really stupid to compare route <br>
filtering with different policies in each stack.<br>
<br>
One more feature I'd like to see, yet I'm not sure how to do this <br>
properly – to make the measurement more accurate, the target should not <br>
only run on its own machine, but bgperf with all the testers should also <br>
watch their load, issuing warning when the bgperf suite may be the <br>
bottleneck. This will probably help testing some hardware routers in a <br>
somehow comparable way.<br>
<br>
Maria<br>
</blockquote></div>