So if I understand this correctly, with two tests running, each test
only manages about 50% of the bandwidth of the link?
Are these tests sending data in only one direction, or both?
If they are sending data in both directions, would it not make sense
that each can only use about half the link? A
On Nov 11, 2013, at 5:32 AM, Octavio Alvarez wrote:
> If you are trying to saturate the link in both directions each of the
> acknowledge packets will compete against the other stream and will have a
> hard time reaching back.
I first read this thread when I was half-asleep, stupid me - concu
Apply a shaper (not a policer) towards the service provider at each end
of 95Mbps or so (will probably require tweaking).
Single TCP session is probably managing to balance itself into the
~100Mbps circuit.
Two/many TCP sessions are probably bursting into a policer (and
effectively each othe
Le 11 nov. 2013 à 06:47, Brad Gould a écrit :
> Apply a shaper (not a policer) towards the service provider at each end of
> 95Mbps or so (will probably require tweaking).
Tried that, I applied a rate-limiter on my port facing my provider. No change...
>
> Single TCP session is probably man
Hello,
Thanks for this useful feedback.
Best regards.
Le 11 nov. 2013 à 06:32, Octavio Alvarez a écrit :
> On 11/10/2013 11:11 AM, Youssef Bengelloun-Zahr wrote:
- TCP traffic reaches up to 90 Mbits/s for one way streams (both
ways),
- TCP traffic hits some kind of
On 11/10/2013 11:11 AM, Youssef Bengelloun-Zahr wrote:
>>> - TCP traffic reaches up to 90 Mbits/s for one way streams (both
>>> ways),
>>>
>>> - TCP traffic hits some kind of limit and isn't able to achieve more
>>> than 40-60 Mbits/s in average <=== That's the problem we are facing
I
-
>> From: Youssef Bengelloun-Zahr
>> To: Randy
>> Cc: "cisco-nsp@puck.nether.net"
>> Sent: Sunday, November 10, 2013 1:26 PM
>> Subject: Re: [c-nsp] Effect of simultaneous TCP sessions on bandwidth
>>
>>
>>
>> Le 11 nov. 2013
Hello,
I don't have access to the CPE, or intermediate PEs, they are not under our
responsability.
Yes, we already been down that road and it has been increased more than enough
on both. Wireshark captures confirm that.
Thanks.
Le 11 nov. 2013 à 05:07, Richard Clayton a écrit :
> Whats th
Le 11 nov. 2013 à 04:22, Randy a écrit :
>
>
- TCP traffic hits some kind of limit and isn't able to achieve more
than 40-60 Mbits/s in average <=== That's the problem we are facing
>
> what happens if you do this -
>
>
> a transfer from host A(fra) to host B(ham) and
Whats the cpe cpu running at with both streams, have you tried adjusting
the window sizes on the servers, could help with bandwidth delay product.
On Sunday, 10 November 2013, Youssef Bengelloun-Zahr wrote:
> 2013/11/10 Phil Mayers >
>
> > On 11/10/2013 05:42 AM, Youssef Bengelloun-Zahr wrote:
>
2013/11/10 Phil Mayers
> On 11/10/2013 05:42 AM, Youssef Bengelloun-Zahr wrote:
>
> - UDP traffic reaches up to 95 Mbits/s for one way streams (both ways)
>> and simaltaneous bi-directionnal streams,
>>
>
> If there's no (significant) loss or reordering on a simultanous bi-dir UDP
> stream a
On 11/10/2013 05:42 AM, Youssef Bengelloun-Zahr wrote:
- UDP traffic reaches up to 95 Mbits/s for one way streams (both ways)
and simaltaneous bi-directionnal streams,
If there's no (significant) loss or reordering on a simultanous bi-dir
UDP stream at 95Mbit/sec, that suggests the pipe i
Hello Roland,
Yes, we have checked counters on all ports under our responsability, carriers'
equipments and third party LL provider.
At first, we discovered speed/duplex mismatch between WE and CPE on customer
site, this has been fixed since then.
Then, we saw output discards on CPE device (me
On Nov 10, 2013, at 1:09 PM, Youssef Bengelloun-Zahr wrote:
> Yes, sorry but I forgot to mention that we have activated every possible TCP
> extension on servers in order to support latency effects over long WAN
> distances.
Due to the nature of TCP, delay-product has throughput effects even i
Hello John,
Yes, sorry but I forgot to mention that we have activated every possible
TCP extension on servers in order to support latency effects over long WAN
distances.
Plus, latency is garantied end-to-end : 5 ms.
Best regards.
2013/11/10 John Osmon
> You don't mention latency for TCP wi
Hello community,
Need your help and hands on experience to shed some light on some problem
I'm facing.
We have contracted a Layer 2 ethernet connection hand-off between our DC
(Frankfurt) and a customer site (Hamburg) with a carrier.
Carrier provides us with an ethernet MPLS pipe up to a DC in h
16 matches
Mail list logo
