It is none of those, peering is not due to NAP or anything like that, it is private arrangements setup, the more peers you have the better off your communications links are.
Cluster2 network right now has more of them, access to more paths out to the clients on a more direct pathing.
We are working to greatly increase it across the board
We will be signing contracts next week on delivery for a nice new setup. We’ll explain more soon but it wil be about 60 days out at max, we are hoping to go live in about 49 days in fact.
Right now we are using a blended InterNAP, seabone, and some cogent (in the case you are connected to a cogent peer) network.
Today we have signed a contract to go 100% internap on a dual feed redundant system as of July 1. This will allow us better control and routing ability as well.
Cluster2 is already preferenced to InterNAP and is performing better overall, the entire network will soon be like this, but no cogent at all, and no seabone at all.
Forgive me if I misunderstand, but isn’t it better to have multiple peers rather than one single connection? Wouldn’t going 100% Internap expose you/us to 100% loss of connection if something goes down within Internap?
It doesn’t quite work that way though
Ideally we will at some point add some private peering but at this point going 100% internap is a benefit due to the nature of their FCP performance optimized network. The FCP doesn’t really care so much about costs as it does performance in their network. The FCP routes around problems quickly and fixes them in an automated manner for all outbound route. Right now with some of the others mixed in, it can get a little squirrelly on routes, especially those having preferences on the ISP side for the low cost carriers where packetloss and congestion are common.
Ah… so where I was assuming that this particular slowdown problem was with Internap, the truth is my route was probably using one of those secondary carriers? Must be so, if Cluster2 is 100% Internap now, and it’s much faster (for me) than Cluster 1 is.
Another thing, just out of interest - I tried downloading a file from my client’s site on Win22, using GetRight. Downloading using 1 single connection was limited to ~26MB/sec.
But when I downloaded using 10 simultaneous connections, the overall download speed was ~250MB/sec. This conclusively shows that whatever peer is connecting me to Jodo’s network is limiting HTTP on a per-connection basis.
Whoever it is, that’s very dodgy indeed. Just goes to show, you get what you pay for.
Steeeeephen, long time no speak! How’s things in Jodoland? Cluster 1 download speed is still dog slow, and I need to make a decision about moving my clients to Cluster 2 which is much much faster.
You spoke about Cluster 1 getting a re-jig. Is that still going to happen, or should I just bite the bullet and move to C2?
How was your Halloween? Get up to anything horrific?
Actually it has already happened, and done. They are both on exactly the same network now, just using the same IP allocation for the most part.
However there are a few /25 bit subnets that can not get the full BGP peering advantage, which we are working to get new IP allocations and migrate them over so that they too can get the full BGP config.
Halloween, completely boring not even a single person came by in a huge place in Miami
Hi Stephen,
Can tou give some more info which /25 IP-subnets you are speaking about?
For example are 204.14.108.1-128 and 64.71.235.1-128 allready on the good new BGP config?
For me it’s the same issue, my sites on cluster 1 are also slowing down, and like to know whether they are on a good uplink connection. (of course slowness can have other causes)
Regards, Jan-Pieter
