Public-Mikrotik-Bandwidth-Test-Server(s) ( now shutdown as of April 1st 2025 )

Thu Jan 28, 2016 12:57 am

Public-Mikrotik-Bandwidth-Test-Server(s) ( now shutdown as of April 1st 2025 )
***** IMPORTANT INFORMATION *****
I will be shutting down the btest server I maintain on April 1'st 2025
It's been on-line for around 10-years and has seen countless terra-bytes pass through it during this time.
*********************************

** Changes *** Update information *** March 20'th 2025 - Wait periods between tests ***
I made some timeout wait changes to the best server I maintain.
- Maximum time for any btest is now 5-minutes or less
- You must wait 3 days to run another btest.
- If you do not wait the required 3 days , the btest server will auto block you for almost 3 weeks.
* * *
I made these changes because many remote ISP networks had every consecutive IP address running btest to my server on a set repeating schedule.
note - when I see in my logs something like this below:
x.y.z.1
x.y.z.2
x.y.z.3
x.y.z.4
* and many more IPs an ISP might have to their customers
x.y.z.250
x.y.z.251
x.y.z.252
x.y.z.253
x.y.z.254
* I am now starting to block the entire remote ISP's network when I see consecutive IPs testing to my btest server.
* This btest server is for manual testing of a remote mikrotik to my btest server.
* My btest server is NOT to be used to test every device in your network to my btest server.

North Idaho Tom Jones
---------------------------------------------------------------
Today ( July 29 2024 ) , The public access btest server I maintain is again now on-line.

This btest server was renumbered and the user name / password to access the btest have been changed.

IPv4: 23.162.144.123
IPv6: 2605:6340:0:1b::123
btest username: North-Idaho-Btest-Server
btest password: I-Am-Not-A-Cron-Script

The maximum/fastest this btest server supports is now : 1.5 Gig Up/Down

Quick notes:
Limit your total bandwidth testing time to less than 8 minutes.
You must wait 27 hours until you can btest again.
If you attempt to btest more than 8 minutes , then you go to btest jail for 7+ days until you can btest again
If you attempt to btest without waiting 27 hours , then you go to btest jail for 7+ days until you can btest again.
If you attempt to btest and you are in 7-day btest jail , then you reset 7-day btest jail back to 7+ days.
No automatic btest scripts on a timed schedule are permitted.
All btest must be manually performed by a human.
Each repeated login failures will auto extend and place your IP address in a 7+ Day btest timeout-waiting jail.
If a pattern of abuse -and- sequential IP-numbered of devices from your networks is detected , your entire /24 may be blocked.

Note: Please read all of my conditions prior to using my btest server

North Idaho Tom Jones

--------------------------------------------------------------------------------------------------------------------------
Old - prior information/posts below:
Today ( 3/21/2024 ) I performed the following on my public-access Mikrotik btest server I host.

IPv4: 23.162.144.120
IPv6: 2605:6340:0:1b::4
btest username: MikrotikBtestServer
btest password: MikrotikBtestServer

- ROS upgrade/update
From: 7.13.5
To: 7.14.1

- I also changed the btest username and passoword
From: MikrotikBtest
To: MikrotikBtestServer

- I also moved this Mikrotik CHR ROS btest server to a different hypervisor
From: VmWare ESXi
To: Proxmox

- During the migration from VmWare ESXi to Proxmox , I changed the Ethernet interfaces
From VmWare ESCi : vmxnet3
To Proxmox: VirtIO ( paravirtualized )

Note: I may be having some IPv6 connectivity to this btest server. (( I am rebuilding everything IPv6 at the ISP I manage ))

Please let me know if you experience any issues not that I have made some changes to this server.

Quick notes - limit total testing time to less than 10 minutes.
You must wait 27 hours until you can btest again.
If you attempt to btest more than 10 minutes , then you go to btest jail for 7+ days until you can btest again
If you attempt to btest without waiting 27 hours , then you go to btest jail for 7+ days until you can btest again.
If you attempt to btest and you are in 7-day btest jail , then you reset 7-day btest jail back to 7+ days.
No automatic btest scripts on a timed schedule are permitted.
All btest must be manually performed by a human.
Repeated login failures using the old btest/btest user/password may auto place your IP address in a 7-Day btest jail.

Note: Please read all of my conditions prior to using my btest server.

North Idaho Tom Jones
--------------------------------------------------

EDIT: May 16'th 2022 - ICMP Ping has been disabled. in the btest server. ( This was done to prevent ping-speed tests against this btest server )
EDIT: May 10'th 2022 :
Hundreds of Mikrotik admins have configured automatic btest script schedules to automatically btest to the btest server I operate and manage.
Automatic btests on a schedule are not acceped and are against my conditions to btest my btest server.
My btest server is averaging 1 to 4 Gig of sustained btest traffic that is to & from hundreds of remote locations every hour of every day.
To prevent the abuse of automatic schedules of btest(s) to my server and reduce btest bandwidth on my ISP networks ;
I have made the following changes to the btest server:

IPv4: 23.162.144.120
IPv6: 2605:6340:0:1b::4
btest username: MikrotikBtest
btest password: MikrotikBtest
* The old btest/btest user/password has been removed

Quick notes - limit total testing time to less than 10 minutes.
You must wait 27 hours until you can btest again.
If you attempt to btest more than 10 minutes , then you go to btest jail for 7+ days until you can btest again
If you attempt to btest without waiting 27 hours , then you go to btest jail for 7+ days until you can btest again.
If you attempt to btest and you are in 7-day btest jail , then you reset 7-day btest jail back to 7+ days.
No automatic btest scripts on a timed schedule are permitted.
All btest must be manually performed by a human.
Repeated login failures using the old btest/btest user/password may auto place your IP address in a 7-Day btest jail.

Note: Please read all of my conditions prior to using my btest server.

Note: If necessary , I will create a subscription based btest server and/or generate a new btest password 24 hours.
To the thousands of Mikrotik admins who have followed my terms and conditions to use this btest server - Thank You

North Idaho Tom Jones
----------------------------------------------------------------------------------------------------------------------------------------------------------------
EDIT: May 6'th 2022 I made changes to my conditions to use this btest server: Please read line numbers 1 through 12.
EDIT: May 3'rd 2022 -- the public access btest server has been updated from CHR ROS version 7.2.2 to version 7.2.3
EDIT: May 2'nd 2022 -- the public access btest server has been updated from CHR ROS version 7.2.1 to version 7.2.2
EDIT: April 15'th 2022 -- the public access btest server has been updated from CHR ROS version 7.1.5 to version 7.2.1
EDIT: March 22'nd 2022 -- the public access btest server has been updated from CHR ROS version 7.1.3 to version 7.1.5
EDIT: February 22'nd 2022 -- the public access btest server has been updated from CHR ROS version 7.1.2 to version 7.1.3

IPv4: 23.162.144.120
IPv6: 2605:6340:0:1b::4

btest username: btest
btest password: btest

EDIT: May 6'th 2022
I made changes to my conditions to use this btest server:
Note; To use this Mikrotik public access btest server , you agree to the following terms and conditions:
#1 - You will not use or create any automatic btest scripts on a timed schedule to automatically perform btest(s) to this btest server.
#2 - You will not run extended btest(s) to this btest server which last longer than 30 seconds.
#3 - The use of this btest server is only permitted to perform btest(s) inside a 10-Minute window.
#4 - You will never use this btest server to create a degrading bandwidth sustained load on your up-stream Internet provider.
#5 - You agree that I ( the owner/operator ) of this btest server may post your remote btest IP address(s) you used to test to my btest server.
#6 - All btest(s) you perform to this btest server will always be performed using a hands-on procedure without the use of any automated scripts.
#7 - You will never attempt a "dude" connection to this btest server.
#8 - You may perform multiple btest(s) inside a 10-minute window per each 24-hour period
#9 - Your btest(s must be completed inside a 10-minute window.
#10 - Failure to follow the above listed requirements may result in actions on my part to permanently ban/block your IP addresses from my networks and this btest server.
#11 - I ask ( not required ) , that you share in this Mikrotik forum what country/city your are located in and your btest throughput results.
#12 - You understand these terms and conditions and you understand the purpose of this btest server is to assist all Mikrotik admins in determining the status/throughput capabilities of the networks they manage.
**** This btest server has the capabilities to perform brief btest(s) up to 4-Gig throughput

Failure to follow these simple above listed request will automatically trigger my firewall rules to auto-block your btest access to my btest server for several days.

Original ( now old ) conditions to use this btest server:
Note; To use this Mikrotik public access btest server , you agree to the following terms and conditions:
#1 - You will not use or create any automatic btest scripts on a timed schedule to automatically perform btest(s) to this btest server.
#2 - You will not run extended btest(s) to this btest server which last longer than 30 seconds.
#3 - The use of this btest server is only permitted to perform brief 30-second btest(s).
#4 - You will never use this btest server to create a degrading bandwidth sustained load on your up-stream Internet provider.
#5 - You agree that I ( the owner/operator ) of this btest server may post your remote btest IP address(s) you used to test to my btest server.
#6 - All btest(s) you perform to this btest server will always be performed using a hands-on procedure without the use of any automated scripts.
#7 - You will never attempt a "dude" connection to this btest server.
#8 - You may perform up to 4 ( four ) btest(s) in a 24-hour period
#9 - You will pause a minimum of 5-minutes between btest(s)
#10 - Failure to follow the above listed requirements may result in actions on my part to permanently ban/block your IP addresses from my networks and this btest server.
#11 - I ask ( not required ) , that you share in this Mikrotik forum what country/city your are located in and your btest throughput results.
#12 - You understand these terms and conditions and you understand the purpose of this btest server is to assist all Mikrotik admins in determining the status/throughput capabilities of the networks they manage.
**** This btest server has the capabilities to perform brief btest(s) up to 4-Gig throughput

North Idaho Tom Jones

EDIT: December 8th 2020
Notice; The public access btest server I manage was re-numbered into new/different IP addresses. This public btest server is now at the following IP addresses:

IPv4: 23.162.144.120
IPv6: 2605:6340:0:1b::4

btest username: btest
btest password: btest

Note; To use this Mikrotik public access btest server , you agree to the following terms and conditions:
#1 - You will not use or create any automatic btest scripts on a timed schedule to automatically perform btest(s) to this btest server.
#2 - You will not run extended btest(s) to this btest server which last longer than 30 seconds.
#3 - The use of this btest server is only permitted to perform brief 30-second btest(s).
#4 - You will never use this btest server to create a degrading bandwidth sustained load on your up-stream Internet provider.
#5 - You agree that I ( the owner/operator ) of this btest server may post your remote btest IP address(s) you used to test to my btest server.
#6 - All btest(s) you perform to this btest server will always be performed using a hands-on procedure without the use of any automated scripts.
#7 - You will never attempt a "dude" connection to this btest server.
#8 - You may perform up to 4 ( four ) btest(s) in a 24-hour period
#9 - You will pause a minimum of 5-minutes between btest(s)
#10 - Failure to follow the above listed requirements may result in actions on my part to permanently ban/block your IP addresses from my networks and this btest server.
#11 - I ask ( not required ) , that you share in this Mikrotik forum what country/city your are located in and your btest throughput results.
#12 - You understand these terms and conditions and you understand the purpose of this btest server is to assist all Mikrotik admins in determining the status/throughput capabilities of the networks they manage.
**** This btest server has the capabilities to perform brief btest(s) up to 4-Gig throughput

North Idaho Tom Jones

* = * = * = * = * = * = * = * = * = * = * = * = * = * = * = * = * = * = * = * = * = * = * = * = * = * = * = * = * = * = * = * = * = * = * = * =
EDIT July 1st 2019
Some good news

The btest server 207.32.194.24 is now also IPv6

IPv4 address: 207.32.194.24
IPv6 address: 2605:4e40:0:1fe::
user: btest
password: btest
---------------------------------------------------------------------------------------------------
EDIT: Feb 26, 2019
Thanks to Martooo , it appears Martooo has spun up a public access btest server.
For details , here is his post: viewtopic.php?f=2&t=145303

EDIT: August 15 2018

At this time, the only known public accessable Mikrotik btest server is 207.32.194.24 (user=btest passoword=btest)

Note; The planetcoop btest server is no longer online. I/we want to say thank you planetcoop for offering to us your btest server. It will be missed.

Note: If anybody else is interested in hosting a btest server (10 meg or 100 meg or 1-Gig peak bandwidth), please post here and let us know.

North Idaho Tom Jones
------------------------------------------------------------------
Subject: Public-Mikrotik-Bandwidth-Test-Server(s)
EDIT: February 28th, 2018

btest server change effective immediately , aka - right now (March 22, 2018)
btest server 207.32.195.2 was moved to 207.32.194.24
Same server , same settings .. Just IP renumbered now to 207.32.194.24

btest user:btest
btest password: btest

FYI: My business is growing. We needed the entire 207.32.195.0/24 Class C netblock for some new networks we are building. Normally , I would of given a prior notice but something came up today and I had to rush a re-number on this btest server.

North Idaho Tom Jones
-----------------------------------------------------------------------------------------------

EDIT: February 28th, 2018
1st - today, I changed the bandwidth allocated to the 207.32.195.2 btest server
Info here: viewtopic.php?f=2&t=104266&p=645201#p645201
Max Limit: 105M
Burst Limit: 1250M
Burst Threshold: 50M
Burst Time: 500

The simple queue operates this way:
#1; allow sustained btest of 105-Meg
#2; If the recent bandwidth average has been below 50-Meg for (Burst-Time seconds), then allow up to 1.25-Gig (until this this #2 line no longer is valid).

2nd - Sometime in/around March 2018, the planetcoop btest server 50.235.23.218 will be going away.
planetcoop is moving to a new location and may not have easy access to a 10-Gig Internet connection for his btest server.
I would like give planetcoop a big "thank you" for his participation and donated time & equipment & operating Internet expenses in our Mikrotik community.

More info about planetcoop:: viewtopic.php?p=645482#p645482

3rd - If anybody is interested in placing their own btest server on-line for the Mikrotik community to use , please let me/us know.
It could be a 10-Meg or 100-Meg or 1-Gig or even a 10-Gig btest server (depending on the bandwidth you might wish to allocate for a btest server)

North Idaho Tom Jones
--------------------------------------------------------------------------------------------------------
Subject: Public-Mikrotik-Bandwidth-Test-Server(s)
EDIT: January 3rd, 2017

Thanks to planetcoop , we now have two public Mikrotik bandwidth btest servers we can test to out on the Internet.

Both btest servers are running Mikrotik CHR.
Both are on 10-gig Internet connections. This however does not imply you are able to test the full 10-gig.
Here is the information:

planetcoop btest server:
Host: btest.planetcoop.com
ipv4: 50.235.23.218
ipv6: 2001:559:8062::20
user and pass: btest
traffic graph of this btest server: https://btest.planetcoop.com:10443/graphs/iface/ether1/

TomjNorthIdaho btest server:
ipv4: 207.32.195.2
user and pass: btest
traffic graph of this btest server: http://207.32.195.2/graphs/iface/ether1/

You are welcome and encouraged to post your btest throughput results - and please let us know where you are located:
Also; A Reputation +1 is always welcome.

Please - limit your btests to short periods of time. We are also using some of our bandwidth for our customers also.

Thank you

North Idaho Tom Jones

======================================================================================================
EDIT: Feb 24 2016 --- Now supports up to 3.5 Gig speedtest - read all the posts
EDIT: October 7th 2016 --- This btest server now supports 3.6 Gig for both send and receive tests - please read through all the posts

I have setup a public accessible Bandwidth test server. It is available for temporary testing through the Internet.

To use this server to test your Mikrotik devices through the Internet you agree not to abuse it.

Here are the details for my server:
- x86 ROS hosted on VMware ESXi server (with 10-gig connection to the Internet)
- Burstable to 250 Meg up/down
- Sustained traffic is limited to 100 Meg up/down (after about 30 to 60 seconds)
- Your maximum connection time for testing is not to exceed 10 minutes.
- IP Address: 207.32.195.2
- btest user authentication needed: User: btest Password: btest
- You may NOT winbox to this machine - you may bandwidth test to it.

Please post your positive and/or negative results or thoughts.

If this server is abused, I will discontinue it.
I hope this helps Mikrotik network admins everywhere.

North Idaho Tom Jones

Thu Jan 28, 2016 1:17 am

Here's a suggestion on how you can keep your server not being (too) abused:

Require that routers make a "/tool fetch" request to a web server, and have the server return temporary bandwidth test username and password (ideally username on first line, and password on second line; for easy parsing). The username/password would only be valid for 10 minutes or so, after which, it would refuse to generate credentials for that IP for another... let's say hour or so.

To actually add the user automatically, you can use the API.

Thu Jan 28, 2016 1:24 am

Here's a suggestion on how you can keep your server not being (too) abused:

Require that routers make a "/tool fetch" request to a web server, and have the server return temporary bandwidth test username and password (ideally username on first line, and password on second line; for easy parsing). The username/password would only be valid for 10 minutes or so, after which, it would refuse to generate credentials for that IP for another... let's say hour or so.

To actually add the user automatically, you can use the API.

I considered doing just that - however I took the quick-easy-simple way to build it. If it creates any problems, then I will do just what you said.

FYI - (With bandwidth limits turned off) - I have tested to the internal loopback IP address of 127.0.0.1 and hit 17 gig. And external to the live IP address at up to 8 gig.

Also - if this is not abused, then I will consider increasing the temporary burstable peak testing speed to a full gig up/down.

tealc · Thu Jan 28, 2016 5:32 pm

Great idea if You have a good infrastructure and inet line! Thank You!
I was always wondering why MikroTik didn't do that with few bunch of load balanced servers.
I will test it in the evening CET.

Poslano sa mog Mi-4c koristeći Tapatalk

Thu Jan 28, 2016 6:23 pm

Great idea if You have a good infrastructure and inet line! Thank You!
I was always wondering why MikroTik didn't do that with few bunch of load balanced servers.
I will test it in the evening CET.

Poslano sa mog Mi-4c koristeći Tapatalk

Thank you - you are welcome to bang away test at it.

If anybody wants to perform any very-high bandwidth testing to it, you are welcome to drop me a private message and we can set up a time where it can be increased up to 10 gig if necessary.

shailparmar · Thu Jan 28, 2016 6:26 pm

Here is Result

Screenshot_2016-01-28-21-51-16_com.android.browser.png

Screenshot_2016-01-28-21-51-57_com.android.browser.png

Thu Jan 28, 2016 6:33 pm

I would guess that the lost-packets are due to my simple queue
Max limit: 100 M
Burst limit: 250 M
Burst threshold: 100 M
Burst time: 120

when the test exceeds the burst limit it will start dropping packets for a max of 250 meg
when the test exceeds the burst time it will start dropping packets for a max of 100 meg

BobcatGuy · Thu Jan 28, 2016 6:49 pm

I just tried your server...

on upload, I get my full upload limit of my isp, on either tcp, or udp.
on receive, I only get around 50 mbit down on TCP, my connection is 100 Mbit, but that could be due to location, but on UDP download, it bursts up to about 7 mbit for about 1 seconf, then to nothing, I cant actually see any traffic passing, if it is, its very few kbits, but still shows 0bps on the graph. the actual interface traffic is a few, less then 100 kbits/sec. Not sure what happened to the UDP......

this happens every time I have tried the test.

Testing from Canada

hmm oddly enough, I do a send and receive I get my 7 mbit upload and 130 down. I should only have 110 down, but hey, that's better. So seems to be only on Receive only test. and doesn't affect the Both, or upload....odd..

Thu Jan 28, 2016 7:04 pm

I just tried your server...

on upload, I get my full upload limit of my isp, on either tcp, or udp.
on receive, I only get around 50 mbit down on TCP, my connection is 100 Mbit, but that could be due to location, but on UDP download, it bursts up to about 7 mbit for about 1 seconf, then to nothing, I cant actually see any traffic passing, if it is, its very few kbits, but still shows 0bps on the graph. the actual interface traffic is a few, less then 100 kbits/sec. Not sure what happened to the UDP......

this happens every time I have tried the test.

Testing from Canada

If you have more upload speed during testing than download speed during testing, I would guess this would be created by your ISP being over-subscribed. Where there is much more ISP download traffic to customers than upload traffic. Thus the possible reason why you upload speed may be faster.

Or the problem could also be where your ISP gets their Internet feed from - they could also be over subscribed.

You may want to try bandwidth speed tests at busy times and at least busy times and see if there is a difference in test results. A difference in test results may point to somebody being oversubscribed.

This is one of the reasons I put my Mikrotik bandwidth tester on-line - so that Mikrotik network admins can test and determine such issues.

BobcatGuy · Thu Jan 28, 2016 7:10 pm

umm, yes, I understand, but when I do the test as " receive only" as UDP it jumps to about 4 - 7 mbit down, then to pretty much 0, ie NO traffic.

If I run the receive only test as TCP I get about 50-60 mbit, tcp data, which is expected for my 100 mbit connection.

if I run the UDP "both" send receive I get the full amounts of my connection, about 7 up, and 110 down.

so, ONLY the UDP receive only test gets no download speed. I don't mean, 1 mbit, or 2, I mean Zero. well, a short burst to 4-7 mbit when it first starts for 1 second.

BobcatGuy · Thu Jan 28, 2016 7:13 pm

ahh never mind. I have my last rule as a drop all others rule on my firewall, when I disable that, the download test with UDP works normally. as to why, im to lazy to figure out. everything else works, except this bandwidth test. odd.

Thu Jan 28, 2016 7:23 pm

Another possible reason the test results may be off is the clock-speed of the remote Mikrotik device performing the test.
This is why I am running my server on a 3+ GHz Intel CPU. When I run the test from an old RB 500, I get much much slower results. Those old RB jump up to 100 percent load quickly.

On my server, testing to itself (IP Address 127.0.0.1) it will jump up to 18 gig throughput testing and almost hit 45 percent CPU load. (and this is a virtual x86 ROS running under VMware ESXi with many many other active servers doing other things also).

tealc · Thu Jan 28, 2016 8:44 pm

With 100 tcp conn. count up to 140/87 mbps, with default 20 Conn 60/60 on 200/100 line.
But beware there is a Atlantic (Croatia) and 5km wireless link inbetween line and test equipment. Very good!!!

Poslano sa mog Mi-4c koristeći Tapatalk

BobcatGuy · Thu Jan 28, 2016 8:47 pm

jebiga

haha
My parents are from around Bihac' This is the only word they taught me ! hahah

Thu Jan 28, 2016 8:50 pm

With 100 tcp conn. count up to 140/87 mbps, with default 20 Conn 60/60 on 200/100 line.
But beware there is a Atlantic (Croatia) and 5km wireless link inbetween line and test equipment. Very good!!!

Poslano sa mog Mi-4c koristeći Tapatalk

TCP is often much more difficult to hit full speed because of the protocol which requires return ACK packets. This is where distance between the test devices has a major effect - due to the speed of light (round-trip propagation time through the network).

UDP is fire and forget. Thus there is no ACK return packet required when sending UDP fire-and-forget packets.

So on long distance - I would expect UDP to almost always show faster results. And with the way the TCP protocol works, I would expect it to be slower as you increase layer 2 and layer 3 hops on TCP traffic..

North Idaho Tom Jones

Sat Jan 30, 2016 3:16 am

Anybody up for a greater than 1-gig btest through the Internet ?

I've got a 10-gig physical network. I would like to test with somebody else who has 10-gig physical connection to the Internet using the Mikrotik bandwidth test program. Something like an O-dark-30 after-hours test limited to 2 gig only for a minute or so.

On my side, I want to verify my 10 gig connection is actually running faster than 1 gig.

Somebody up for some testing ?

North Idaho Tom Jones

EDinATL · Tue Feb 09, 2016 12:54 am

This is perfect! Thanks so much for providing this. I was just looking into how I could accomplish some of these tests and I couldn't be happier to find it. Definitely enough to saturate the Comcast links I'm testing in Atlanta

.

Thanks again!

Tue Feb 09, 2016 12:59 am

This is perfect! Thanks so much for providing this. I was just looking into how I could accomplish some of these tests and I couldn't be happier to find it. Definitely enough to saturate the Comcast links I'm testing in Atlanta .
Thanks again!

You are welcome

I can see from my logs that it gets some use.

It looks like there has not been any abuse. So, soon in the near future (when I have the time to test & verify), I may increase it to 1.2 gig. I have the spare bandwidth here to work with.

North Idaho Tom Jones

EDinATL · Tue Feb 09, 2016 11:39 pm

My informal results so far have been the following:

Comcast Business class in Atlanta's West Side, probably lowest speed tier: 30Mbps down and 7Mbps up.
My Comcast residential in Marietta, GA: 29Mbps and 6Mbps up.
Charter residential in Roswell, GA: 65Mbps down and 4.2Mbps up.

Thanks again!

troy · Wed Feb 10, 2016 10:24 pm

Very cool. Testing Seattle(?) to Virginia:

[me@myrouter] > tool bandwidth-test 207.32.195.2 ... direction=receive remote-tx-speed=200M duration=30 
                status: done testing
              duration: 31s
            rx-current: 199.9Mbps
  rx-10-second-average: 199.9Mbps
      rx-total-average: 199.9Mbps
          lost-packets: 0
           random-data: no
             direction: receive
               rx-size: 1500

I've often thought about setting this up as well, though we only have a 1Gbe connection and abuse is a concern, though I'd imagine that most people who could abuse it have better things to do.

If you don't mind a suggestion, you may want to add a couple filter rules to track addresses running tests so you can limit them to a finite number of sessions per period of time.

Thu Feb 11, 2016 6:25 pm

troy

I thought about adding IP tracking. One reason I have not is that I am not that good on the Mikrotik when it comes to firewall rules needed to track and log IPs during a bandwidth test.

However, I do know how to use Cisco access-lists with permits that can log IPs through my core 10-gig Cisco router to get from the Internet to/from my Mikrotik Bandwidth tester.

Thu Feb 11, 2016 7:28 pm

Some good news. I kicked up the peak throughput testing to now support up to 1.2 GIG bandwidth testing.

With the original system, I did not see any abusers. Everybody was good.

Please wait at least 1 minute between tests. My simple queue needs this time for the average traffic to drop so that it can again peak back up to 1.2 gig for another test.

Below is a CLI method to perform the test (if you are a command prompt type of person):
bandwidth-test 207.32.195.2 user=btest password=btest protocol=udp duration=30 direction=receive
bandwidth-test 207.32.195.2 user=btest password=btest protocol=udp duration=30 direction=transmit
If you use the CLI method shown above; then look at your tx-or-rx "10-second-average:" when the test is completed.

FYI information:
- At this time, my Internet connection should have the ability to support this load at all times
- My Internet connection comes out at Seattle Washington U.S.A. although I am actually located in North Idaho U.S.A.
- If you do not get the speeds you think you should be getting, then wait about 5 minutes. Somebody else could be testing which could effect your testing.
- I am not sure how well bandwidth tests will perform near or above 1-gig (due to the nature of the Internet connected routers and switches and physical transports)
- Please post your positive or negative results or thoughts about this tester.
- Please no abusers. The function of this tester is only intended to good and proper use
- And I wish to say "Thank You" for feedback.

North Idaho Tom Jones

troy · Thu Feb 11, 2016 8:41 pm

Tom,

This couldn't come at a better time. We're getting ready to turn up a new 1Gbe connection, and it will be very nice to actually be able to test it.

