Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Actually getting Gigabit speeds #120

Open
clonm opened this issue Jan 22, 2019 · 2 comments
Open

Actually getting Gigabit speeds #120

clonm opened this issue Jan 22, 2019 · 2 comments

Comments

@clonm
Copy link
Member

clonm commented Jan 22, 2019

Sonic's faster currently. Need to finally follow through on this. Relevant to @kngnm, may require @mitar's help but I think the first step is just contacting HE.

@clonm clonm self-assigned this Jan 22, 2019
@clonm clonm changed the title Upgrading to gigabit Actually getting Gigabit speeds Jul 9, 2019
@clonm
Copy link
Member Author

clonm commented Jul 9, 2019

Progress report:

  • upgrade our plan with HE
  • migrate the HE router to new cabinet.
  • Develop robust tests for the bandwidth of each link, to try to narrow down the bottlenecks
    • create a spreadsheet for logging tests
      We haven't confirmed that our current test methods are actually capable of generating gigabit traffic yet, but they are still useful. Currently, we have two tests:

Ping Speed

  1. in the web interface for any of our mikrotik routers, go to Tools > Ping Speed
  2. Enter the remote IP to test in the "Ping To" box
  3. Click start, wait about two minutes, then click stop. If it doesn't work, change the Big Packet Size to 1024 instead of 1500. Not sure why this is helping - see Lower MTU in the network #72
  4. WRITE DOWN the remote IP, small packet size, big packet size, and average throughput values in the Getting to Gigabit spreadsheet.

Pros:

  • Can be run from routers
  • Doesn't require the remote server to have any special software installed
  • Provides a lower bound on the capacity of the link

Cons/Caveats:

  • Consumes router CPU, so we expect this to show lower throughput than a separate machine plugged directly into the router
  • Ping isn't really designed for bandwidth testing

iperf (see tozd/iperf )

  1. Pick an iperf server - I've been testing with iperf.he.net (216.218.227.10) and iperf.scottlinux.com (173.230.156.66). You can also run iperf in server mode with iperf -s from within the network. server3 has an iperf server running in a docker container (so exec into the docker container first! you don't need to install iperf on the host).
  2. On the client, run iperf -c <server> -P 4 -f 'm' -r. The -P 4 means run with 4 threads in parallel. If this fails, try with 2. Increase the number of threads until the total throughput doesn't increase with more threads, then use the last value where more threads helped.
    • If using server3 as the server, you will need to pass a port number depending on the interface being tested. See spreadsheet notes for details.
  3. (possibly unnecessary) if running within network, switch directions: Run the client as server and the server as client. Remember to swap the address. This should be pretty much identical and has been so far in the tests I've done.

@clonm
Copy link
Member Author

clonm commented Nov 4, 2019

Running iperf from server2 which is now directly attached to BSCRouterHE, I get ~425 Mbps

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant