Hi all,

is anybody aware of a Bandwidth Test server version for Linux?

thanx in advance

is there any plans for supporting ipers, as BTest won't come for linux

You can use wine to run btest tool.

Running btest server in wine is simply not an option. I would never trust the result of a gigabit link tested on an emulated/reverse-engineered protocol stack. I hope you will either support the iperf standard or release a linux text-based version of btest.

I just want to second the request for a Linux BTest server. The lack of it is causing grief among our support staff.

trust what you want, but correctness of it you can simply check by monitoring traffic passed through interfaces on the router in between btest.

or you do not trust that either?

For me it's not a matter of not trusting the results. Wine isn't going on the servers in our data center. You can call that religious, but it isn't going to change. Not that a non-free-software bandwidth test application is going on them either.

ok, no one will make me install wine on a server too.

as a "workaround" you could put RouterOS box in there (at least temporarily), and use it to test your links

or use any kind of linux bandwidth testing tool you want. just run the test to another linux machine behind the router

Doesn't that ruin the whole idea behind the btest system? Being able to test to the router while temporarily shutting of the local lan is an invaluable tool.

I really hope you will consider making the test server available for linux, or at least publish the protocol information so we can create our own implementation.

Doesn't that ruin the whole idea behind the btest system? Being able to test to the router while temporarily shutting of the local lan is an invaluable tool.

?

BTest is just a random data transmitter

Yes, but isn't it also a throughbut test? Testing the bandwidth of the line?
If so, it is a tremendous help to be able to test it directly at the router and not behind the router. Service providers prefer not to include anything the customer might have provided on his own, tampered with etc.

you are highly encouraged to run the test THROUGH the router, not from it, because the random data generation takes a lot of resources, and compromises the test results. threfore, it's almost the same as any kind of traffic. just run multiple FTP sessions, or something like that. The only difference is that BTest can also test UDP

Hmm, dire news indeed.

That means I will do a feature request instead:
A reliable bandwidth measurement tool
It could either be based on iperf, or a protocol of your liking, as long as it provides a linux remote server.
If random data makes the result unpredictable, then you should stop using random data. The payload in reality has no effect on the throughput, and you could just fill the payload with all zeros or all ones. That should be pretty easy to implement, if you ask me.

In real life, the router doesn't generate any data, so you shouldn't run tests that do. Any kind of data generation will use resources.

yes, but your routers are quite powerful, especially the larger ones. It can't impact that much...?

you can try to run btest tool on your computer and see, how much resources this tool uses, somehow similar tool is implemented in routeros, so you can test if you have no other chance, of course, if you are running RB600 in each end of line, but you are running 100MBps wire between them, of course, you will saturate that line before cpu maxes out.

anyway if you run btest through the router, not to router itself - you will get completely different results.

It seems to me that you are trying to convince me that a bug is a feature?
In all fairness, I find the bandwidth-test tool magnificent. Imagine my scenario:
We are a service provider, selling primarily MPLS solutions with managed CPE's. We've got around 80-90 routerboard units in production already, mostly RB450, some RB600 and we will in the future use a lot of RB1000 for gigabit links. Most of our links are around 25-50 Mbit/s on fibre or 8-20 Mbit/s on copper. Whenever we receive a customer complaint about throughput we are basically forced to send out an engineer to the customer and at the customer's inconvenience disconnect his equipment and test using iperf and similar from an ethernet interface on the router. It would be absolutely wonderful for us to test remotely, not mentioning the fact that our time cost money. So in a perfect world, we would just shut down the customer lan port, initiate a bandwidth test directly from the router and report the result to the customer. Now that would be wonderful, wouldn't it?

Right now, we are experimenting with installing an RB1000 in our data center and using it as a central bandwidth test server. It might work, but if you say your results are unreliable, I beg you to fix it to make it reliable. Make the payload of the data non-random, so that the router only needs to concentrate on moving the packets - there are plenty of ways to generate enough data for the payload: You could send all-ones, a fixed repeating string or even a random string generated before run and repeated at the desired segment size, and I'm sure you can come up with more ideas yourself!

I hope you will look positively on this request of mine - as I said we purchase a lot of your devices and we are a happy customer in any other regards

well, if you want to see the throughput of link - you can do that by sending bandwidth through the link, and this is reliable, the values showed are correct, but if you test throughput of router it self you should do that in the way normis told in previous posts.

so in your case - you can run BW-test on the links, and see available traffic on the link and that is acceptable.

so if you test throughput of router, then you have to have A and D as bandwidth generators and routers in the middle will be tested A----B-----C----D in this case you test router B and router C

in case you test link - you can send upd packages in one direction if router is not that powerful, and in both if you have enough "juice in router" and see the result that is reliable and correct

well, if you want to see the throughput of link - you can do that by sending bandwidth through the link, and this is reliable, the values showed are correct, but if you test throughput of router it self you should do that in the way normis told in previous posts.

Yes, very good. You have provided some nice benchmarks of your routers, so I am not very interested in testing the routers. Link speed and performance is what I want to test. Since we only use RB450 and RB1000 I suppose both these models are suitable for a full-duplex test?

yes, RB450 will be able easily saturate 100MBps link, just note, do not connect through link you are testing, or you might get disconnection, because of time-outs, as link will be fully saturated and any other data transmission will not be available. also run UDP packets, something like

I agree with Eising. We are in very similar situatuation. We have 100 mikrotik routers and they are connected together via wireless links. I would like to check the throughput between the main gateway and routers. I would like to make a script to check it automatically in the night. The night throughput is not actually so interesting but we can check measured throughput for a significant change according to previous measurements. Then we can find that some link went worse than before. I can do that with remote ssh to some mikrotik router and then initialization of the bandwith test from the router but it's more complicated.

We would very appreciate this functionality.

Can you share bandwith-test client code or at least share binary of that file? Thanks

I had a discussion with a few people about this at the MUM, and basically what people told me was that the bandwidth-tester is working great as a receiver of the test, but the actual package generation is too cpu intensive. I have a few suggestions on what you could do:

1 (and most prefered): Release a bandwidth-test client that is either cross platform or has a linux and windows version. That way I could load it on my different management servers, and test against the CPE's. Despite the low cost of Mikrotik routers, it's simply not practical for me to set up a dedicated RB for each VPN customer (my customers are Layer3 VPNs, and are protected from each other).

2: Change the testing algorithm on the clients.
At the moment, the actual bandwidth test does a lot of smart tests with different packet sizes and all that. If you made it possible to do very specific test, for instance by selecting what packet size to run (together with MTU, buffer sizes etc.), you could basically just cat all ones (or fill a repeating string, like ping does) into the payload of the packets and thus save a lot of CPU.

I know there is a bandwidth test program for windows, but I simply refuse to install wine on my servers, and run a performance test on an emulated/reverse engineered OS stack...

I hope you will consider my suggestions, and I regret I didn't catch one of you MikroTik guys at the MUM and discussed it with you there, when I had the chance... I blame the beers

that amazing.

almost ten years past, and no progress at all?
that sucks.

Reverse engineered btest, written in Perl and C:
https://github.com/samm-git/btest-opensource

This man deserves the cookie!
Now I have to learn how to compile stuff on linux...

This worked for me:

that amazing.

almost ten years past, and no progress at all?
that sucks.

LMAO! HA HA HA, I signed up just to say the same exact thing, I did find that open-source btest someone made, but I don't really like that someone else had to do it for them!
Come on MikroTik, really, the backbone of most of the internet is built on linux systems, why have you not made this yet? Completely being lazy here!

Mikrotik's business plan seems to be to shoot themselves in the foot

August 2021, still the same!

It would make sense in this climate to create a docker container for a btest server with some sort of web interface to easily control the btest client/server.

If someone at Mikrotik is reading this, what is the use case for this? Easy, in an environment where you have multiple backhaul links as wells and WLAN environments, it is very easy to day to ask a client to run a docker container for the purpose of tuning and validation. Also, it's easy and cheap for me to buy a stack of small mini PC's run Linux and drop the btest server/client and/or container version distribute at key locations and perform validation and tuning. Yes I could buy a bunch of RB's to sort of do the same thing, but you need to move up to a CCR to get the capability to run multiple btest streams from multiple locations which you can sort of get that same performance on an x85 quad core minipc with a few gigs or RAM.

Anyhow that is my feedback.

I haven't been able to compile this linux btest due to os being so old.
What I am considering if having a routerboard monitor an address list for ips to speedtest.
As it completes each IP, it removes it from the address list and using fetch returns the results to a php script which updates the database.
It then lops until there are no more ips... I can have a 5min schedule restart the script if its in a completed state.

Has anyone else gone down this path.
I am more interested in the download that a cpe reports then the upload. I may only run the SEND TCP test.

I have looked at running the test from the CPE and it only runs data is not flowing. Seem appears less CPU intense for the CPE if it receives not sends data.

Actually it's pretty easy to compile this tool, I didn't bother to fix the autotools config but essentially just run:

$ gcc btest.c md5.c timing_mach.c

That'll return you a.out which is the binary that you can execute like:

$ ./a.out -t -u -c <ip_addr>

However the performance seems to be really bad, I haven't dug any further.

This worked for me:

Code: Select all

git clone https://github.com/samm-git/btest-opensource
cd btest-opensource
gcc -o btest *.c -lpthread

Thank you, works as a charm.