For the firewall, here are 2 simple rules that will limit the number of tests that can be performed

/ip firewall filter
add action=reject chain=input connection-state=new dst-port=2000 protocol=tcp reject-with=tcp-reset \
    src-address-list=btest
add action=add-src-to-address-list address-list=btest address-list-timeout=1d chain=input connection-state=new \
    dst-port=2000 protocol=tcp

First rule will reject any new connection from any address in the "btest" address list. The second rule will generate that list as connections come in. I used 1 day in the example.

Again, as long as folks aren't abusing it, great... but this may help if things become a problem.

Another way to do authentication, would be radius, which could use an SQL back-end, easily managed by a web front end where users could register, be verified, then granted access. I won't pretend to have the patience for building something like this, but I'm sure if you were to ask the community, someone would be more than happy to step up and help you out.

Thu Feb 18, 2016 6:45 pm

I would like others to consider configuring their own public Mikrotik Bandwidth Tester systems also and placing them on-line for other Mikrotik network admins to be able to btest to/from with.

I have had mine on-line for almost two months now and the last week has been opened up to be able to btest up to 1.2 gig (note a continuous btest will drop down to 100 meg). So far, I have not seen any effects on my business ISP network.

If you have the bandwidth to spare, I would like to suggest you consider also making a btest server. From my point of view, I have the bandwidth and I have only heard positive comments and so-far I have not seen any abuse - thank you.

Also - If anybody has a desire to perform any really high-throughput bandwidth testing, you are welcome to drop me a message and we can set up a time where I can crank up my btest server to be able to sustain up to 3-gig (Yes I have that kind of spare bandwidth).

North Idaho Tom Jones

novical · Tue Feb 23, 2016 12:57 am

Hi Tom,

Thank you very much for providing this! My results are below.
Are you planning to keep this server running permanently (for the foreseeable future, or until you run out of spare bandwidth)? Or is this a temporary project only?

It would be awesome if it's long-term, but either way, thank you!

BTest.JPG

Tue Feb 23, 2016 1:01 am

Hi Tom,

Thank you very much for providing this! My results are below.
Are you planning to keep this server running permanently (for the foreseeable future, or until you run out of spare bandwidth)? Or is this a temporary project only?

It would be awesome if it's long-term, but either way, thank you!

BTest.JPG

novical - are you measuring what you are supposed to be getting ?

If there are no abusers, I plan on keeping it on-line and available (aka long-term).

I plan on keeping it available as long as I have the extra un-used bandwidth to support btest connections.
At this time, do not see having to reduce the speed to less than 1 gig.

North Idaho Tom Jones

novical · Tue Feb 23, 2016 1:23 am

Hi Tom,

Thank you very much for providing this! My results are below.
Are you planning to keep this server running permanently (for the foreseeable future, or until you run out of spare bandwidth)? Or is this a temporary project only?

It would be awesome if it's long-term, but either way, thank you!

BTest.JPG
novical - are you measuring what you are supposed to be getting ?

Yes, getting very close to what I'm supposed to. 25 up / 25 down, but there is lots of other stuff running so I estimated it would be closer to 15-20Mbps.

If there are no abusers, I plan on keeping it on-line and available (aka long-term).

I plan on keeping it available as long as I have the extra un-used bandwidth to support btest connections.
At this time, do not see having to reduce the speed to less than 1 gig.

North Idaho Tom Jones

That would be great. I would like to set up a test server too at some point, but it may be a while before I can do that so in the meantime it's really nice having this. Are you aware of any other servers or yours is the only one as far as you know?

Thank you

Tue Feb 23, 2016 1:24 am

btest.jpg

My internal network testing to this btest server:

XTX · Tue Feb 23, 2016 2:08 pm

Hi Tom

Works like a charm

1.2G up, 1.2G down

Tue Feb 23, 2016 6:24 pm

Hi Tom

Works like a charm

1.2G up, 1.2G down

Great - I must admit that I did now know how well 1.2 gig would traverse through the Internet.

I am thinking about kicking it up to 2.4 gig then later 3.6 gig - might do the first later this week.

It would be nice if the btest server had a setting for how long a test can run to/from a client. If I had this kind of control of the server, then I would remove all limits and let it run up to 10-gig for 10 seconds or longer.

Thu Feb 25, 2016 3:00 am

Now you may test your Internet download speeds up to 3.5 Gig !!!

btest-squeue.jpg

Good news for you

I opened up my best server to be much faster !!!
It now supports 3.5 Gig bandwidth tests to you (your download speed)
It now supports 2.2 Gig bandwidth tests from you (your upload speed)

XTX · Thu Feb 25, 2016 2:37 pm

Hi Tom

Just tried it !

2G down and 1.3G up

Not bad since there is the Atlantic ocean between us

And for the 1.3G up...I'm testing from a CCR 1036-8G-2S+, and at that speed one core hits 100% and that's it

Thu Feb 25, 2016 5:54 pm

Hi Tom

Just tried it !

2G down and 1.3G up

Not bad since there is the Atlantic ocean between us

And for the 1.3G up...I'm testing from a CCR 1036-8G-2S+, and at that speed one core hits 100% and that's it

LOL - that actually made a needle like spike in my Cacti bandwidth graphs

If you don't mind, I have some questions for you:

- What do you get when you btest to your local loopback IP address of 127.0.0.1 ?
On my ESXi VMware hosted 32-bit x86 ROS, I get around 17 gig.

- What do you get when you btest to the IP address of your WAN on your Mikrotik?
I get 9 gig.

