Check your Internet connection to this server

You are connected to .

Use this speed test to check your roundtrip network latency and your bandwidth to this server.

NOTE: This test is best run on Chrome. Safari and Edge should also be okay. Firefox often produces inaccurate results.

How to run this test

Ensure you are connected by Ethernet cable to your Internet connection. We strongly recommend that you avoid any kind of wireless connection to the Internet including Wi-Fi, satellite, or a cellular Internet connection. It is best to turn off the Wi-Fi in your computer settings so that you can be 100% sure you are going through the Ethernet connection. If you don’t currently own an Ethernet cable you can run the test on Wi-Fi just to see if you’re in the ballpark. Depending on how good or bad your Wi-Fi is, you can expect the latency might be 1 or 2ms slower but the jitter will likely be a lot worse. Wi-Fi is not a supported configuration for our service.

Also ensure you are not running any programs that might impact the network performance on your machine such as VPN or firewall software or any programs that might automatically download large software updates. Some anti-virus packages include firewall or "Internet protection" functionality that may impact network activity on your computer.

Here's the best way to run the test:

1. Run the full test (start it and wait until it is complete) to get the latency, jitter, upload, and download numbers. Record these somewhere.
2. Run the test about five times just long enough to measure the latency and jitter. You can start the test and then abort it after the latency and jitter numbers appear and then restart it again. Record each set of latency and jitter numbers. You want to do this multiple times just to see if it is consistent. Occasionally there will be some outliers.

Advanced alternatve: As an alternative, if you know how to do it, you can run an ICMP ping to the server and let it run for a while to get a more accurate sense of the latency. The browser test is good enough although we often see that it may report 1 or 2ms higher than an ICMP ping.

How to interpret test results

Consult the tables below to determine if you have enough bandwidth to use the services and to get an idea of what kind of experience you might get based on the latency of your connection.

Most broadband network connections will have more than sufficient bandwidth for syncspace.live. It is usually latency that is the greatest concern. While higher numbers for bandwidth are more desirable, we want the lowest possible numbers for latency and jitter.

Latency Use the following table to get you an idea of how the experience might be based on the latency of your connection. Experience Latency Jitter Excellent 5ms or less 3ms or less Very good 6 to 15ms 4 to 10ms Acceptable 16 to 25ms 11 to 15ms Below average Greater than 25ms Greater than 15ms Note that while latency greater than 25ms is not ideal, it doesn't mean you can't perform together but you will be more constrained in what you can do especially when it comes to performing music with fast tempos.

Bandwidth To determine whether you have enough bandwidth, you need to add the bandwidth needed for audio to that required for video and also add bandwidth required for broadcasting if you will be running a Do-It-Yourself broadcast. Note that when broadcasting through our Virtual Broadcast Service you don't need to worry about bandwidth for broadcasting. Features Upload Download Jamulus audio 1 Mbps 1 Mbps JackTrip audio 2 Mbps 2 Mbps Real-time video 5 Mbps 1 Mbps Do-It-Yourself Broadcasting 6 Mbps 5 Mbps per other ensemble member

If you meet the requirements for bandwidth and latency there's no need to read further. If you don't meet the requirements, continue reading or contact us for further assistance.

Explanation of the measurements

Upload is a measure of how much data you can send to this server in one second. Download is a measure of how much data you can receive from this server in one second. Higher numbers are better.

Latency measures the roundtrip network time to send data to the server and receive data back in return. There is latency in sound transmission even between two people in the same physical space. Sound travels approximately one foot in one millisecond. Therefore, if two people are six feet apart there will be a roundtrip latency of approximately 12ms between them. The overall delay you experience when exchanging sound through the Internet will include the network latency as well as time taken to process the audio data by all the computers in the signal chain. This will typically be the computer sending sound, the computer receiving sound, and the server computer in the middle which acts as a hub for all the audio data sent between an ensemble.

Jitter is the variance or spikes in latency and and may be caused by many things including congestion in the network or processing contention in networking or computer equipment. High jitter may lead to dropouts or artifacts in sound and while it can be somewhat relieved by using jitter buffers, this will increase overall delay.

If your latency is unexpectedly high

If you are within 200 miles or 330 kilometers of a server and have a decent broadband connection, you should see latency that is anywhere from 2 to 10ms. Every location where we are deployed in is carefully selected for the lowest possible latency and this is often a matter of ensuring maximum peering through Internet Exchange Points (IXPs). In some cities there are Internet Service Providers (ISPs) that not peered locally. If you are with one of these ISPs you may find that traffic between you and a local server may be routed out of the city and back, even when the server is just down the street. It may work out that the lowest latency you can get will not be to one of our servers in your city but in another city. If this is the case, you may have to either change ISPs or settle for higher latency to another region.

Check Get Started for a list of some of the known problems we aware of in some cities.

We are already running servers in many global locations and we're constantly expanding and making changes in the quest for the lowest possible latency. If your latency to this server is too high, another location may be a better match especially if your Internet routing is not optimal and can't be improved.

Below you will find instructions to run a traceroute to help determine if you might be seeing routing issues.

Advanced: How to check your Internet routing if your latency is unexpectedly high

If your latency is high it may be because you are very far away from the server. If you know you are within several hundred kilometers or miles of the server then high latency might be due to problematic Internet routing with your ISP.

You can check your routing by following the instructions below. This is not a perfect science and it takes some knowledge to interpret the results but you may be able to figure out enough to give you a clue as to what's happening. Feel free to contact us as we may be aware of existing routing problems in your city or we may have other ideas why your latency is high.

Windows Execute the tracert command with this server as the argument and copy the output to the clipboard. If you're not sure how to do this, follow these steps: Open the command prompt on your computer. Use this button to copy the command to the clipboard and then paste it on the command-line. Execute the command by hitting <return> or <enter>.

Mac Execute the traceroute -q1 command with this server as the argument and copy the output to the clipboard. If you're not sure how to do this, follow these steps: Open a terminal session on your computer. Use this button to copy the command to the clipboard and then paste it on the command-line. Execute the command by hitting <return> or <enter>.

Linux Execute the traceroute -q1 command with this server as the argument and copy the output to the clipboard. If you're not sure how to do this, follow these steps: Open a shell session on your computer. Use this button to copy the command to the clipboard and then paste it on the command-line. Execute the command by hitting <return> or <enter>.

The traceroute may take a minute or two to run as it will try to contact every point along with route. Once the traceroute is complete you will have the output from the command on the clipboard and you can paste it into a site such as this one. Note that the results may be incomplete or inclusive as there may be some computers in the route that did not respond to the traceroute. This doesn't mean that they are not working or unable to route data but may just be unresponsive to traceroute. It's also possible that the geolocation data may not be correct in some cases.