Related to the possible btest issues I might be seeing, I spotted this in Release Candidate information:
6.41rc28
*) btest - improved reliability on Bandwidth Test when device`s RAM is almost full;

Just to be clear, my implementation is done only upon one of our admins clicking the test bandwidth button inside the web admin console they use to manage their hardware, and it's hard coded to run only a single 10 second test up, followed by a single 10 second test down, it then disables the test button once it's been ran once. They would have to exit and re-enter that configuration screen to be able to run it a 2nd time. so while it's automated in the sense that it is launched programmatically through the hardware, it is initiated and requested by an admin.

Brian Higgins,
Thinking about it last night, I feel your scripted use of the 207.32.195.2 btest server is a neat and clever idea and pretty much in-line for what this btest server was built/configured to perform.
So at this time, I will say go ahead and do your stuff with your script - and good luck.

I would like to ask the following however:
1) What IP address would your btest clients be coming from ? I ask so that if I see a stuck btest session, then I can identify who it came from and work with you on it.
2) Your script is human triggered and not auto triggered using a cron or scheduler.
3) If/when possible, your client btest sessions are sequential (one at a time ) , instead of many at the same time.
4) Please try to limit the client btest session to be just long enough to get an accurate bandwidth measurement.

FYI - As a network engineer, I really like to see useful tools like this and I suspect your script is a very good tool. If you don't mind and if you have the time, could you post some information on your network and how it is used? I think tools like this could help many others.

North Idaho Tom Jones

Tom Jones and planetcoop, thank you so much for sharing your band-width us. (bad pun)

As you can see, I am able to fill my 1G pipe at Tomjones =)

Although I noticed I can't connect to planetcoop and it looks like my IP block is in your blacklist. Can I be whitelisted for 162.255.156.0/22 ?

Tom Jones and planetcoop, thank you so much for sharing your band-width us. (bad pun)

As you can see, I am able to fill my 1G pipe at Tomjones =)

Although I noticed I can't connect to planetcoop and it looks like my IP block is in your blacklist. Can I be whitelisted for 162.255.156.0/22 ?

It's good to hear the positive feed back - thank you.

FYI - The two different btest servers (mine and planetcoop) are both independent systems. As for planetcoop, he manages his own system(s). Together, we both offer this free btest service for the benefit of all Mikrotik admins (at our own bandwidth & time expenses). However ... If anybody wanted to donate some Mikrotik hardware equipment, I for one would be interested in bringing up multiple btest servers (the current CHR & and possibly some additional physical Mikrotik devices). I think it would be useful to be able to btest do different types of Mikrotik hardware platforms connected to a 1-gig or 10-gig Internet feed.

FYI - lol - Kinda funny ... I think that when/if planetcoop and I btest to each other, I suspect the 2 to 10 Gig bandwidth load can melt lots of network equipment along the path between us. Officially, my network is supposed to be 2-gig burstable to 4-gig using all 10-gig physical ports.

North Idaho Tom Jones

Tom Jones and planetcoop, thank you so much for sharing your band-width us. (bad pun)

As you can see, I am able to fill my 1G pipe at Tomjones =)

Although I noticed I can't connect to planetcoop and it looks like my IP block is in your blacklist. Can I be whitelisted for 162.255.156.0/22 ?

I have just added you to the whitelist. This should also allow you to run longer tests.
Thank you for the request.

Thank you @planetcoop - here's my screenshot. Someday soon I'll have a 10G Circuit to test with >:)

They could also be subscribed.

They could also be subscribed.

?
Not sure if I understand what you are stating ?

any reason why?
I have try with 3 routers with 3 differents sim ...
in all of them I get "connecting....." and "can't connect"

what could be the reason?

Thanks,

any reason why?
I have try with 3 routers with 3 differents sim ...
in all of them I get "connecting....." and "can't connect"

what could be the reason?

Thanks,

Check your firewall, you have to allow tcp/udp port ranges into the mikrotik chain.

any reason why?
I have try with 3 routers with 3 differents sim ...
in all of them I get "connecting....." and "can't connect"

what could be the reason?

Thanks,

I was trying 50.235.23.218 today and he must have it set not to allow Direction set to Both, if you do just send or receive then it will do a test. I tried it a few times in the last week and had this issue where it would connect then just disconnect right away. the second ip listed by OP dose do the bidirectional test if you want to try it also.

any reason why?
I have try with 3 routers with 3 differents sim ...
in all of them I get "connecting....." and "can't connect"

what could be the reason?

Thanks,

I was trying 50.235.23.218 today and he must have it set not to allow Direction set to Both, if you do just send or receive then it will do a test. I tried it a few times in the last week and had this issue where it would connect then just disconnect right away. the second ip listed by OP dose do the bidirectional test if you want to try it also.

I don't have a restriction configured on btest for one direction at a time. I am running the latest RC while i am conducting my own performance testing.

Could not connect to Planetcoops but could connect to Toms. From one Tom to another, thank you! great way to test out my small pipe when needed.

Could not connect to Planetcoops but could connect to Toms. From one Tom to another, thank you! great way to test out my small pipe when needed.

Tdaddysimi - Thanks for the kind words & you are welcome

North Idaho Tom Jones

Could not connect to Planetcoops but could connect to Toms. From one Tom to another, thank you! great way to test out my small pipe when needed.

Hello, do you mind providing your ip? I can add you or verify why it didn't work.

Its dynamic and it changes every 12-24 hours, but right now its 174.219.139.207.
Its a verizon wireless IP. my network is bridged off from my lte connection via cellular

Just received an upgrade from 300 to 400 Mbps.
14 hops and established 413 Mbps!

Just received an upgrade from 300 to 400 Mbps.
14 hops and established 413 Mbps!

Which btest server did you test to & what part of the world are you in ?

North Idaho Tom Jones
(admin for the btest server 207.32.195.2)

I live in the Netherlands and used this server: 50.235.23.218
[update]
Just tried also your server:

I live in the Netherlands and used this server: 50.235.23.218
[update]
Just tried also your server:

Thanks

I must be getting old ...
I remember back in the late 70s , I was a tech working on a large multi-state SNA banking computer network and we were screaming fast at 1,200 Baud (Bits per second).
North Idaho Tom Jones

Test from Durban, South Africa.

Thoughts on Bandwidth testing and Mikrotik.
Using mikrotik you can get two very different results depending on if you use TCP or UDP... basically:
UDP will give faster result because it ignores any smaller packet loss and just keep stuffing packets down the link until it is full.. Not a very useful test in my opinion.
TCP has a default settings of 20 individual TCP connections, so its like several PCs working together on the same link, good to see what you may expect from say an office connection with several users (combined usage).
For end user testing I like to use TCP with just two Individual TCP connections, this gives a good indication what a single end user will experience, and will give much the same result as a good speedtest.net server.
Another note, TCP bandwidth testing put more strain on the Mikrotik routers/CPU, and can give a false slow result.

Thoughts on Bandwidth testing and Mikrotik.
Using mikrotik you can get two very different results depending on if you use TCP or UDP... basically:
UDP will give faster result because it ignores any smaller packet loss and just keep stuffing packets down the link until it is full.. Not a very useful test in my opinion.
TCP has a default settings of 20 individual TCP connections, so its like several PCs working together on the same link, good to see what you may expect from say an office connection with several users (combined usage).
For end user testing I like to use TCP with just two Individual TCP connections, this gives a good indication what a single end user will experience, and will give much the same result as a good speedtest.net server.
Another note, TCP bandwidth testing put more strain on the Mikrotik routers/CPU, and can give a false slow result.

UDP us a fire and forget protocol.
TCP is a fire and wait for an answer that the packet(s) was properly received.

I believe then when a Mikrotik is performing a btest (UDP or TCP), the remote device being tested to is also sending summary packets to the originator of the Mikrotik btest device. The summary packets may include drops, good & bandwidth during the test.

When performing a UDP (receive) btest, look at the "Lost Packets:" count. If it constant changing/increasing number, then your UDP receive btest session is slightly outrunning the throughput capability of the total end-to-end network between both Mikrotik devices. At this point, set your local Mikrotik "Remote Tx Speed:" to a slightly slower speed than what you are actually measuring (about 75 percent) and run the test again. If you still see drops on the UDP receive btest, then try 70 percent. Raise or lower your "Remote Tx Speed:" until you no longer see any errors. This is your clean error-free maximum UDP receive bandwidth rate.

Note: It is normal to see some "Lost Packets:" on the Mikrotik originating the UDP receive btest.
Note: If you see "Lost Packets:" on the Mikrotik originating a UDP send test, or a TCP send-or-receive test, then you may be experiencing some possible network problems.

Note: TCP uses RED (Random Early Detect). When a packet is lost/dropped during transmission and a response was never received, the TCP sending device performs some brief random timeouts and resumes sending TCP traffic at a slightly slower rate. You might want to google "RED -aka- Random Early Detect" and also google "TCP ACK" and google "Delayed ACK".

North Idaho Tom Jones

EDIT: additional notes -

With UDP (fire and forget), it is possible to have more-than-one/several/many UDP packets in transit going through the network at the same time. Example, a UDP packet could be 10 percent through the network and another UDP packet at 50 percent and another UDP packet at 85 percent through the network.
There is no guarantee a UDP packet made it through the network to the remote device.

With TCP (fire and wait for a received ACKnowledgement), (((Not using delayed ACK))), the TCP sending device fires one TCP packet (through the network) then waits for the ACKnowledgement packet before sending the next TCP packet.
There is a guarantee a TCP packet made it through the network to the remote device. If the device sending the TCP packet does not receive a ACKnowledgement packet, then it assumed the packet was lost and may wait a random amount of time and possibly slow down the sending of TCP packets. When all/many ACKnowledgement packets are properly received by the TCP sending device, the TCP sending device may start to increase the speed at which TCP packets are sent.

FYI - most ISP bandwidth governing devices (such as Mikrotik simple-queues for example), start automatically dropping packets when a certain bandwidth is reached. This causes bandwidth to/from an ISP customer to conform to the speed the ISP has the customer set to (RED).

North Idaho Tom Jones

Hello, an big thank you for the btest!
Its great having that server for testing purposes, I did some tests for 2 or 3 minutes to verify the %CPU of the MikroTik rules and QoS and optimizations (wasn't necessary), I'm using my first MikroTik bought from a month, RB951G-2HND, an great product! Best of that price here, had to learn a bunch shit of networking LOL.
I am from Brazil and there's the results and traceroute , by the way, my internet is 20/4mbps (2500KBps/500KBps) *and this MikroTik is running 1xMIPS@500MHz, the default is 600MHz*, I underclocked it because it has so much power for my own internet that I don't need even the default clock, its for long durability.

"
1 1 ms <1 ms 1 ms 10.0.8.1
2 <1 ms <1 ms <1 ms 172.16.104.229
3 1 ms <1 ms <1 ms 10.12.0.9
4 1 ms 1 ms 1 ms 10.99.99.45
5 1 ms 1 ms <1 ms 10.5.5.2
6 1 ms 1 ms 1 ms 10.5.10.33
7 13 ms * * 201.16.219.9
8 21 ms 27 ms * 170.84.33.110
9 20 ms 19 ms 19 ms 170.84.34.177
10 19 ms 19 ms 19 ms 168.197.21.141
11 137 ms 137 ms 137 ms 168.197.20.189
12 159 ms 163 ms 159 ms 206.126.236.8
13 199 ms 199 ms 200 ms 65.50.198.85
14 200 ms 199 ms 199 ms 174.127.136.98
15 199 ms 199 ms 199 ms 174.127.141.176
16 200 ms 200 ms 202 ms 174.127.136.97
17 205 ms 208 ms 204 ms 174.127.138.144
18 200 ms 199 ms 200 ms 216.243.28.158
19 209 ms 208 ms 208 ms 66.35.5.246
20 * * * Esgotado o tempo limite do pedido.
"
https://drive.google.com/open?id=0BxFQ1 ... WpMMmVuQlE

Hello, an big thank you for the btest!
Its great having that server for testing purposes, I did some tests for 2 or 3 minutes to verify the %CPU of the MikroTik rules and QoS and optimizations (wasn't necessary), I'm using my first MikroTik bought from a month, RB951G-2HND, an great product! Best of that price here, had to learn a bunch **it of networking LOL.
I am from Brazil and there's the results and traceroute , by the way, my internet is 20/4mbps (2500KBps/500KBps) *and this MikroTik is running 1xMIPS@500MHz, the default is 600MHz*, I underclocked it because it has so much power for my own internet that I don't need even the default clock, its for long durability.

"
1 1 ms <1 ms 1 ms 10.0.8.1
2 <1 ms <1 ms <1 ms 172.16.104.229
3 1 ms <1 ms <1 ms 10.12.0.9
4 1 ms 1 ms 1 ms 10.99.99.45
5 1 ms 1 ms <1 ms 10.5.5.2
6 1 ms 1 ms 1 ms 10.5.10.33
7 13 ms * * 201.16.219.9
8 21 ms 27 ms * 170.84.33.110
9 20 ms 19 ms 19 ms 170.84.34.177
10 19 ms 19 ms 19 ms 168.197.21.141
11 137 ms 137 ms 137 ms 168.197.20.189
12 159 ms 163 ms 159 ms 206.126.236.8
13 199 ms 199 ms 200 ms 65.50.198.85
14 200 ms 199 ms 199 ms 174.127.136.98
15 199 ms 199 ms 199 ms 174.127.141.176
16 200 ms 200 ms 202 ms 174.127.136.97
17 205 ms 208 ms 204 ms 174.127.138.144
18 200 ms 199 ms 200 ms 216.243.28.158
19 209 ms 208 ms 208 ms 66.35.5.246
20 * * * Esgotado o tempo limite do pedido.
"
https://drive.google.com/open?id=0BxFQ1 ... WpMMmVuQlE

Re under clocking ...
I understand your reason for under clocking. However , in general , faster CPUs tend to offer faster/quicker propagation delay times when going through routers & firewalls & bridges. Even a 1 ms (or .05 ms) per packet delay starts to add up when sustaining full network speeds.

This is a poll question for Mikrotik admins;

I assume most of you know about the two privately owned btest servers that are available for public btests.
We have had many thank-you(s) and received a lot of praise - and we know they are both often used hundreds of times every day from all over the world.
And for that , we are happy to provide this service.

Now for my questions:
- Who would be interested in an additional set of public accessible Mikrotik tools which use the Mikrotik "Traffic Generator" ?
- Does anybody have some suggestions for how to set one up ?
- Could a public accessible Mikrotik "Traffic Generator" be run on a 100 meg connection ?
- Should it be short period high-traffic testing ?
- Should it be long period slow traffic testing ?
- Who would be interested in also hosting a public accessible Mikrotik "Traffic Generator" site ?

In my opinion, the two current public accessible btest servers work well to help determine peak up/down TDP/TCP bandwidth. However, I am thinking a "Traffic Generator" site should be low & slow sustained traffic which might run for example at 1-to-5 meg over an hour or 24 hours or possibly even a full week. And be able to sustain traffic testing to possibly 100 or more simultaneous testers at the same time.

Any thoughts and/or input and/or consideration for other types of other Mikrotik public accessible test functions/features ???

North Idaho Tom Jones

You should be very carefull providing Traffic Generator service: no authorization, one can freely generate 'test stream' to faked address, thus providing kind of DoS attack. If you allow testing only to caller's IP address, then he should be NATed by router's address - not everywhere it's possible.

BrianHiggins wrote:
Just to be clear, my implementation is done only upon one of our admins clicking the test bandwidth button inside the web admin console they use to manage their hardware, and it's hard coded to run only a single 10 second test up, followed by a single 10 second test down, it then disables the test button once it's been ran once. They would have to exit and re-enter that configuration screen to be able to run it a 2nd time. so while it's automated in the sense that it is launched programmatically through the hardware, it is initiated and requested by an admin.


Brian Higgins,
Thinking about it last night, I feel your scripted use of the 207.32.195.2 btest server is a neat and clever idea and pretty much in-line for what this btest server was built/configured to perform.
So at this time, I will say go ahead and do your stuff with your script - and good luck.

I would like to ask the following however:
1) What IP address would your btest clients be coming from ? I ask so that if I see a stuck btest session, then I can identify who it came from and work with you on it.
2) Your script is human triggered and not auto triggered using a cron or scheduler.
3) If/when possible, your client btest sessions are sequential (one at a time ) , instead of many at the same time.
4) Please try to limit the client btest session to be just long enough to get an accurate bandwidth measurement.

Bumped to 6.41, enjoy.

I can't get through (to either you or Tom J's, oddly); just unable to connect. It works from another device on a different network I have access to.

I have a new 1gbps symmetrical connection I'd like to test. IP address is 38.131.218.243 -- is it blocked on your end, perhaps?

I can't get through (to either you or Tom J's, oddly); just unable to connect. It works from another device on a different network I have access to.

I have a new 1gbps symmetrical connection I'd like to test. IP address is 38.131.218.243 -- is it blocked on your end, perhaps?

The last test i saw was here: Dec/21/2017 22:26:32 I let you test for 5 minutes and then block for the next 55 minutes. I have added your ip to my always allow list for 72 hours.

I can't get through (to either you or Tom J's, oddly); just unable to connect. It works from another device on a different network I have access to.

I have a new 1gbps symmetrical connection I'd like to test. IP address is 38.131.218.243 -- is it blocked on your end, perhaps?

The last test i saw was here: Dec/21/2017 22:26:32 I let you test for 5 minutes and then block for the next 55 minutes. I have added your ip to my always allow list for 72 hours.

Huh, strange...that probably was me; I'm in Central time, so assuming you're reporting that in Pacific time, my last test being at 1:26am here sounds about right. No traffic was passed, though, and all I ever saw was something like this:

[admin@MikroTik] > /tool bandwidth-test 50.235.23.218 user=btest password=btest protocol=tcp
status: can not connect
duration: 0s
rx-current: 0bps
rx-10-second-average: 0bps
rx-total-average: 0bps
random-data: no
direction: receive

Same exact command from a MT on a different network (Suddenlink 1gbps cable):

[admin@MikroTik] > /tool bandwidth-test 50.235.23.218 user=btest password=btest protocol=tcp
status: running
duration: 30s
rx-current: 141.8Mbps
rx-10-second-average: 150.0Mbps
rx-total-average: 144.0Mbps
random-data: no
direction: receive

The ISP serving my apartment management company (~5,000 units) uses CGNAT so it's _possible_ someone else has a MT and is running btests and is appearing to be coming from my same IP address (resulting in the 55-minute block), but a) I think the chances of that are unlikely and b) you put me on the always-allow list. The ISP assures me they do not do any filtering--I assume CGNAT doesn't break btest, but clearly something's wrong, here...

Anyway, I had looked forward to seeing what the MT btest could do, but I've done plenty of other speed tests and am finding a consistent ~600mbps down and ~925mbps up from regional speedtest servers here in the midwest, so a btest isn't strictly necessary, just informative.

Try udp protocol.

Try udp protocol.

I did try both TCP and UDP on both planetcoop and tomj's...no go.

Not a big deal, though. But I may pop back by when the local MDU ISP that manages the complex turns IPv6 on (they assure me it's soon) to do some IPv6 speed/peering testing.

btest server 207.32.195.2 was just upgraded to 6.41


Ho Ho Ho - hope you had a Merry Christmas and hope you will have a good New Year

North Idaho Tom Jones

I was able to do a send test from my cable ISP but my DSL hung. both worked on RX mode.
Now my PC is on my cable router to feed my cloud backup from my NAS, this test helped me cut upload time.

Thanks for the link!
It was handy to test our 10Gbps connection,

Congratulations. What was the device on the mikrotiks side?

Congratulations. What was the device on the mikrotiks side?

With the interface name i will say a Routerboard CCR?

Which CCR ?
it looks pretty darn fast if this is a btest !!!

North Idaho Tom Jones

Which CCR ?
it looks pretty darn fast if this is a btest !!!

North Idaho Tom Jones

My NAT router pushing all this to btest is a ccr1036-2sfp+ with the same interface type names. Btest is obviously a CHR behind that ccr.

The thing is which CCR was used as btest client... has btest been fixed???

The thing is which CCR was used as btest client... has btest been fixed???

I would say a CCR1036 or 1072... I may get a 1072 some day but i just picked up a cisco nexus 3064 for a tengb core.

The thing is which CCR was used as btest client... has btest been fixed???

Bingo. That was my concern.

The thing is which CCR was used as btest client... has btest been fixed???

Bingo. That was my concern.

Ditto - same question "... which CCR was used as btest client ..."
A CHR can do 10-gig with no problems. I have never seen a hardware CCR achieve anywhere near the btest speed as indicated in the graphical image a few posts ago.

North Idaho Tom Jones

The thing is which CCR was used as btest client... has btest been fixed???

Bingo. That was my concern.

Ditto - same question "... which CCR was used as btest client ..."
A CHR can do 10-gig with no problems. I have never seen a hardware CCR achieve anywhere near the btest speed as indicated in the graphical image a few posts ago.

North Idaho Tom Jones

Tom, we will probably need a few samples to keep hosting btest servers... wink wink.

The thing is which CCR was used as btest client... has btest been fixed???

Bingo. That was my concern.

Ditto - same question "... which CCR was used as btest client ..."
A CHR can do 10-gig with no problems. I have never seen a hardware CCR achieve anywhere near the btest speed as indicated in the graphical image a few posts ago.

North Idaho Tom Jones

Tom, we will probably need a few samples to keep hosting btest servers... wink wink.

planetcoop , Ya gotta admit - The amount of bandwidth and server resources we give/donate to the free/open btest project is totally way far beyond insane !!!
Combined together , we donate a 20-Gig physical Internet connection exclusevly for Mikrotik btest admins - and at no charge but with all of the headaches that go with any such high bandwidth projects.
So yea ... If Mikrotik ever has a new routerboard, please consider giving two to planetcoop and two to myself (Tom). ((( Two because one of the two would be dedicated as a 10-gig public btest server and the other would be put into production to front-end our 10-gig business networks.))) ((((( or would you really rather see a 10-gig btest mikrotik behind a 10-gig Internet connected Cisco router ? .)))))

Yo - planetcoop - lol , wadda you say that If we don't get two free mktiks each , that we break the Internet for a few days and run a multi-24-hour-day sustained 10-gig btest between our btest servers. - really - yup - serious - well just kidding - or am I ???

North Idaho Tom Jones

The thing is which CCR was used as btest client... has btest been fixed???

Bingo. That was my concern.

Ditto - same question "... which CCR was used as btest client ..."
A CHR can do 10-gig with no problems. I have never seen a hardware CCR achieve anywhere near the btest speed as indicated in the graphical image a few posts ago.

North Idaho Tom Jones

Tom, we will probably need a few samples to keep hosting btest servers... wink wink.

planetcoop , Ya gotta admit - The amount of bandwidth and server resources we give/donate to the free/open btest project is totally way far beyond insane !!!
Combined together , we donate a 20-Gig physical Internet connection exclusevly for Mikrotik btest admins - and at no charge but with all of the headaches that go with any such high bandwidth projects.
So yea ... If Mikrotik ever has a new routerboard, please consider giving two to planetcoop and two to myself (Tom). ((( Two because one of the two would be dedicated as a 10-gig public btest server and the other would be put into production to front-end our 10-gig business networks.))) ((((( or would you really rather see a 10-gig btest mikrotik behind a 10-gig Internet connected Cisco router ? .)))))

Yo - planetcoop - lol , wadda you say that If we don't get two free mktiks each , that we break the Internet for a few days and run a multi-24-hour-day sustained 10-gig btest between our btest servers. - really - yup - serious - well just kidding - or am I ???

North Idaho Tom Jones

Tom, lets do it. it would remind me when the brazil based ISP or spoofing was 5+gbps and i only noticed due to interface monitoring... This is my home connection so nothing tested nothing lost.

https://btest.planetcoop.com:10443/graphs/iface/ether1/
https://observium.planetcoop.com/graphs ... 484147434/

This is cute, about 140TB in testing per year...

I don't think it would be so problematic to kill the communication between you two in that case for anyone in the middle. But anyway, you could do that to see what happens. Maybe none will notice that...

I don't think it would be so problematic to kill the communication between you two in that case for anyone in the middle. But anyway, you could do that to see what happens. Maybe none will notice that...

lol - I suspect a lengthy/extended/non-stop 10-gig btest UDP send and a second btest UDP receive between planetcoop and myself (20-gig sustained total) could very well be noticed and felt at many peer points and router-inter-connects on the Internet between us. I doubt that all of the L2 & L3 hops and peer points between us always have an extra/available/free 10-gig of un-used pipe just sitting around that is not being used during all periods of a 24-hour day. I would expect to possibly see some saturated networks and packet delay and packet loss would occur along the connection paths which could have some effects for everybody in the world having traffic to/from/through any of the servers & networks sharing the btest to btest Internet L2 L3 pathway.

I don't think it would bring the Internet down - but it would be very much noticed at many points if it was a sustained continous flood of traffic

FYI - I must be getting old !!! I remember when the Internet (arpa net) backbone was a 56 k DS0 pipe between the east coast and the west coast. I was on it back then with my 110 baud dial-up modem. DNS was not invented yet , you had to periodically download a host file which contained all of the connected machines.