- Social Media
- CDN & Software
- Last Mile
The internet is made up of an enormous quantity of networks and servers that all communicate voluntarily with each other. As your ISP we facilitate this global connectivity for you. When you see a value fluctuating, it could be as a result of a few things:
1. The server that is being monitored is undergoing changes. Servers host the content that you view and interact with on the internet. The further away they are located, the more networks between you and them will likely be involved to get to that data. Servers also fluctuate in volume of requests they receive, depending on their popularity. You're likely to find that a very popular gaming server will suffer from more fluctuations than a blog site, for example
2. The network that the server is hosted on is experiencing changes. Hosting providers offer services to thousands of customers at the same time, and often if one of those customers receives an usually high volume of requests (for example) it may impact the services for all other clients who use the same hosting provider.
3. Something in the network path has changed. As your ISP we interconnect with a vast number of other networks to ensure global connectivity over the internet. Between you and the server/website/app you are connecting to, there can be anything from 1 to 100 other networks involved in serving you that content. i.e. if you connect to a website in Australia for example, your network traffic moves through our network and onto our international connections. From there it moves to international peers' networks, and their peers' networks and so on and so forth, until you finally reach your intended destination. The further away the content, the more likely it is that something can happen along the way.
4. The host has changed. More often than not, popular services, apps and websites will use a distributed network to deliver their content to you. This means the "host" that you connect to isn't a single server, but a multitude of servers spread all around the world. These are often referred to as CDNs and they help to make the internet faster and more stable for end-users. But they also switch the location they deliver content from at times, and this can result in changes to the performance metrics, particularly if the new location is geographically different to the original location.
5. EvoNet's network is undergoing changes. When we undergo maintenance on the network, we may switch network paths temporarily or re-route traffic over different routes. Alternatively if we are experiencing an issue (perhaps a problematic switch) that can result in fluctuations. We monitor for this and proactively take action when and where necessary.
6. a combination of the above. Sometimes things are affected for a multitude of reasons at the same time. This is where we step in to report these issues to other networks when we identify that the issue resides within their control, or we take action if it turns out the issue is on our network.
Latency and why it is so important:
For anyone not used to seeing a network graph, this kind of data can seem overwhelming, but it can be quite intuitive to read if you give it a chance.
What you are seeing is a measure of latency. Latency is the time it takes for us to send traffic to another website, service or app, and for us to receive traffic back from them. This is called the Round-Trip-Time or RTT for short, and is measured in milliseconds (yes, it's THAT FAST!)
It is (arguably) the most critical metric in determining network performance as it dictates absolutely everything from download speed to quality of experience. Many might say that RTT/latency doesn't dictate download speeds but that's simply not true. Any smart device like your computer or smartphone will contain algorithms that help to keep your connection as stable as possible. It will use things like RTT and packet loss to determine how fast it will allow you to download. If it tries to download at full speed but sees packets are being dropped (lost) along the way, it will automatically reduce the speed by using a combination of RTT and the packet loss data.
Additionally, the majority of the internet is based on a protocol called TCP. This requires two devices (your device and the server you are connecting to) to communicate first before sending and receiving packets together. The longer this process takes, the slower the connection will be. This is why connecting to local services will ALWAYS be faster than connecting to international services. This is because the speed of light is the limiting factor here. It takes light travelling through fibre-optic cable a much shorter time to talk to a nearby server than it does to a server far away. And for this reason, all TCP connections over a longer distance will not perform as well as TCP connections over shorter distances. Until such time as someone can break the laws of physics. When you combine all of this together, it helps to better understand why some services may be slower than others. It's just the nature of the global internet and how all computers are able to communciate with each other.
We provide you with real-time (live) views of our network and how it is performing to various systems, services, apps and websites around the world. Additionally, we give you access to 10 day historical data too, so you can see if there have been any major changes or patterns of late. Looking at the live data will give you a more detailed, current view into the network, whle looking at historical data will give you more summarised view of the network/service/app/website you are currently viewing.
If you see a sudden and unprecedented spike which is maintained over a period of time, this might indicate an issue. If you see this same behaviour across all of EvoNet's metrics, then this might indicate an issue on our network. If however the issue is isolated to a single service or a handful of services, this might indicate a problem further upstream, perhaps with an exchange sitting in Frankfurt, perhaps a fibre break in London, or even a server on another network experiencing trouble. Because we don't own the entire internet, these servers and networks fall under the control of other operators. i.e. we do not own Facebook and therefore if Facebook's infrastructure is experiencing difficulties there is nothing we can do other than to report this to Facebook. Where an issue resides on our network however, this will be obvious to see as you'll identify the same patterns or spikes across all of our services.
Let's take an example: if you see latencies to a certain gaming server in Amsterdam have spiked over the past hour, but other gaming services in Amsterdam are not showing the same, or other servers in Amsterdam are not showing the same, this is likely an issue with the gaming server itself. If however you notice that all international traffic has spiked at the same time, this could indicate an issue with EvoNet's network and something we are probably already aware of due to our constant monitoring and alerting systems. If however you see that all of Amsterdam has spiked but London, Frankfurt, France etc are all fine, this could indicate that Amsterdam itself is experiencing a problem such as a major fibre outage on major fibre backbones.
Absolutely, where feasible. It would be deceitful of us to do anything else. Where possible (and it's not always possible) we investigate the ports and correct underlying servers that end-users would be connecting to, and we monitor THOSE.
Let's walk through an example: when you go to Facebook, the website itself is served from a particular IP address however the data is served from various sources. We investigate those sources where possible, monitor how we connect to those sources, and we monitor those connections themselves on the correct ports.
Another great example is gaming: we try at all times to setup our monitoring to connect to the correct gaming servers on the correct ports, rather than simply pinging the website of the gaming developer (the latter would be rather pointless). By doing this we ensure that we're monitoring and displaying to you the most accurate information possible.
There is however a caveat to this, and that is that some services simply don't allow our automated systems to make such connections, and some services require complex login procedures in order to do so. When we encounter this it is sometimes not feasible to perform anything other than ICMP/ping/RTT checks on default ports rather than targeted testing and analysis (the latter we prefer)
You may not publish this data under any circumstances without the written authority and consent by an EvoNet director. This data is provided for personal use ONLY, and ONLY available to EvoNet clients. It is to be treated as strictly confidential and is subject to our terms and conditions.
View historical data for all services. This allows you to take a deeper dive into the network and compare against live data.
View real-time network data and drill into the last few hours in more detail for a wide range of services, websites and apps.
Want to better understand what this data means and how to interpret it? Just like our network, we've got you covered!
In other words you need to be using your registered EvoNet account and have a valid EvoNet IP address.
In other words you need to be using your registered EvoNet account and have a valid EvoNet IP address.
We continuously run performance metrics to a range of locations across North America. If you'd like to suggest changes or additions, head over to the HELP tab above and submit the request to us. We will review all requests and determine if they are suitable for our monitoring system
We intentionally measure performance to targets that we don't control (i.e. we are testing to real-world sites and services that we don't own or operate). This ensures that all data accurately reflects all clients' real-world experiences
This ensures that all data accurately reflects all clients' real-world experiences. This is particularly important for gamers to better understand real-world performance. Head over to our HELP tab to see more information about how to interpret and use this data to get the MOST out of your connection Server Information: Amsterdam 1: 126.96.36.199 Amsterdam 2: 188.8.131.52