For access side (home users) we have slightly over provisioned there
circuits, to minimize the "I¹m paying for 20 why am I getting 19" type of
calls. Provision them out to 25 they get 23-24 on there speedtest
everyone is happy.
Carlos Alcantar
Race Communications / Race Team Member
1325 Howard
Hi,
did you have a look at https://atlas.ripe.net/ ?
They have two types of probes that are already in place.
Best regards
Karsten
2014-10-29 21:05 GMT+01:00 Eric Germann :
>
>
> Greetings,
>
> I'm looking for recommendations on a reliable VPS Provider(s) who can
> provide
>
> 1. Centos 6
> 2.
On Wed, 29 Oct 2014, valdis.kletni...@vt.edu wrote:
On Wed, 29 Oct 2014 15:24:46 -0700, keith tokash said:
Is there an industry standard regarding how much bandwidth an inter-carrier
circuit should guarantee?
And where your PoPs are (and how many) matters as well - if you have a peering
agr
On Wed, Oct 29, 2014 at 7:04 PM, Ben Sjoberg wrote:
> That 3Mb difference is probably just packet overhead + congestion
Yes... however, that's actually an industry standard of implying
higher performance than reality, because end users don't care about
the datagram overhead which their applica
I've used several off this list https://www.exoticvps.com/
On Thu, Oct 30, 2014 at 3:58 AM, Karsten Elfenbein <
karsten.elfenb...@gmail.com> wrote:
> Hi,
>
> did you have a look at https://atlas.ripe.net/ ?
> They have two types of probes that are already in place.
>
>
> Best regards
> Karsten
>
Still acting up for me this morning.
On Wed, Oct 29, 2014 at 4:05 PM, Doug Barton wrote:
> On 10/29/14 12:36 PM, Christopher Morrow wrote:
>
>> On Wed, Oct 29, 2014 at 11:36 AM, Doug Barton
>> wrote:
>>
>>> Happy Eyeballs has nothing to do with it. This is a server
>>> misconfiguration
>>> plai
It is now working over IPv6
On Thu, Oct 30, 2014 at 10:09 AM, Brian Christopher Raaen <
mailing-li...@brianraaen.com> wrote:
> Still acting up for me this morning.
>
> On Wed, Oct 29, 2014 at 4:05 PM, Doug Barton wrote:
>
>> On 10/29/14 12:36 PM, Christopher Morrow wrote:
>>
>>> On Wed, Oct 29,
If memory serves me right, keith tokash wrote:
> I'm sorry I should have been more specific. I'm referring to the
> *percentage* of a circuit's bandwidth. For example if you order a
> 20Mb site to site circuit and iperf shows 17Mb. Well ... that's 15%
> off, which sounds hefty, but I'm not sure
Could someone from AWS contact me off-list.
> On Oct 30, 2014, at 8:23 AM, Jimmy Hess wrote:
>
> On Wed, Oct 29, 2014 at 7:04 PM, Ben Sjoberg wrote:
>
>> That 3Mb difference is probably just packet overhead + congestion
>
> Yes... however, that's actually an industry standard of implying
> higher performance than reality, because end
You can't just ignore protocol overhead (or any system's overhead). If an
application requires X bits per second of actual payload, then your system
should be designed properly and take into account overhead, as well as
failure rates, peak utilization hours, etc. This is valid for networking,
autom
Hi,
> and this industry would
> perhaps be better off if we called a link that can deliver at best 17
> Megabits of Goodput reliably a "15 Megabit goodput +5 service"
> instead of calling it a "20 Megabit service"
But you don't know what the user is going to do over the link. If the average
pac
I'm willing to recommend to sales people that they advertise the size of the
*usable* tube as well as the tube overall, but I'm fairly sure they won't care.
Ben rightly stated the order of operations: BS quote > disappointment > mea
culpa/level setting.
If that fails I'll at least make sure no
> You can't just ignore protocol overhead (or any system's overhead). If an
> application requires X bits per second of actual payload, then your system
> should be designed properly and take into account overhead, as well as
> failure rates, peak utilization hours, etc. This is valid for networkin
Useable data over a link depends on packet size.
56 byte IP packets at X Mbps
1500 byte IP packets at Y Mbps
This is then comparable across link technologies and framings used
on those technologies.
You can then compare a DSL vs GPON vs Cable as provided by the ISP
using Apples
Either is alcatel-lucent.com for the past 2 days I noticed. Ipv6 version of
their site broken.
On Oct 30, 2014 1:18 PM, "Brian Christopher Raaen" <
mailing-li...@brianraaen.com> wrote:
> It is now working over IPv6
>
> On Thu, Oct 30, 2014 at 10:09 AM, Brian Christopher Raaen <
> mailing-li...@br
IPv6 is production. Report the problem.
In message
, Javier J writes:
> Either is alcatel-lucent.com for the past 2 days I noticed. Ipv6 version of
> their site broken.
> On Oct 30, 2014 1:18 PM, "Brian Christopher Raaen" <
> mailing-li...@brianraaen.com> wrote:
>
> > It is now working over
On 10/30/2014 06:27 PM, Mark Andrews wrote:
> IPv6 is production. Report the problem.
>
Sorry for reporting it here, but there seems to be more than one problem
(the link resulting from clicking on "nist time".
I get the nist front page fine on v6, then click on the time link and
get a 404 lookin
In message <5452d146.4080...@altadena.net>, Pete Carah writes:
> On 10/30/2014 06:27 PM, Mark Andrews wrote:
> > IPv6 is production. Report the problem.
> >
> Sorry for reporting it here, but there seems to be more than one problem
> (the link resulting from clicking on "nist time".
What does re
Yes, and no.
If you are a given a limited resource (in this case, a physical port that
can process no more than 1gbps for example) and your efficiency in
transferring data over that port is not 100%, the provider itself is not to
blame. Each and every protocol has limitations, and in this case we
20 matches
Mail list logo
