perfSONAR User Q&A and Other Discussion

[Mark Feit <>]

Michael Mellin writes:

 

We plan to renew our servers for perfsonar and I didn't find answers in
the documentation [1] at these questions :
- I eard we can use two NICs instead of 2 servers, but it's not clear in
the documentation. Does someone has any more information or ever tried
with 2 NICs ?

 

Dual-NIC perfSONAR is very common.  The typical arrangement is to have one for general-purpose tests (throughput, trace, rtt) and one for streaming and one-shot latency.  That keeps the latency measurements (mostly) from being distorted by the avalanche of throughput traffic.  You’ll find information on setting that up here:  https://docs.perfsonar.net/manage_dual_xface.html.

- in the documentation, I understand it's a better way to have only one
CPU with the highest frequency. Is it the best configuration when having
one servers (with two NICs) for the two tests (BW, lantency) ?

 

There are a lot of variables that go into answering that question, most having to do with the workload and what tool is being used for the throughput measurements.  If your systems follow our minimum recommendations, CPU frequency doesn’t matter for latency and helps some with throughput.  The usual way that’s made fast is through having more cores, the faster the better.  Most current, moderate-spec, server-class systems can saturate a 10 GbE interface easily with room to run streaming latency in parallel with good results. 

 

There are situations where having two separate systems is advantageous; Docker is an option for those.  Internet2 has been installing utility servers in its PoPs that dedicate memory and specific cores to each perfSONAR container.  The macvlan network type is used to dedicate a 100 GbE port to each container.  Lab testing of this configuration has worked well; we have one container per host up in production and will be turning up the second later.

 

Whatever configuration you use, it’s best to test a pair of them back-to-back in the lab before installing them in the field.  That will give you some idea about how they perform beforehand and eliminates questions about whether a performance problem is in the network or the system doing the measuring.

 

Hope that helps.

 

--Mark