New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
No packet loss and achieving the advertised / promised speeds.
99.5% Uptime or better. Things happen and having a provider who promises less and delivers more would be better in my opinion.
I redundancy.
@24khost @KuJoe, nevermind the redundancy stuff. Assume the network is redundant and giving the advertised 99.99% uptime. What else would you look?
If it's consistently providing 99.99% uptime I would look into why it's only providing 99.99% uptime and try to fix that 0.01%.
I am not sure what you are asking. Are you asking what we think makes a good network? Because if so, I believe we answered it. Here is a list of importance for a good network:
As you can see there isn't much more to a good network than the top 3. If it's online, safe, and fast then anything is else is not important IMO.
@KuJoe +1
Wouldn't you check for routing or something? If it's a 1Gbps line, is downloading at 55M/sec from cachefly fine?
routes.
Peers ? Who your network peers with and as @William said routes, better routes will lead to lower pings and well a better network
Consistently decent speed with this: http://freevps.us/downloads/bench.sh
It's a pretty balanced script.
@jarland not really, i have a feeling some of the servers this scripts downloads from are too slow/overloaded - at least this is my observations when running this script from multiple different locations.
They aren't great but that's generally why I think it's balanced. I expect 15-20mbit minimum from that. Anything less generally points out a bad route on the server end in my experience.
Yes but 15-20 mbits is very limiting. The server you are testing could be much faster, and the result is limited by the slow test targets.
How to test a network...
It depends on what I am intending with that location. If it is to serve a local geography like say a few US states, then I determine peering of the provider and I look at the dominant consumer facing bandwidth providers as well as prominent cable operator and traditional phone company.
Perform a bunch of traceroutes, mtr, ping, etc. to points within their respective networks and ideally also get some speedtest files up on a clean unused pipe of equal or larger size. Test that and repeat for a few days at all sorts of times.
Beyond that on the larger scale, the same mentality prevails. I try to break off small areas for nodes/servers/VPSes to address.
It is VERY hard to find any provider (especially in the United States) that is going to have low latency as well as throughput to much of the country unless you are dealing with two locations on their same network (which typically won't prove true and low latency and high throughput to end users --- unless they are on same network or directly peered with non subscribed bandwidth).
Other than uptime I really want a network with really low pings, consistently fast network speeds, and no packet loss.
I don't check routing unless there's a problem. Also, how exactly do you check the routing information for a network you don't have access to?
Just because you have a 1Gbps line doesn't mean you won't hit a bottleneck outside of your network. If it's downloading at 55MB/s and I only need 1MB/s for my VPN then I could care less.
The other thing I really look for especially is the presence of HE and Cogent in the traceroutes.
Find that many providers like these two companies due to historically low pricing. As a result, they load those pipes up and stomp on things with QoS. Meaning throughput often sucks.
Run into this exact situation every day.
IN all fairness, impossible typically to say if the originating side is full or if the end destination over the Cogent or HE has the congestion problem.
Yes, possible to experience this with other transit providers, but happens far less.