I have never played with a CCR device, so I really have no idea just how well they perform under heavy load and testing. I sure would like to replace my 32-bit x86 ROS btest server with a 64-bit ROS btest server. Anybody willing to donate one (or a physical miktorik that can handle a public btest server up to 10-gig ???

North Idaho Tom Jones

XTX · Thu Feb 25, 2016 9:39 pm

Hi Tom

Just tried it !

2G down and 1.3G up

Not bad since there is the Atlantic ocean between us

And for the 1.3G up...I'm testing from a CCR 1036-8G-2S+, and at that speed one core hits 100% and that's it
LOL - that actually made a needle like spike in my Cacti bandwidth graphs

If you don't mind, I have some questions for you:

- What do you get when you btest to your local loopback IP address of 127.0.0.1 ?
On my ESXi VMware hosted 32-bit x86 ROS, I get around 17 gig.

- What do you get when you btest to the IP address of your WAN on your Mikrotik?
I get 9 gig.

I have never played with a CCR device, so I really have no idea just how well they perform under heavy load and testing. I sure would like to replace my 32-bit x86 ROS btest server with a 64-bit ROS btest server. Anybody willing to donate one (or a physical miktorik that can handle a public btest server up to 10-gig ???

North Idaho Tom Jones

In both cases I get around 850Mb/s...and a sigle cpu core at 100%.
And Bandwidth Test uses only a single CPU core...so the tilera cpu isn't the best option on which to run the btest server...

Thu Feb 25, 2016 9:55 pm

FYI - Although I am running my ROS in a VMware ESXi environment, I am running two Intel Xeon 10-core E5-2690 3-GHz CPUs (20-meg CPU cache) (Hyper-Threading disabled), of which I have allocated 2 CPUs to the virtual ROS.

I was not aware that btest only used a single core. I might drop it down to a single CPU and see if it makes any difference.

North Idaho Tom Jones

XTX · Thu Feb 25, 2016 10:07 pm

FYI - Although I am running my ROS in a VMware ESXi environment, I am running two Intel Xeon 10-core E5-2690 3-GHz CPUs (20-meg CPU cache) (Hyper-Threading disabled), of which I have allocated 2 CPUs to the virtual ROS.

I was not aware that btest only used a single core. I might drop it down to a single CPU and see if it makes any difference.

North Idaho Tom Jones

Yeah...me neither, because frankly i don't use it at all, but since I saw your post I thought maybe i should try it

But then I read http://wiki.mikrotik.com/wiki/Manual:To ... width_Test and there it was :

Warning: Bandwidth Test uses only single CPU core and will reach its limits when core will be 100% loaded.

Fri Feb 26, 2016 3:38 am

Very nice.

From New Zealand through 19 hops I can get 1Gbit Full Duplex.

Wed Mar 02, 2016 12:30 am

FYI - the Mikrotik x86 ROS must of crashed a couple of days ago - I just noticed it was not talking so I re-started it.
207.32.195.2
btest user: btest
btest password: btest

This time I put a network monitor on it to alert me if it happens to go down.

I suspect I may of crashed it when I was performing some bandwidths from a 64-bit ROS and had all rate-limiting disabled.

North Idaho Tom Jones

Aveyer · Wed Mar 02, 2016 2:34 am

Cheers Tom, it's very useful.

Wed Mar 02, 2016 6:02 pm

LOL - well somebody had a 6 hour long btest running.

After a few minutes, my simple queue drops from Gigs down to 250 meg, which then continued running for 6 hours.

For an hours long sustained btest, it looks pretty good with no drop-outs from what I can see.

Good thing that I have several gigs of extra un-used available bandwidth

North Idaho Tom Jones

Lombart · Thu Mar 03, 2016 6:33 am

Thx for this !!!

man, you are my hero for btest, i'm from Indonesia and this btest server is very usefull for our client test for international bw !!

+1

rjscomms · Thu Mar 17, 2016 4:25 am

Thank you Sir, you are a legend.

Thu Mar 17, 2016 7:25 pm

Thank you Sir, you are a legend.

Nice comments are welcome.
Money is much more welcome - lol

thank you for the kind comment.

North Idaho Tom Jones

crash9877 · Fri Apr 08, 2016 1:53 am

Woha Dude,

perfect. Works fine from Germany. Excellent Job. Thank you so much for sharing this.

Fri Apr 08, 2016 1:56 am

Woha Dude,

perfect. Works fine from Germany. Excellent Job. Thank you so much for sharing this.

Woha - you are welcome

pyjamasam · Fri Apr 08, 2016 2:48 am

Thanks for sharing. Works great from Niagara Falls Canada. I get my full 55 down 10 up

chris.

Fri Apr 08, 2016 2:49 am

Thanks for sharing. Works great from Niagara Falls Canada. I get my full 55 down 10 up

chris.

challap · Wed Apr 13, 2016 11:29 am

Hi.Thanks very much for this.I am from South Africa and works fine

Wed Apr 13, 2016 10:02 pm

Hi.Thanks very much for this.I am from South Africa and works fine

You are most welcome.

Thank you for posting your positive response

North Idaho Tom Jones

WirelessRudy · Thu May 05, 2016 6:53 pm

Hi, great work done.
We used to use a Mikrotik router from a friend's network to do 'real' internet traffic test from our network towards his server. But his business is sold....

Anyway, I can use your's now to test again.

We have a 300/300Mb simmetric line delivered to us over a dual hop microwave link from our provider. (24Ghz) After some ill experiances with previous provider we need to test that capacity once a month at least to see we really get what we pay for.... so here your service comes in place.

We can use www.speedtest.net but results are all over the place and therefore very unreliable in my opinion. Either these servers at times, or part of my providers network or part of the rest of the (inter)network is saturated at times since sometime I can push my link to indeed 300 up and almost 300 down, but at time same PC connect to my CCR (=gateway) only gets 20Mb down......

Anyway I found your test server, very helpfull!

BUT;
I also have a multi session download bandwidth test program from Peplink (manufacturer for multy WAN load balancers) that works very nice (download only!) in downloading some standard files (MS-Windows upgrade for instance).
With this little program on my PC I can open several downloads (4 program sessions) for several files and it will fill the 300Mb pipe up to 285-290Mbps considered we already have some 90-140Mb client traffic running.
Done this many times and almost always can 'fil' by download pipe.

But just now did the MT-bandwidth test from same PC and can only 'fill' the same pipe to just over 200Mbps.
Actually, I could even run the bandwidth test from my CCR1016-12G and still can not fill the pipe. Max I'll get is 210-220Mbps max.
Starting Peplink in parrallel and it puts another 60Mbps on top of it to fill the pipe to 260-270 this time....

We are now developing the 'feeling' something is wrong with our CCR settings.
We also never can get the clients assigned (simple queues by PPPoE-server) internet speeds as we sell. But internal MT bandwidth test always completely fill the client's assigned queues.

Anybody has any advice where to look for?

kenny55 · Thu May 12, 2016 9:44 pm

Thanks! works great from Israel, 19 hops

Fri May 13, 2016 11:43 pm

One thing I have noticed is that sometimes my virtual ROS x86 bandwidth speedtest server running under VMware ESXi will sometimes crash - interesting.

I can't ping it or talk to it using IP. However the VMware ESXi console to the ROS is still active and the ROS does respond to console CLI commands.

I am kinda wondering if the problem is the IP stack dying when under extreme heavy I/O loads.

It's a good thing this not also functioning at a production router under the same loads.

Anyways - a reboot appears to get thing up and running again for another week or so.

FYI - From my Cacti bandwidth graphs, it looks like my ROS bandwidth test server gets a bandwidth test around every 1 to 2 hours ever day.

North Idaho Tom Jones

kristaps · Tue May 17, 2016 12:38 pm

could you make watchdog that genarates supout before it crashes and send to support@mikrotik.com

Tue May 17, 2016 11:30 pm

could you make watchdog that genarates supout before it crashes and send to support@mikrotik.com

OK - I modified my auto-reboot - when I get a hit I will send an email to support
North Idaho Tom Jones
-- Thank you --

Netwatch: (Detect a missed ping to something)
Host: 192.0.2.254 (an IP in my network)
Down: log info "Netwatch missed a ping to 192.0.2.254 - starting 5 minute timeout script" ; /system script run NetWatchBoot-192.0.2.254

Scripts: (Verify not false alarm - verify the problem stays around and we lost connectivity)
NetWatchBoot-192.0.2.254
:local addresstoping 192.0.2.254;
:local interface "wlan1";
#
:local continue true;
:local counter 0;
:local maxcounter 18;
:local sleepseconds 10;
:local goodpings 0;
:log error "-----> Tom's Netwatch-Script-Warning - Netwatch could not ping $addresstoping - Will begin further testing in $sleepseconds seconds - and will continue for $maxcounter times $sleepseconds seconds";
:while ($continue) do={
:set counter ($counter + 1);
:delay $sleepseconds;
:if ([/ping $addresstoping interval=1 count=1] =0) do={
:log info "----->ping to $addresstoping failed on attempt $counter of $maxcounter -- Will try again in $sleepseconds seconds";
} else {
:log warning "-----> ping success on to $addresstoping attempt $counter of $maxcounter <----- No Further testing needed --- Program will exit -----";
:set continue false;
:set goodpings ($goodpings +1);
};
}
:if ($counter=$maxcounter) do={:set continue false;}
}
:if ($"goodpings" = 0 ) do={
:log info "-----> Rebooting in 15 seconds";
:delay 5;
/file print file=ScriptRebootReason
/file set ScriptRebootReason.txt contents="Rebooted by Toms script on $[/system clock get date] at $[/system clock get time]"
:log error "-----> Rebooting in 10 seconds";
:delay 5;
:log error "-----> Rebooting in 5 seconds";
:delay 5;
:log error "-----> Rebooting now";
:delay 1;
/system sup-output without-paging file=btest-server
:delay 20;
/system reboot
/system reboot
/system reboot
/system reboot
}

voodoovood · Wed May 18, 2016 1:23 am

perfect!
27 hops from Slovakia,
930mbit up/ 930 mbit down

Wed May 18, 2016 6:08 pm

perfect!
27 hops from Slovakia,
930mbit up/ 930 mbit down

Perfect

Now that is what I like to hear

Am I correct in guessing you have a 1-gig Internet connection ?

WirelessRudy · Wed May 18, 2016 6:48 pm

I tried your server from Spain now several times and best I ever got download was some 100Mbps.
This is done directly from a CCR as our gateway router.
We are on a 300/300 symmetric line and with other programs can easy push over 250Mbps.

Doing same Mikrotik speedtest with its Window bandwidth tester from my PC gives me less than 1Mb, where a download progam with multiple connection almost inmediately downloads at 120-130 mbps and sometimes up to 280Mbps into my PC. (Still traffic from the rest of my WISP environment using the same 300/300Mbps.)

How come these huge differences?

Wed May 18, 2016 7:01 pm

I tried your server from Spain now several times and best I ever got download was some 100Mbps.
This is done directly from a CCR as our gateway router.
We are on a 300/300 symmetric line and with other programs can easy push over 250Mbps.

Doing same Mikrotik speedtest with its Window bandwidth tester from my PC gives me less than 1Mb, where a download progam with multiple connection almost inmediately downloads at 120-130 mbps and sometimes up to 280Mbps into my PC. (Still traffic from the rest of my WISP environment using the same 300/300Mbps.)

How come these huge differences?

I am guessing at some answers...
- Your up-stream ISP - or their up-stream connection may be over subscribed.
- There could be some bottle-necks somewhere between your location and my location (my connection is physically a 10-gig connection from North Idaho USA into Seattle USA. My account is actually a 2-gig account that is burstable.
- Try running the btest several times at different times. There is a chance that somebody else may of also been performing a btest to my server at the same time you ran a btest to my server - which may result in a slower result.
- Are you testing using TCP or UDP. UDP is normally much faster over many hops.

What is the best speedtest you get when using a PC computer testing to speedtest.net ? What do you get when testing to Seattle USA ?

Can you post traceroute from your location to 207.32.195.2
If you give me your IP address, I will post a traceroute from me to you.

WirelessRudy · Wed May 18, 2016 8:55 pm

I tried your server from Spain now several times and best I ever got download was some 100Mbps.
This is done directly from a CCR as our gateway router.
We are on a 300/300 symmetric line and with other programs can easy push over 250Mbps.

Doing same Mikrotik speedtest with its Window bandwidth tester from my PC gives me less than 1Mb, where a download progam with multiple connection almost inmediately downloads at 120-130 mbps and sometimes up to 280Mbps into my PC. (Still traffic from the rest of my WISP environment using the same 300/300Mbps.)

How come these huge differences?
I am guessing at some answers...
- Your up-stream ISP - or their up-stream connection may be over subscribed.
- There could be some bottle-necks somewhere between your location and my location (my connection is physically a 10-gig connection from North Idaho USA into Seattle USA. My account is actually a 2-gig account that is burstable.
- Try running the btest several times at different times. There is a chance that somebody else may of also been performing a btest to my server at the same time you ran a btest to my server - which may result in a slower result.
- Are you testing using TCP or UDP. UDP is normally much faster over many hops.

What is the best speedtest you get when using a PC computer testing to speedtest.net ? What do you get when testing to Seattle USA ?

Can you post traceroute from your location to 207.32.195.2
If you give me your IP address, I will post a traceroute from me to you.

Ok, Traceroute;

Traceroute to 207.32.195.2 by pingplotter.JPG

172.25.48.1 is my gateway, 212.231.164.1 is the cisco of my 300/300M provider.

udp speedtest from you to my CCR; Impossible
udp speedtest to you from CCR;

udp speedtest to 207.32.195.2.JPG

Good speed, 328Mb upload! (To where? Provider might drop these. Do they reach you, don't think so....)

tcp speedtest from you to my CCR;

tcp speedtest from 207.32.195.2.JPG

tcp speedtest to you from my CCR;

tcp speedtest from 207.32.195.2.JPG

udp upload from my PC to you;

tcp speedtest from 207.32.195.2.JPG

udp download from you to my PC; impossible

WirelessRudy · Wed May 18, 2016 9:05 pm

Peplink multi stream download from some servers;

peplink multi tcp download test from some servers.JPG

http://www.speedtest.net;

http://www.speedtest to and from local provider's server.JPG

Both up as download on the main pipe reached 185mbps (roughly 100-140mbps client running)

I tried to do some http://www.speedtest's to some servers in Seatle, WA. but speeds where in the range of 2-6Mbps at best. Not very useful.....

WirelessRudy · Wed May 18, 2016 9:08 pm

So, maybe we have a provider that is having saturation issues or we are not having a 100% contented to us pipe.

But how to proof? We've had something similar in the past and than the provider comes up with some ftp servers we can download from with ftp and off course, always we reach top speed according contract....

And maybe indeed the route to his servers is OK. How to find where other bottlenecks are to be found.
If I read the several post from other users from all over the world with good results, I'm wondering why I cannot have my contracted speeds?
Any help/suggestions from this forum is appreciated.

Wed May 18, 2016 9:22 pm

Here is a Mikrotik traceroute from my btest server to your ISP router:

traceroute-212-231-164-1.png

I suspect your ISP may have two potential issues:
- their NAT router might be running slow
- some of the hops appear to be bottlenecked ( he.net )

chiefbmr · Tue May 31, 2016 11:09 pm

Thanks Tom, tested 500/500 perfectly.

Chupaka · Wed Jun 01, 2016 2:22 am

With 186ms RTT, I'm getting 1912.4 Mbps/1933.6 Mbps Tx/Rx, not more. looks like there's somewhere 2G link in-between Belarus and USA

Wed Jun 01, 2016 6:01 pm

FYI - The free public btest server available to all Mikrotik admins is averaging just over 1.5 TB (tera-bytes) of best data a month. Wow - It looks like it gets used/tested against up to 50 times a day. And at least one person ran a 6-hour 200-meg sustained test during the last month.

I would like to ask - if anybody has the extra bandwidth capacity - would you be interested in a 24 hour sustained 1.5 gig up & down test ? I am interested in an opportunity to stress test my un-used spare capacity under heavy load.

Edit: or a bunch of testers running a 24 hour btest against me at what ever they can spare ... I would then set my simple queue to limit at 1.5 gig up & down flat.

Thu Jun 02, 2016 12:17 am

OK - I just setup a 2'nd speedtest server.
This one is at: http://speedtest.rezmail.net

It is hosted on the same VMware ESXi server as my Mikrotik btest server.

Hope this helps to compare a btest and a windows speedtest through your mikrotiks & firewalls.

If ya don't mind - you are welcome to post your btest speeds and your speedtest speeds.

North Idaho Tom Jones

Tue Jun 07, 2016 1:42 am

Heads up - I will be shutting down both speedtest servers in about 30-minutes from now.
They should be turned on in about 15 hours or so.

Our 10-gig fiber is being worked on - My network is going to fall back to a microwave link. To conserve bandwidth, I will temporarily shut down both speedtest servers - then bring them back on-line when the new fiber is connected.

I thought I would post this - because the btest server has many people testing it at all times of the day.
So, when it goes down, it is not you...

North Idaho Tom Jones

Thu Jun 16, 2016 1:02 am

could you make watchdog that genarates supout before it crashes and send to support@mikrotik.com

Kristaps,
I am able to duplicate and repeat the lockup with my ROS x86 PUBLIC btest server (hosted on a MvWare ESXi server).
I will shortly be sending an email to support@mikrotik.com
I will describe in the email how to duplicate the lockup.
What happens when the ROS locks up is the following:
- No IP network access
- Console & keyboard to ROS CLI is still active
- Can not ping anything (including WAN IP address and also the 127.0.0.1 loopback IP address)
North Idaho Tom Jones

StefanM · Thu Jun 16, 2016 2:22 am

Thanks for this.

sph1nx · Sat Jun 18, 2016 8:30 am

Thank you for the endeavor and for sharing this with the community. As a home user I must say I'm pretty happy about my speedtest results:
status: done testing
duration: 31s
rx-current: 305.7Mbps
rx-10-second-average: 306.0Mbps
rx-total-average: 197.7Mbps
lost-packets: 2740
random-data: no
direction: receive

Mon Jun 20, 2016 9:30 pm

Heads up
Starting this morning (Monday 6/20/2016 PST),
I am now running the Mikrotik CHR 64-Bit version or ROS.
The original x86 ROS 32-bit btest server is turned off, while we test the 64-bit CHR ROS.
The new ROS is the following:
     - Running under VMware ESXi (the same server that was hosting the 32-bit ROS btest server)
     - VMXNET3 Ethernet (paravirtulized Ethernet driver in the Mikrotik ROS) for ether1 (old 32-bit was E1000E)
     - 2 CPUs with 8-Gig ram (Old 32-bit ROS was 1 CPU with 2-Gig ram)
     - Latest ROS version (6.35.4)

If you experience anything other than normal speeds - please let me know.
ALSO - for the Mikrotik admins with a 1-gig or faster connection, please test and let me know if you are able to send & receive at the speeds you were getting in the past.
Mikrotik Bandwidth test server:     207.32.195.2
bandwidth test username:     btest
bandwidth test password:     btest

FYI: Below is the simple queue I was using on the older x86 32-bit ROS best server. I kept the same setting for the new CHR btest server.
#

/queue simple
add burst-limit=2200M/3500M burst-threshold=250M/250M burst-time=6m40s/10m max-limit=250M/250M name=3.5-Gig-send-and-2.2-Gig-receive target=""

kristaps · Tue Jun 21, 2016 12:40 am

Looks like clients having RX problems both udp and tcp, Not been able to do more then couple hundred kb to your server form different locations.

Tue Jun 21, 2016 12:56 am

Hmm,

I turned off the CCR 64-bit ROS btest server (a few minutes ago)
I turned on the ROS 32-bit ROS btest server

Tue Jun 21, 2016 1:31 am

Hmm,

I turned off the CCR 64-bit ROS btest server (a few minutes ago)
I turned on the ROS 32-bit ROS btest server

I guess I am going to need to look at what kind of bandwidth the 60 day trial license can support for throughput.
In-house I was able to send to it (from another ROS 32-bit) at near 10 gig. However - I did not measure how fast the ccr can send. Is the send speed limited (when running the built-in 60 eval license -or- do I need to do something (license) to kick up the vmxnet3 Ethernet send speed ?
North Idaho Tom Jones

Tue Jul 12, 2016 5:56 pm

Almost cool.
This morning I had somebody doing a btest to my public Mikrotik ROS 32-Bit virtual hosted server at an average of 3-Gig for about one hour - and I did not even notice a difference on my network.

stewartpe · Thu Jul 21, 2016 7:41 am

Awesome tool! For the first time, I can test end-to-end.

Thu Jul 21, 2016 8:08 pm

I just updated the public access btest server (207.32.195.2)

It is now version 6.36 (X86 ROS running as a virtual client - which is hosted on my VMware ESXi server_

I welcome the Mikrotik admins to bang away at it to help me determine if it is stable under greater than 1-gig (up to 3-gig) throughput btest loads.
Specifically I want to see if the random lockup condition has now gone/resolved under heavy loads where the simple-queue kicks in.

Paxy · Tue Jul 26, 2016 12:18 pm

Hmm, for some reason I could not connect to 207.32.195.2 using BW test in MT with TCP (user btest/btest) from Serbia.
Is it just some temp issue, or is this project done with testing ?

Great job anyway !

Tue Jul 26, 2016 6:05 pm

Hmm, for some reason I could not connect to 207.32.195.2 using BW test in MT with TCP (user btest/btest) from Serbia.
Is it just some temp issue, or is this project done with testing ?

Great job anyway !

Sorry about the can't connect.
The problem is the x86 ROS keeps locking up.
From what I think I am seeing, it appears that if somebody continues a btest bandwidth test - and my simple queue kicks in to limit them to 250 meg - and the test continues, then sometimes the TCP/IP stack on my ROS x86 takes a dump and no longer talks. The console is still responsive but nothing IP talks. When my ROS does this, it can not even ping the loopback address 127.0.0.1 - it acts like all IP traffic is just turned off. From the console, I still have CLI commands to the ROS. To get my btest ROS server back on-line, I have to reboot the MIkrotik ROS.
North Idaho Tom Jones

mrz · Tue Jul 26, 2016 6:20 pm

For virtualized environment you should try CHR image.

Chupaka · Tue Jul 26, 2016 6:25 pm

also, Watchdog should help in that case

Tue Jul 26, 2016 6:38 pm

also, Watchdog should help in that case

I do use Watchdog
I also have my own custom watchdog.
I do not know whey they are not working when the x86 ROS IP stack dies ??? Something I will need to study when I have the free time.
A note - Even if the watchdog was working - A watchdog is not a fix for the underlying problem - at best a watchdog would be network effecting reboot.
One issue with the Mikrotik watchdog is --- when the simple queue kicks in and starts dropping packets in a RED (Random Early Detect) condition, the simple queue can and will also drop watchdog packets - which will result in un-needed reboots.
My watchdog (netwatch with a script) should be working but for some reason it is not. My watchdog (netwatch-script-reboot) script will retry many times then perform a reboot after continued/extended ping failures - where the stock Mikrotik watchdog will reboot upon a single ping failure.
Thus with only the Mikrotik stock watchdog - the ROS is subject to rebooting during a btest - thus the reason I do not use it.
North Idaho Tom Jones

Tue Jul 26, 2016 11:30 pm

For virtualized environment you should try CHR image.

I thought I replied to this this morning - but I must of forgot to hit the post button.
The reason I use X86 ROS for the btest server is because I received a free complimentary license from Mikrotik and I used it to activate the X86 ROS 32-bit btest server.

FYI - I did try the free version of CHR but I hit some snags :
- The CHR free license does not support high-throughput on the Ethernet. The free license has a limitation of only a few meg throughput on the Ethernet which prevents somebody from performing a btest in the hundreds or gigs of bandwidth to support a remote admin running a btest at 1-gig or even multi-gig throughput best.
North Idaho Tom Jones

Tue Jul 26, 2016 11:44 pm

You can activate 2months unlimited trial license for free. After that period you loose only the update ability. If you need to update you can freely regenerate the system Id and activate new trial license again.

Wed Jul 27, 2016 1:01 am

Sorry about that - the btest server went down again.
I just rebooted it so it should be up again.

Sometime within a week or so - I may give CHR another trial run.

Chupaka · Thu Jul 28, 2016 12:06 am

One issue with the Mikrotik watchdog is --- when the simple queue kicks in and starts dropping packets in a RED (Random Early Detect) condition, the simple queue can and will also drop watchdog packets - which will result in un-needed reboots.

but if 127.0.0.1 is not pingable after crash, you may use it - it should not be affected by queues

Thu Jul 28, 2016 12:23 am

One issue with the Mikrotik watchdog is --- when the simple queue kicks in and starts dropping packets in a RED (Random Early Detect) condition, the simple queue can and will also drop watchdog packets - which will result in un-needed reboots.
but if 127.0.0.1 is not pingable after crash, you may use it - it should not be affected by queues

When the X86 ROS server dies, I have the following conditions then:
- Console is still responsive
- noting talks IP
- I can not ping 127.0.0.1
- The console CLI appears to look normal - but no IP to anything
- A console CLI reboot does work ( after a reboot - the btest server is on-line and working again )

Chupaka · Thu Jul 28, 2016 2:56 am

That's why I say: set Watchdog Address to 127.0.0.1

Thu Jul 28, 2016 3:04 am

That's why I say: set Watchdog Address to 127.0.0.1

Mikrotik watchdog now set to 127.0.0.1

Fri Jul 29, 2016 3:56 am

Another lockup
- the Mikrotik watchdog to 127.0.0.1 did NOT reboot the X86 ROS router
- A console CLI system-reboot did properly reboot it. After the reboot, it was back online.

Prior to me doing the CLI reboot, I verified the ROS could not ping anything (itself 207.32.195.2 & gateway 207.32.195.1 & 127.0.0.1 loopback)
The only thing in the IP-arp print list (arp table) was the 207.32.195.2 mikrotik itself.

This bring up a question as to why it did not watchdog auto-reboot -
My question is - does the watchdog use a special call or function via an IP stack to the 127.0.0.1 to make a watchdog reboot command to itself ?

The reason I ask is that I have seen some devices with CLI commands which the command is actually talking to itself on 127.0.0.1 to do some things passed to it from the CLI or programs or other ...

--- Some other background information ---
my VMware ESXi server hosting this X86 ROS has several other router/nat virtual hosted servers on it also (Pf Sense). The other devices all have 10-gig links (vmxnet3) never have a problem.

Fri Jul 29, 2016 8:22 am

It would be good you could make a supout before reboot and just after the reboot and send them to mikrotik. They are sometimes able to find the reason and correct it.

mrz · Fri Jul 29, 2016 11:49 am

Watchdog on x86 is currently broken.

spaxton · Fri Jul 29, 2016 2:04 pm

My VM MikroTik server should have 1/1 Gbps but according to this measuring it is not like that... Unless there are too many people testing at the moment.

Here are my test results:

Both directions UDP

Unnamed QQ Screenshot20160729125249.jpg

Only Upload

Unnamed QQ Screenshot20160729125325.jpg

And only Download

Unnamed QQ Screenshot20160729125416.jpg

Thank You for providing us this. It is very useful.

Best Regards!

Fri Jul 29, 2016 6:11 pm

Heads up
Potential slower-than-normal bandwidth btest results to my 207.32.195.2 ROS btest server - every last weekend of the month.

The reason for possible slower than normal results:
My company "Red-Spectrum Communications" now has an all-customer wide-open no-bandwidth-limitations every last-weekend of the month.

Every Friday (normally towards the end of the day) prior to the last weekend of the month -and- Saturday -and- Sunday -and- Monday morning, we remove all speed-limits to all of our customers (thousands of customers). All of our fiber-to-the-home customers become 500 meg up/down accounts -and- all of our Microwave customer have no limits.
We do this for the following reasons:
-1) We have the bandwidth to support this
-2) Customers experience much faster connections than normal. It helps to encourage our customers to upgrade their paid-for bandwidths they are purchasing from us.
-3) It gives us an opportunity to load-stress-test our network and look for areas in our network which could use improvements

Although we only have a 10-gig connection Internet feed - we have discovered the total average customer bandwidth only jumps up an additional 150 percent during the last weekend of the month.

Anyways - when we do this every last weekend of every month, it has the potential to effect your test results to our 207.32.195.2 btest server.

North Idaho Tom Jones

spaxton · Fri Jul 29, 2016 7:03 pm

Heads up
Potential slower-than-normal bandwidth btest results to my 207.32.195.2 ROS btest server - every last weekend of the month.

The reason for possible slower than normal results:
My company "Red-Spectrum Communications" now has an all-customer wide-open no-bandwidth-limitations every last-weekend of the month.

Every Friday (normally towards the end of the day) prior to the last weekend of the month -and- Saturday -and- Sunday -and- Monday morning, we remove all speed-limits to all of our customers (thousands of customers). All of our fiber-to-the-home customers become 500 meg up/down accounts -and- all of our Microwave customer have no limits.
We do this for the following reasons:
-1) We have the bandwidth to support this
-2) Customers experience much faster connections than normal. It helps to encourage our customers to upgrade their paid-for bandwidths they are purchasing from us.
-3) It gives us an opportunity to load-stress-test our network and look for areas in our network which could use improvements

