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

RouterOS General
1

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.

Update - I shutdown the Public-Mikrotik-Bandwidth-Test-Server(s) I maintained on April 1’st 2025 - because of all the cron scheduled never-ending btests I was getting all-of-the-time. I figured that well over two-thirds of all of the btests were non-humans - and automatic time-based scripts ( so that other admins could automatically have all of their ISP customers perform speed test to my server. No matter how many times I posted only manual btest(s) performed by a human Mikrotik operator.
Now over two months later , my now private btest server ( same IP addresses ) is still getting hit with hundreds of daily btest attempts - which they now fail because the login & password was changed.
I would like to - but I won’t - create an auto reverse direction denial-of-service back to those repeating networks. A 10+ Gig denial-of-service might get their attention.

  • If somebody reading this post had one , please disable your automatic btest(s) to my now private btest server.

North Idaho Tom Jones



** 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 :smiley:
    The btest server 207.32.194.24 is now also IPv6 :slight_smile:
    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: NEW Public Bandwith Test Server - General - MikroTik community forum

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: Public-Mikrotik-Bandwidth-Test-Server(s) ( now shutdown as of April 1st 2025 ) - #427 by TomjNorthIdaho - General - MikroTik community forum
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:: Public-Mikrotik-Bandwidth-Test-Server(s) ( now shutdown as of April 1st 2025 ) - #428 by planetcoop - General - MikroTik community forum

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

2

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.

3

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.

4

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

5

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.

6

Here is Result

7

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

8

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..

9

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.

10

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.

11

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.

12

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).

13

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

14

jebiga :slight_smile:

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

15

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

16

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

17

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 :slight_smile:.


Thanks again!

18

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

19

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!

20

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.