Although we only have a 10-gig connection Internet feed - we have discovered the total average customer bandwidth only jumps up an additional 150 percent during the last weekend of the month.

Anyways - when we do this every last weekend of every month, it has the potential to effect your test results to our 207.32.195.2 btest server.

North Idaho Tom Jones

Thanks for the info. I will test again tomorrow.

Best Regards.

Sent from my Redmi Note 2 using Tapatalk

Fri Jul 29, 2016 7:32 pm

spaxton - questions for you

- Are you testing using a virtual ROS ?
If so ...
- What hardware and operating system & version are you using ?
- What kind on network cards are you using on your virtual ROS ?
- Are you using X86 ROS or the cloud 64-bit version ?
- What do you get when you test to your local loopback address 172.0.0.1 for a btest ?

( me - I use E1000E network card on my virtual ROS. I get about 17 gig on a btest to 127.0.0.1. - Also I get about 9.5 gig between two different ROS systems (each hosted on two different physical servers).

North Idaho Tom Jones

spaxton · Fri Jul 29, 2016 8:23 pm

spaxton - questions for you

- Are you testing using a virtual ROS ?
If so ...
- What hardware and operating system & version are you using ?
- What kind on network cards are you using on your virtual ROS ?
- Are you using X86 ROS or the cloud 64-bit version ?
- What do you get when you test to your local loopback address 172.0.0.1 for a btest ?

( me - I use E1000E network card on my virtual ROS. I get about 17 gig on a btest to 127.0.0.1. - Also I get about 9.5 gig between two different ROS systems (each hosted on two different physical servers).

North Idaho Tom Jones

Hi friend,

I am using x86 64 bit on a virtual machine on proxmox. The machine is supermicro with intel atom processor while the network card is intel E1000E. I could also choose RTL. Testing to 127.0.0.1 resulted with 1800 Mbps. Just tested it with TCP and it shows about 5 Gbps.

That's how my configuration looks like in few words.

Best Regards.

Sent from my Redmi Note 2 using Tapatalk

l781 · Wed Aug 10, 2016 1:13 am

thanks a lot for usefull tool!

my result is 400M/400M over 25 hops (Lithuania).

Wed Aug 10, 2016 7:19 pm

Good news
I now have a 2nd best server
This 2nd btest server is intended for low-speed long-term btest connections
(( This new 2nd btest server is not intended to test bandwidth throughput ))
(( This new 2nd btest server is intended to test long-term connectivity ))

Here are the details:
IP address: 207.32.195.10
User: btest
Passowrd: btest
Local Tx Speed: 25k
Remote Tx Speed: 25k

Duration of your long-term test to this server are not to exceed 7 days

Please set your Tx Speeds to 25k ! If you do not set your Tx Speeds to 25k, then you will create problems for other simultaneous users of this server testing at the same time.

Like any new server - there may be a few kinks to fine-tune and work out.

ffathoni · Tue Aug 16, 2016 7:40 am

hi tom, wonderful job for providing this test server.
however I can't connect to your 207.32.195.2, is it down again?

thanks

Tue Aug 16, 2016 5:45 pm

hi tom, wonderful job for providing this test server.
however I can't connect to your 207.32.195.2, is it down again?

thanks

Yup - it was down again.
I did a system - reboot. It should be up again

The last thing I spotted in the logs was: ... 91.39.152.5 via dude
The way I look at it is that no matter what 91.39.152.5 was doing, it should not of caused a crash (if there was anything related between dude and the crash).
Question for admin of 91.39.152.5 - cat you bang away again at my 207.32.195.2 - I would like to test to see if there is something that will repeat the crash

North Idaho Tom Jones

Wed Aug 17, 2016 4:19 pm

Question for others who use x86 ROS

Am I the only person experiencing x86 ROS problems ?
or
Am I the only person pushing an x86 ROS beyond 1 gig throughput with a 10-gig network interface in a virtual environment ?

On a related note...
I have many times tried x86 ROS in a 10-gig multi-Ethernet environment under sustained loads from 500 meg to 8 gig. I have never been able to trust an x86 ROS because they often just lock-up and stop routing. I know my hardware is good and my hypervisor (ESXi) is good because the same VMware boxes also run dozens of PfSense virtual routers/firewalls at the same loads (up to 8 gig sustained).

Sometimes I wonder are the X86 ROS lockup problems are because ROS does not support or have paravirtual drivers (for things like Ethernet & hdd),
i
This btest server 207.32.195.2 has been driving me nuts - since I started it this year - it has locked up well over 100 times !!!!!!!! I have replaced all hardware and rebuilt everything at least a dozen times.
If I had to give ROS (x86) a score for reliability under load , I am sorry to say it would be low (close to zero).
If I had to give PfSense a score for reliability under load, I would give it a score close to 100.
I uave used both for many years. I really like and totally trust Mikrotik wireless products and Mikrotik hardware. I just can't say the same about their x86 ROS products - not good.

North Idaho Tom Jones

Thu Aug 18, 2016 10:57 am

Have you tried chr instead x86? Not sure, maybe could be better in your situation..

Thu Aug 18, 2016 4:12 pm

Have you tried chr instead x86? Not sure, maybe could be better in your situation..

Yes and no

I have tried it. I do not have a CHR license key. The free version has built-in speed limitations. Without looking it up again I think it was something like 1-meg (or somewhere slowwww and un-useable).

So - yes - I could run CHR with the free license, but btest will top out at the whimpy speeds of about 1-meg tops (or what ever the CHR free license sets the maximum throughput at).

A note - Right now - I do have many remote admins performing regular btest tests several times a day at speeds greater than 1-gig. So, that tells me that those testing at speeds greater than 1-gig are probably on 10-gig hardware and probably on 10-gig Internet connections (like me).

North Idaho Tom Jones

Sat Aug 20, 2016 9:20 pm

You can get unlimited trial chr license for free. It will just block updates after two months.... For testing it is great.

Tue Aug 23, 2016 7:37 pm

As of 8/23/2016 9:15 AM PST the btest server is now running on CHR
(CHR, 64-bit, VMXNET-3, 4-Gig ram memory, 128 MB hard disk, 2-CPUs)
I am running VMware ESXi version 6.0.0 to host the Mikrotik ROS CHR btest server

License; not-configured (it will eventually time-out for updates)

btests to itself:
When performing a btest to 127.0.0.1 UDP, it hits 17.5 Gbps (without simple-queue enabled)
When performing a btest to 207.32.195.2 UDP, it hits 17.5 Gbps (without simple-queue enabled)

For Mikrotik admin public best testing, I currently have simple queues enabled:
/queue simple
add burst-limit=2200M/3500M burst-threshold=250M/250M burst-time=6m40s/10m max-limit=250M/250M name=3.5-Gig-send--and--2.2-Gig-receive target=""

To test to it, the same info applies:
IP address 207.32.195.2
user: btest
passowrs: btest

Everybody is welcome to bang away at it. I think we would all like to find out how stable it is under gig+ btest loads
Please post your positive or negative results - thank you

North Idaho Tom Jones

format19 · Wed Aug 24, 2016 4:15 pm

Using 207.32.195.2
I cant seem to get more than 300-800Kbps on TCP Download?

Are others having an issue like this ?
Thanks

novelty22 · Wed Aug 24, 2016 4:52 pm

Using 207.32.195.2
I cant seem to get more than 300-800Kbps on TCP Download?

Are others having an issue like this ?
Thanks

That's about what I'm getting as well

Wed Aug 24, 2016 8:39 pm

TCP verses UDP

UDP is a fire a packet and forget protocol. With UDP you can send many packets. Over long distance links UDP should somewhat retain pretty fast speeds.

TCP is a fire a packet and wait for an ACK from the remote side protocol. With TCP, you have to wait for the remote ACK to be received prior to sending the next packet. As distance and hops and network routers increase, TCP will slow down.

Additional information:
TCP uses RED (Random Early Detect) which helps govern speeds. When there is no ACK received in a short time, the sending unit starts to learn how fast it can send before there are packet drops.
UDP does not use RED. Some protocols using UDP might send many many packets and receive a summary of received packets.

UDP is: fire - fire - fire -fire - fire - fire - fire
TCP is: fire - wait for ACK - fire - wait for ACK - fire - wait for ACK - fire - wait for ACK - fire - wait for ack - fire - wait for ACK - fire - wait for ACK
(Just looking at the two above lines I typed in - I hope you can get an idea why UDP is sometimes a better protocol and why TCP is sometimes a better protocol.

North Idaho Tom Jones

biland · Thu Aug 25, 2016 9:03 am

i love this Tool
but today i also get only 700 to Max 900 Kbps on tcp receive,, down here in Mexico..
upload is working fine

gwitowski · Thu Aug 25, 2016 7:01 pm

Hello. I'm from Poland. Your server is doing a great job, but for a few days, my score is 800 - 900 Kbps. If you can then do something with it. Thank you.

Thu Aug 25, 2016 11:23 pm

Hello. I'm from Poland. Your server is doing a great job, but for a few days, my score is 800 - 900 Kbps. If you can then do something with it. Thank you.

re for a few days ...
Are you stating something like -- for a few days it is now slower results - or faster results

A few days ago - I changed the 207.32.195.2 btest server
It was a x86 ROS 32-bit server
It is now a CCR ROS 64-bit server

North Idaho Tom Jones

gwitowski · Fri Aug 26, 2016 9:05 am

Hello. I'm from Poland. Your server is doing a great job, but for a few days, my score is 800 - 900 Kbps. If you can then do something with it. Thank you.
re for a few days ...
Are you stating something like -- for a few days it is now slower results - or faster results

A few days ago - I changed the 207.32.195.2 btest server
It was a x86 ROS 32-bit server
It is now a CCR ROS 64-bit server

North Idaho Tom Jones

Hello. Previously, it was OK. I have a link 200Mbps / 200Mbps, and my results are only 800 - 900 Kbps if I test download from your server to me. Upload to your server is OK.

Fri Aug 26, 2016 6:13 pm

Hello. I'm from Poland. Your server is doing a great job, but for a few days, my score is 800 - 900 Kbps. If you can then do something with it. Thank you.
re for a few days ...
Are you stating something like -- for a few days it is now slower results - or faster results

A few days ago - I changed the 207.32.195.2 btest server
It was a x86 ROS 32-bit server
It is now a CCR ROS 64-bit server

North Idaho Tom Jones

Hello. Previously, it was OK. I have a link 200Mbps / 200Mbps, and my results are only 800 - 900 Kbps if I test download from your server to me. Upload to your server is OK.

OK - I see the problem/issue also.
The new CHR ROS 64-bit server is the problem.
This morning (Friday 8 AM PST), I went back to the x86 ROS 32-bit system.
Now I am seeing great btest speeds again (faster than 7 Gig) btest results.
Please test and verify you are now testing at full speeds.

I am just not sure how I feel about the CHR ROS 64-bit system. Without a full paid-for license, it is not useable for close to 1-meg throughput or greater.

North Idaho Tom Jones

gwitowski · Sat Aug 27, 2016 10:28 am

Hello. I'm from Poland. Your server is doing a great job, but for a few days, my score is 800 - 900 Kbps. If you can then do something with it. Thank you.
re for a few days ...
Are you stating something like -- for a few days it is now slower results - or faster results

A few days ago - I changed the 207.32.195.2 btest server
It was a x86 ROS 32-bit server
It is now a CCR ROS 64-bit server

North Idaho Tom Jones

Hello. Previously, it was OK. I have a link 200Mbps / 200Mbps, and my results are only 800 - 900 Kbps if I test download from your server to me. Upload to your server is OK.
OK - I see the problem/issue also.
The new CHR ROS 64-bit server is the problem.
This morning (Friday 8 AM PST), I went back to the x86 ROS 32-bit system.
Now I am seeing great btest speeds again (faster than 7 Gig) btest results.
Please test and verify you are now testing at full speeds.

I am just not sure how I feel about the CHR ROS 64-bit system. Without a full paid-for license, it is not useable for close to 1-meg throughput or greater.

North Idaho Tom Jones

Today is Ok. Thank you for solving the problem. Your server is doing a really good job.

jrpaz · Sat Aug 27, 2016 9:22 pm

Doing good work sir!

Sun Aug 28, 2016 9:31 am

Sorry you had not so good experience with chr. I am running dude in testing mode so far on chr with trial unlimited free license and I don't see any interface performance problems.

mrz · Mon Aug 29, 2016 1:51 pm

Only free license is limited to 1Mbps, you can run 60-day trial to get this limitation off.
http://wiki.mikrotik.com/wiki/Manual:CHR#Free_licenses

dsliesrn · Tue Sep 20, 2016 2:19 pm

Hi, I can not connect to the server. It is down?

Thanks

Tue Sep 20, 2016 5:55 pm

Hi, I can not connect to the server. It is down?

Thanks

YES - It was down again
I rebooted it this morning.
FYI - I am still currently running the 32-BIT ROS x86 version.
Sometime, I plan to try again to test out the 64-bit version - when I have time.

North Idaho Tom Jones

tljatrezmaildotcom · Tue Sep 20, 2016 8:36 pm

I use this test server all the time - it works great

Wed Sep 21, 2016 6:45 am

10-gig fiber network outage & spanning-tree fall back to a low-speed microwave up-link.
So - I had to turn off the 207.32.195.2 btest server to help conserve bandwidth for my customers.
Sorry about that - It should be backup around 8 am California time (my time zone here in North Idaho).

North Idaho Tom Jones

paams · Tue Sep 27, 2016 1:43 pm

Great Tool and Great Service. I really appreciate. Keep it up

Tue Sep 27, 2016 6:34 pm

Every morning - first thing, I check my Cacti bandwidth graphs for my entire network to see who is pulling what amount of abnormal bandwidth traffic.
It is sometimes WTF when you discover a huge spike on your Internet traffic by several gig-per-second then realize it was only the 207.32.195.2 btest server - lol

Which brings up a question I have to those who often use it.
My question is, for those with fast Internet accounts (high bandwidth), are your throughput btest results to 207.32.195.2 consistent ?

North Idaho Tom Jones

Thu Sep 29, 2016 10:03 pm

Yesterday - I upgraded the 207.32.195.2 public access btest server. I tested it after the upgrade - everything looked good.

However ... I forgot to re-enable the simple-queue to limit the bandwidth test so that it can't consume my entire 10-gig internet feed...
Well ... Yesterday - somebody got a lengthy 6 gig+ btest -and- somebody else got a 4 gig+ btest - lol

My bad - lol.
I will try to not forget about the simple queue - because I do not want to saturate my 10-gig Internet feed or somebody else with a 10-gig feed testing to me and relying on my simple queue to not kill their feed also.

Related info - I have seen it hit up to 9.8 gig on a btest to somebody remote out on the Internet testing to me a few months ago...
And - if any of you ever want to perform a quick btest higher than 4-gig, let me know and I can setup something temporary just for you.

North Idaho Tom Jones

040mvz · Fri Sep 30, 2016 3:57 pm

Peaking the max of my 500/500MBIT FTTH with ISP KPN in The Netherlands!

Thanks a lot! this helped me great!

Fri Sep 30, 2016 5:47 pm

Peaking the max of my 500/500MBIT FTTH with ISP KPN in The Netherlands!

Thanks a lot! this helped me great!

You are most welcome.
That is exactly the reason I have this 207.32.195.2 btest server running. So that we can all test and verify our contracted Internet speeds - and take possible actions to correct an environment where we/you do not get what we are paying for.

North Idaho Tom Jones

PeterO · Wed Oct 05, 2016 12:47 pm

Works also perfectly from the Netherlands.
Got my full 200 Mb Down and 20 Mb Up!

Wed Oct 05, 2016 6:29 pm

Works also perfectly from the Netherlands.
Got my full 200 Mb Down and 20 Mb Up!

Thank you
Posting your test results also help me know my network is talking correctly to the Internet also.

North Idaho Tom Jones

Wed Oct 05, 2016 7:12 pm

FYI - This is a Cacti bandwidth graph of the last 24-hours of my 207.32.195.2 btest server.
The needle like spikes indicate a 5-minute average of the bandwidth (up/down).
Thus a 3 Gig btest executed for only a few seconds may only show a very small spike in the graphs.
The far right of the graph indicates a 180 meg btest. This could of been a 180 meg btest for 5 minutes - or a 360 meg btest for 2.5 minutes or 900 meg btest for 1 minute or a 1.8 gig btest for 30 seconds or a 2.7 gig btest for 20 seconds.

As you can see, the total traffic for 24 hours is actually pretty low (which averages out to a 24-hour total load of about 45 meg sustained over 24-hours), but the real-time-traffic-spikes can actually be very high - especially when I have the simple-queue disabled.

24-hours-btest-server.png

North Idaho Tom Jones

Chupaka · Thu Oct 06, 2016 10:05 pm

Tom, I heard this server is quite popular among RouterOS admins

If you do not mind, I'd like to make this topic sticky on the forum so it stay on top

Fri Oct 07, 2016 12:31 am

Tom, I heard this server is quite popular among RouterOS admins

If you do not mind, I'd like to make this topic sticky on the forum so it stay on top

Hey - you are more than welcome
Everybody is welcome to btest to it.
*** thank goodness for simple-queues

--- otherwise my network could saturate at 10 gig lol

Also - I am open to the idea of other test servers doing other mikrotik related things (tunnel test - vpn test - or what ever could help out the Mikrotik community )

North Idaho Tom Jones

Fri Oct 07, 2016 7:07 pm

Good news everybody

I just increased the simple-queue settings for the 207.32.195.2 btest server.

The btest server now supports 3.6 Gig testing speeds.

The new speed settings are supported for both send & receive tests (up & down settings are now identical)

I also increased the time duration for how long a 3.6 Gig test can run before it throttles down to a lower speed.

I also increased the sustainable extended btest server to now support a continuous 1/2 Gig (500 Meg)

NOTE: I have a few points I would like to clearly state:
- Do not abuse this btest server
- Do not use this btest server to create/generate unwanted & undesired saturation issues with your Internet provider
- If and when there are two or more tests occurring at the same time (two or more different remote Internet locations at the same time), the simple-queue will rate-limit the combined tests of everybody. Example - two admins can not test at 3.6 gig at the same time.
- If you run an extended test - you are also preventing others from bursting to 3.6 Gig or also running an extended btest
- You are welcome and encouraged to post your tested speeds and where you are located
- This btest server is solely intended to support the good purposes and good intentions of all Mikrotik admins

To use this btest server, perform a Mikrotik ROS bandwidth test to 207.32.195.2 (test user name is: btest -and- test password is: btest)

North Idaho Tom Jones
Below are some screen snapshots of the simple-queue settings:

Tue Oct 11, 2016 3:46 am

Sorry about that - It locked up again and I had to reboot it.

CZFan · Sun Oct 16, 2016 6:54 pm

Hi Tom,

Seems like an excellent tool for the Miktotik community, thx for providing

I am unable to connect though and not sure I am doing something wrong or if it is down at the moment, I am connecting to 207.32.195.2 with usr/pwd btest?

Kind regards from South Africa

lty1993 · Sun Oct 16, 2016 7:13 pm

Looks like the server down again, and I cannot even ping the server.

Screenshot from 2016-10-16 16-05-23.png

NetHorror · Wed Oct 19, 2016 12:10 pm

can`t connect

silversword · Wed Oct 19, 2016 7:50 pm

Thx Tom!

FYI testing from Atlanta, GA on AT&T Gigapower.
btest from mikrotik hardware (CPU throttled)
DSL reports and speedtest.net for comparison (fastpath enabled only way to get high speeds without CPU bottleneck)
Can't connect via UDP, only TCP. Wouldn't be surprised if AT&T is filtering UDP out at their interconnects so their backbone doesn't get flooded with infected devices.
VPN tunnel test anyone?

Tested with windows Mikrotik bandwidth test util (v0.1) and was only getting 10-20Mbps, not sure why.

jasko · Wed Oct 19, 2016 8:19 pm

Hello Tom,

Thanks you to offer this tool for free.

Here are the results of my test:
[img]

btest.png

[/img]

I would ask you: How to configure a user to just have permission on the banwidth-test tool of the server?

thanks in advantage

Wed Oct 19, 2016 9:50 pm

jasko - re I would ask you: How to configure a user to just have permission on the banwidth-test tool of the server?

Rather than type the answer to your question, I just made some image snapshots.
Is this what you was asking for ?

North Idaho Tom Jones

btest-user.png

Wed Oct 19, 2016 9:54 pm

silversword - re: Can't connect via UDP, only TCP

Interesting ...
Are you behind a firewall ?
Is your test device on a live IP address ?

devices/programs/computers/servers talking on the Internet need both TCP and UDP

North Idaho Tom Jones

Wed Oct 19, 2016 10:20 pm

Can't hurt asking ...

Anybody want to donate a Mikrotik with a 10-gig port to replace my x86 32-bit 207.32.195.2 btest server ?

I would like to find a hardware solution Mikrotik something that can btest up to near 10-gig (or at least 4-gig).

I would like to see the stability & throughput difference .

anybody - Mikrotik how about you ????

North Idaho Tom Jones

silversword · Thu Oct 20, 2016 1:13 am

silversword - re: Can't connect via UDP, only TCP

Interesting ...
Are you behind a firewall ?
Is your test device on a live IP address ?

No firewall, live public IP from AT&T Uverse, the Gigapower division.

It's consumer 1Gbit, so I'm sure they have protection mechanisms for large quantities of UDP traffic aiming across the Atlantic

If I had a closer server with btest listening I'd test that...nothing setup atm.

Thu Oct 20, 2016 1:46 am

silverswood

What do you get when you do the same traceroute again but this time using UDP instead of icmp ?

North Idaho Tom Jones

silversword · Thu Oct 20, 2016 5:59 am

What do you get when you do the same traceroute again but this time using UDP instead of icmp ?

....you can traceroute with UDP. My "learned something new" for the day! Makes sense if you think about it though.

Re-testing apparently it's only the receive part I'm not getting...though quite slow, guessing a 1Mbps limit.

Considering you're trying to "receive" a UDP, there must be a tcp control channel for the btest that is telling the btest server to send udp at you, so somewhere it must be dropping it. I'll send you a PM with my IP and btest server if you'd like to test.

Thu Oct 20, 2016 7:06 pm

silverswood

Based on your last traceroute - I just noticed you are coming from an RFC-1918 NAT network (10.x.x.x).
This implies you have a firewall/NAT device between your Mikrotik and the Internet.
The firewall/NAT device may need a port-forward so that Mikrotik UDP packets from the Internet are forwarded to your internal Mikrotik.
This may be starting to sound more complex to configure than the time you may want to invest just to be able to perform a btest to-and-from my 207.32.195.2 btest server.

What might be easier would be to move and reconfigure your Mikrotik to be the live IP address NAT device for your RFC-1918 internal 10.x.x.x network. Then you should be able to perform UDP btests in both directions - and it may give you more control over what your network is doing.

North Idaho Tom Jones

Jeroen1000 · Thu Oct 20, 2016 9:07 pm

Just wanted to say thanks for your server. I've been able to test both my connections. One weird Mikrotik thing found: when uploading (10 megabit) the test server process makes a routerbord 450G's CPU spike to 100%. When just doing a speedtest on speedtest.net, it does not go over 10%

Fri Oct 21, 2016 10:02 am

Because btest is very cpu hungry while generating traffic.

silversword · Fri Oct 21, 2016 4:16 pm

Based on your last traceroute - I just noticed you are coming from an RFC-1918 NAT network (10.x.x.x).
This implies you have a firewall/NAT device between your Mikrotik and the Internet.
The firewall/NAT device may need a port-forward so that Mikrotik UDP packets from the Internet are forwarded to your internal Mikrotik.
This may be starting to sound more complex to configure than the time you may want to invest just to be able to perform a btest to-and-from my 207.32.195.2 btest server.

No, the 10. is the private side of the Mikrotik. traceroute must default to the default internal private bridge unless specified otherwise.

Running the btest directly from the Mikrotik using winbox.

jllz · Fri Oct 21, 2016 11:12 pm

So It looks like my routers running 6.37 and 6.37.1 just shows 0 my routers with older firmware work with it tho.

Sat Oct 22, 2016 2:14 am

Instead of trying BOTH, try send by itself then try receive by itself.
Also you might want to try and verify you can ping 207.32.195.2 (the btest server)

North Idaho Tom Jones

jllz · Mon Oct 24, 2016 4:17 pm

So looks like it works with tcp but not udp.

gardenstate · Thu Oct 27, 2016 8:00 pm

Thank you for this service, NI Tom Jones.

(BTW, grew up in the Panhandle up near Murray.)

Thu Oct 27, 2016 8:45 pm

Thank you for this service, NI Tom Jones.

(BTW, grew up in the Panhandle up near Murray.)

Murray Idaho - Originally started as a mining camp back in the 1880s. Lots of trees, mountains and critters. Small community but a very beautiful place.
I am actually in Plummer Idaho - about 30 minutes or so south of Coeur d'Alene.

North Idaho Tom Jones

netflow · Sat Oct 29, 2016 6:05 pm

Thanks for the service Tom. It is a great alternative to speedtest. I hope you can keep it running despite its increasing notoriety.

Note to other testers: Windows v0.1 client is not up to the level of the ROS client. It should be avoided for any realistic figures.

RonJohn63 · Wed Nov 02, 2016 11:05 pm

(Had to temporarily disable the FW rule on dropping all WAN packets.)

Otherwise, it matches well with my 150/10 cable tier.

[admin@MikroTik] /tool> /tool bandwidth-test address=207.32.195.2 user=btest password=btest \
 	duration=00:01:00 direction=receive random-data=yes protocol=udp
                status: done testing
              duration: 1m1s
            rx-current: 163.0Mbps
  rx-10-second-average: 163.0Mbps
      rx-total-average: 146.3Mbps
          lost-packets: 1571
           random-data: yes
             direction: receive
               rx-size: 1500
[admin@MikroTik] /tool> /tool bandwidth-test address=207.32.195.2 user=btest password=btest \
	duration=00:01:00 direction=transmit  random-data=yes protocol=udp
                status: done testing
              duration: 1m1s
            tx-current: 10.8Mbps
  tx-10-second-average: 10.8Mbps
      tx-total-average: 11.1Mbps
           random-data: yes
             direction: transmit
               tx-size: 1500

interpoint · Thu Nov 03, 2016 10:17 pm

Greetings from Ireland !!

Firstly: Many thanks for providing this very useful btest facility.

We also had problems with the CHR's running on VMware ESXi 6.0 using Hotlava 10G Cards.

We experienced the VMware host would "Pink Screen of Death" complaining about the Network card approx once every 6 weeks approx.

We gave up and moved to CHR1072. It is not as good for BGP convergence on a CCR1072, however it doesn't crash - which is way more important

BGP Convergence of 1080219 routes to the Internet is around 20 minutes after startup. Single core limitation.

Did this test from one of our CCR1072's - she was RX'ing at 1G of live traffic at the time when I ran this test.

We have a 10G connection to the Internet on the CCR1072

Interesting that I can pull 2Gbps (on the RX) from your test server but can only manage 1.2Gbps (TX) to your test server.

[XXXXX@CCR1] > /tool bandwidth-test direction=receive local-tx-speed=2000M remote-tx-speed=2000M user=btest password=btest protocol=udp address=207.32.195.2
status: running
duration: 10s
rx-current: 1917.1Mbps
rx-10-second-average: 1918.8Mbps
rx-total-average: 1918.8Mbps
lost-packets: 0
random-data: no
direction: receive
rx-size: 1500

[XXXXX@CCR1] > /tool bandwidth-test direction=transmit local-tx-speed=2000M remote-tx-speed=2000M user=btest password=btest protocol=udp address=207.32.195.2
status: running
duration: 14s
tx-current: 1219.2Mbps
tx-10-second-average: 1180.7Mbps
tx-total-average: 1153.7Mbps
random-data: no
direction: transmit
tx-size: 1500

I have 19 hops between your router and mine.

capture.jpg

Fri Nov 04, 2016 5:26 pm

interpoint

Greetings from Ireland !!

Firstly: Many thanks for providing this very useful btest facility.
....

Hey - thanks for the feedback.

I am very interested in possibly changing the 207.32.195.2 btest server from a 32-bit ROS system running under VMware ESXi 6.something to a physical mikrotik hardware solution with 10-gig network cards.
I know that btest only uses 1 CPU when there are multi-cores available. Thus a btest server comes down to CPU clock speed to function well as a btest server.
So - I would like to ask you a favor please
On any of your Mikrotik platforms with 10-gig Ethernet, what do you get when you do a UDP btest to 127.0.0.1 ???
If I can find something that cat run at or near 10-gig, I want to try to switch the 207.32.195.2 btest server over to it - then see if it can handle the load while still delivering same speed results.

again - thanks for your post

North Idaho Tom Jones

Makoto · Tue Nov 08, 2016 10:51 am

Hi,

is servers still runing ? I did try few times last couple of days but never able to connect !

It would be so cool if Mikrotik has someting like that for at least 100Mbit test:)!

Tue Nov 08, 2016 2:42 pm

Hi,

is servers still runing ? I did try few times last couple of days but never able to connect !

It would be so cool if Mikrotik has someting like that for at least 100Mbit test:)!

Yea it's running. Uptime about a week or so.

Tue Nov 08, 2016 7:52 pm

Hi,

is servers still runing ? I did try few times last couple of days but never able to connect !

It would be so cool if Mikrotik has someting like that for at least 100Mbit test:)!

Have you been able to test to it in the past ?
Can you ping it ?
Is your Mikrotik behind a firewall ?

RonJohn63 · Tue Nov 08, 2016 10:01 pm

Hi,

is servers still runing ? I did try few times last couple of days but never able to connect !

It would be so cool if Mikrotik has someting like that for at least 100Mbit test:)!

I had the same problem, then enabled logging on the FW rule chain=input action=drop tcp-flags="" in-interface=ether1 log=no log-prefix="" and saw tons of drops.

Thus, I added this just above that rule:

add action=accept chain=input comment="IP address of public bandwidth tester" protocol=udp src-address=207.32.195.2

Wed Nov 09, 2016 4:12 am

Well - my x86 ROS 32-bit locked up again and I had to restart it

It locked up at California USA time 2016/11/08 17:49:23 ((( 5:49 PM ))

It is back up now

I am glad I don't use this as a primary high-bandwidth router.

North Idaho Tom Jones

Makoto · Thu Nov 10, 2016 10:38 am

Hi,

no I did not able to test in the past but I am able to ping the server, maybe it is firewall but not mine !
In a few days I am geting new dedicate line I whill try then!

Thu Nov 10, 2016 3:39 pm

Hi,

no I did not able to test in the past but I am able to ping the server, maybe it is firewall but not mine !
In a few days I am geting new dedicate line I whill try then!

Hmmm

Please post a tracefoute from your mikrotik

North Idaho Tom Jones

Makoto · Fri Nov 11, 2016 10:48 am

Hi

timeout at the moment

!

I can try again later

Fri Nov 11, 2016 7:43 pm

Hi

timeout at the moment !

I can try again later

Yup - my Mikrotik ROS x86 32-bit btest server was locked up again. I reset it and it should be running again.

I have a question to everybody - does anybody have a Mikrotik anything that is actually standing up to gig+ sustained routed bandwidth loads (like what my btest server goes through) ?

North Idaho Tom Jones

jasko · Wed Nov 16, 2016 1:29 pm

jasko - re I would ask you: How to configure a user to just have permission on the banwidth-test tool of the server?

Rather than type the answer to your question, I just made some image snapshots.
Is this what you was asking for ?

North Idaho Tom Jones
btest-user.png

Thanks Tom,
that was the answer I need

Great work!!

HumanDamned · Sat Nov 19, 2016 12:11 am

Subject: Public-Mikrotik-Bandwidth-Test-Server
Here are the details for my server:
- x86 ROS hosted on VMware ESXi server (with 10-gig connection to the Internet)
- Burstable to 250 Meg up/down
- Sustained traffic is limited to 100 Meg up/down (after about 30 to 60 seconds)
- Your maximum connection time for testing is not to exceed 10 minutes.
- IP Address: 207.32.195.2
- btest user authentication needed: User: btest Password: btest
- You may NOT winbox to this machine - you may bandwidth test to it.

Hi and Thanks for the server, but i cant understand why Btest to your server shows average TCP Tx Rx 15.0 Mbps/49.5 Mbps and speedtest.net - Tx Rx 661 Mbps/641 Mbps ?
The result are so much different...

Sat Nov 19, 2016 1:53 am

Subject: Public-Mikrotik-Bandwidth-Test-Server
Here are the details for my server:
- x86 ROS hosted on VMware ESXi server (with 10-gig connection to the Internet)
- Burstable to 250 Meg up/down
- Sustained traffic is limited to 100 Meg up/down (after about 30 to 60 seconds)
- Your maximum connection time for testing is not to exceed 10 minutes.
- IP Address: 207.32.195.2
- btest user authentication needed: User: btest Password: btest
- You may NOT winbox to this machine - you may bandwidth test to it.
Hi and Thanks for the server, but i cant understand why Btest to your server shows average TCP Tx Rx 15.0 Mbps/49.5 Mbps and speedtest.net - Tx Rx 661 Mbps/641 Mbps ?
The result are so much different...

My guess would be the speedtest.net server you are testing to might be closer than my btest server.
Try a speedtest.net speedtest using Seattle and see if that looks near the same as my btest server.
Also - are you btest ing using UDP or TCP? UDP should be faster.

North Idaho Tom Jones

HumanDamned · Sat Nov 19, 2016 1:16 pm

My guess would be the speedtest.net server you are testing to might be closer than my btest server.
Try a speedtest.net speedtest using Seattle and see if that looks near the same as my btest server.
Also - are you btest ing using UDP or TCP? UDP should be faster.

Oh, I see, it's in USA, then maybe that is the reason. I'm using TCP because speedtest also uses TCP, just wanted to compare the results.
Today results are - Btest up 31.8 Mbps/ down 66.4 Mbps and speedtest to Seattle up 697 Mbps/ down 141 Mbps.
Really crazy =)

gunguy7007 · Tue Nov 22, 2016 4:16 pm

Thank you, this helps a ton in troubleshooting.

Wed Nov 23, 2016 12:55 am

I just updated the 207.32.195.2 btest server (on 11/22/2016 3:PM California time) to the new ROS release v6.37.2

North Idaho Tom Jones

Yarisken · Wed Nov 23, 2016 7:55 pm

Thx for the tool

. Working great here.

kevgits · Fri Nov 25, 2016 12:54 pm

Hi,

I'm trying to ping the server from Kenya and it's timing out. Could you kindly confirm if it's running?

C:\Users\TOSH>ping 207.32.195.2

Pinging 207.32.195.2 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

On the mikrotik it returns the error "can't connect".

fabvit · Fri Nov 25, 2016 6:05 pm

As of today for me too the server is not pingable (Rome, Italy)

dash · Fri Nov 25, 2016 10:37 pm

same here

Mon Nov 28, 2016 5:31 pm

x86 ROS under load has a MTBF (meat time before failure) of less than 1 day. This is across all versions of x86 ROS for the last year.

If you can not ping or btest to this server, it is 99.999 percent because it locked up again. This btest server sometimes has to be reset up to 3 times a day.

I can only hope that CHR or anything else is better at faster than gig btest speeds.

North Idaho Tom Jones

mp3turbo · Tue Nov 29, 2016 1:15 am

Tom, what locks up ? Is it the x86 ROS virtual machine or is the whole physical server crashing under the load ? Can you post DETAILED information about your HW config especially about NW cards their models etc, versions of BIOS, ILO/DRAC card firmware if you have HP/Dell hardware (or equivalent of other vendors') ? If you have white box ("home made" computer), please post motherboard name, BIOS version.

Ideally in both cases, screenshots of BIOS settings would be great. Especially PCI Latency Timer, if you have one.

I'm running virtualized x86 ROSes with 100.0% uptime for years and yes, I have big bandwidths.

Tue Nov 29, 2016 3:39 pm

Tom, what locks up ? Is it the x86 ROS virtual machine or is the whole physical server crashing under the load ? Can you post DETAILED information about your HW config especially about NW cards their models etc, versions of BIOS, ILO/DRAC card firmware if you have HP/Dell hardware (or equivalent of other vendors') ? If you have white box ("home made" computer), please post motherboard name, BIOS version.

Ideally in both cases, screenshots of BIOS settings would be great. Especially PCI Latency Timer, if you have one.

I'm running virtualized x86 ROSes with 100.0% uptime for years and yes, I have big bandwidths.

I am running the following configuration:
- Physical server: I have tried Dell but now I run on a SuperMicro (SAS 12 tb hdd and 127 gig ram and intel 10-gig nics and two Xeon CPUs 10-core each with a crap-load of CPU cache.)
- Boot operating system on physical server: VMware ESXi 6.0.0 (I have also run ESXi version 5.x
- btest server is an x86 ROS 32-bit server (have tried many different fresh installs from scratch).
- Virtual host (ROS) configuration: Memory 2 gig - CPUs (Tried 1,2,3 and 4) currently 1 - HDD thin 8 Gig - single Network card E1000E

I have rebuilt and replaces and reconfigured everything to do with the btest server dozens of times.

I currently have 20 other additional virtual host servers/routers also running on my VMware ESXi machine. None of the other virtual routers (PfSense) or other virtual servers (DNS, sendmail, apache, radius, syslog, cacti etc ...) ever lock up. The only thing that locks up is ROS - never anything else.

When ROS locks up, it appears to be a complete loss of the TCP/IP stack. When it is locked up, the console is still alive and there is still an Ethernet link - but anything to do with IP anything is dead. When locked up, ROS can not even ping it's local loopback address of 127.0.0.1

If I had to take a guess at what the problem is, I would start with a guess that the ROS lack of paravirtual network drivers/support is the biggest potential problem. In my opinion, any x86 operating system without full set of paravirtual (tools, HDD, network, KVM) is pretty much a trusted brick if you are building a house - and only a brick.

It is very frustrating !!! I pretty much give x86 ROS a rating (0 to 10) of a solid -8 (negative

, and I suggest in a virtual routing environment to instead use PfSense for stability to achieve a never crash virtual environment.

Don't get me wrong and think I am down/against Mikrotik - I totally love ROS and Mikrotik has the best bang for the buck when it comes to wireless products. I know - I have more than 1,000 Mikrotik wireless devices. But when it comes to central core greater than 1-gig throughput processing, this I don't feel Mikrotik is a solution. In my opinion, Mikrotik uses slow cheap wimpy weak CPUs and are unable to reliably compete in the 500 meg to over 10-gig market. I am under the option that Mikrotik has nothing that can reliably handle the sustained often greater than 1-gig btest loads my btest server gets every day. However - for small office and residential use (less than 300 meg), mikrotik has some good products to consider.

North Idaho Tom Jones

Tue Nov 29, 2016 3:46 pm

One thing I will add,

It appears that when somebody is running a btest at high speeds (800 meg up to 10-gig), is when the ROS TCP/IP stack dies.

and note - I have some PfSense virtual routers on the same VmWare server often holding that sustained amount of traffic (near 8-gig sustained) for sometimes several hours.

Thu Dec 01, 2016 6:58 pm

Subject: Public-Mikrotik-Bandwidth-Test-Server
EDIT: Feb 24 2016 --- Now supports up to 3.5 Gig speedtest - read all the posts
EDIT: October 7th 2016 --- This btest server now supports 3.6 Gig for both send and receive tests - please read through all the posts

thx very much for the server Tom

I have tested successfully a gpon connection of 120mbps/60mbps udp and tcp with a RB750Gr2

Thu Dec 01, 2016 9:57 pm

Subject: Public-Mikrotik-Bandwidth-Test-Server
EDIT: Feb 24 2016 --- Now supports up to 3.5 Gig speedtest - read all the posts
EDIT: October 7th 2016 --- This btest server now supports 3.6 Gig for both send and receive tests - please read through all the posts

thx very much for the server Tom

I have tested successfully a gpon connection of 120mbps/60mbps udp and tcp with a RB750Gr2

Re: I have tested successfully a gpon connection of 120mbps/60mbps udp and tcp with a RB750Gr2
chechito - right now you are new best friend

I am trying to bring up a Mikrotik SFP GPON in one of my Mikrotiks.
My head-end to terminate my customer GPON devices is an Adtran TA-5000

I have some questions I would like to ask you.
Is your GPON network using a Mikrotik SFP GPON in a Mikrotik ?
Or is your GPON non-Mikrotik and you simply have a Mikrotik connected ?

North Idaho Tom Jones

Fri Dec 02, 2016 1:13 am

Re: I have tested successfully a gpon connection of 120mbps/60mbps udp and tcp with a RB750Gr2
chechito - right now you are new best friend

I am trying to bring up a Mikrotik SFP GPON in one of my Mikrotiks.
My head-end to terminate my customer GPON devices is an Adtran TA-5000

I have some questions I would like to ask you.
Is your GPON network using a Mikrotik SFP GPON in a Mikrotik ?
Or is your GPON non-Mikrotik and you simply have a Mikrotik connected ?

North Idaho Tom Jones

Sorry My isp brings a CPE which receive optical fiber directly, behind it i connect MIkrotik with ethernet copper

Fri Dec 02, 2016 6:25 pm

FYI: I just upgraded the Mikrotik ROS 32-bit public btest 207.32.195.2 server to version 6.37.3

When I did this - I know I bumped somebody off who was doing a btest at the time - sorry about that

North Idaho Tom Jones

Wed Dec 07, 2016 11:57 pm

FYI: December 7th 2016
I just replaced the Mikrotik ROS 32-bit public btest 207.32.195.2 server.
It is now a CHR 64-bit system.
It is hosted on the same VMware ESXi server which hosted the older 32-bit x86 ROS server.

So far it appears to have the same throughput capabilities. A local btest to the loopback 127.0.0.1 comes out between 18 to 19 gig.

There is still a simple-queue which limits peak testing to 3.6 gig up or down (and also limits sustained testing down to about 500 meg).

You are welcome to hammer away on it.
I would like to find out and verify if CHR is more stable/reliable under the same peak loads when compared to the original 32-bit ROS btest server.

btest server: 207.32.195.2
user: btest
password: btest

Chupaka · Thu Dec 08, 2016 1:01 am

Just tested, 3.6G down (to me)/1875M up with UDP

Well... Wow

I'm from Belarus, it's 8500km from Idaho =) RTT is 185 ms

With TCP it's only 1550M down/540M up

By the way, "Lost Packets: 0" after 5 seconds at 3.6G

Thu Dec 08, 2016 2:46 am

Just tested, 3.6G down (to me)/1875M up with UDP

Well... Wow I'm from Belarus, it's 8500km from Idaho =) RTT is 185 ms

With TCP it's only 1550M down/540M up

By the way, "Lost Packets: 0" after 5 seconds at 3.6G

Hey - sounds like you have a greater than 3.6 gig internet feed
If you ever want to do a brief no bandwidth test - just let me know
It would be interesting to see what it can go up to ...
North Idaho Tom Jones

Tue Dec 13, 2016 3:34 pm

Interesting, since upgrading from 32-bit x86 ROS to CHR on December 7th 2016, the btest server has not locked-up/died.
Normally I would of performed up to 15 resets/reboots by now.
I can only guess that the paravirtulized 10-gig network card drivers "vmxnet3" are working correctly.

North Idaho Tom Jones

Wed Dec 14, 2016 6:51 pm

Hope ya don't mind if I ask ...

Would somebody happen to be running a CHR or 32-bit ROS on a Amazon Web Services (AWS) account ?

This is not a problem. I just happened to look at who was connected to the 207.32.195.2 btest server and spotted a connection from AWS.

My question for you, what kind of throughput and processing ability are you able to get with AWS ?

North Idaho Tom Jones

marting · Tue Dec 20, 2016 2:22 pm

Thank you for providing this server!

Although I wonder why ROS does not correctly track their own BTEST UDP/Receive connections. I have same issue with UDP Receving like some other in this thread. I allow ESTABLISHED&RELATED in input and forward chain. But I have to disable my REJECT chains for UDP for the BTEST packets not to drop. Of course I could allow my btest IPs but in my opinion this should be covered by the connection tracking.

yoozieck · Thu Dec 22, 2016 10:43 am

Hello,
Is there any problem with the 207.32.195.2 test server?
I cannot connect today, nor can't ping it, this is my traceroute:

but using ping.eu comes with transmitted/received packets 100% success.

Thu Dec 22, 2016 6:52 pm

Hello,
Is there any problem with the 207.32.195.2 test server?
I cannot connect today, nor can't ping it, this is my traceroute:

but using ping.eu comes with transmitted/received packets 100% success.

Yea - it was down
in fact my entire network was down
huge spanning tree issue and native vlan issues across hundreds of network devices.

It should be up and running normally now.

North Idaho Tom Jones

Thu Dec 22, 2016 7:20 pm

Heads up -
Because I am still having some network problems (non-related to Mikrotik anything), I have turned off the 207.32.195.2 public btest server.
It will remain turned off until mid next week.

North Idaho Tom Jones

Thu Dec 22, 2016 9:19 pm

new feature wish list for Mikrotik ROS and CHR

I would like to see a new feature option in the bandwidth test setting (for server and clinet), where there is a new setting for maximum amount of time a btest can be performed.

Example:
- Where somebody connected up to my 207.32.195.2 btest server (from their client ROS/CHR device) and no matter what, the test will terminate after a set number of HH:MM:SS has elapsed.

This would be great for both client and server in btest.

One of the potential issues I often see with my 207.32.195.2 btest server is that somebody starts a btest to me and lets it run all night long. This can force the simple-queue to kick in after a few minutes and then slow down everything to what ever I have my simple-queue set for. When this happens, a second remote person wanting to also run a btest to my server may not be able to connect or get slower-than-normal results - or possibly not able to run a btest at all.

North Idaho Tom Jones

yoozieck · Fri Dec 23, 2016 12:06 am

Heads up -
Because I am still having some network problems (non-related to Mikrotik anything), I have turned off the 207.32.195.2 public btest server.
It will remain turned off until mid next week.

North Idaho Tom Jones

Thanks for your response.
I want to thank you, you are doing great work. Hope you'll get server running quick.
Merry Christmas from Poland to you, North Idaho Tom Jones, and to the whole forum

biland · Mon Dec 26, 2016 1:53 am

merry cristmas
and i love this server

on each mikrotik i can proof the speed for my client localy, without going there and show it on his windows..
does anybody know another server you can use, for the same mather (even slower, i dont mind)

Tue Dec 27, 2016 6:28 pm

I just turned back on the public 207.32.195.2 btest server

Please - no 10+ minute continuous extended bandwidth tests.
It's OK to use - but please don't do lengthy tests. Recently I've had some tests that have lasted for several hours or more.

I hope everybody had a good holiday - and will have a good New Years.

North Idaho Tom Jones

planetcoop · Tue Dec 27, 2016 10:55 pm

here is what i was able to test at on a 10gbps comcast fiber connection. Thank you for the public btest site.

1-traceroute.png

2-udp-15-seconds.png

3-tcp-15-seconds.png

planetcoop · Tue Dec 27, 2016 11:04 pm

here are two other random speed tests from beta.speedtest.net and speedtest.googlefiber.net

4-beta-speedtest-net.png

5-speedtest-googlefiber.png