The last linux graphs are wrong - sorry! (Thanks for the hint, much to
low RTT and small window)
I graphed the wrong direction of the session.
Now updated graphs:
network io bits/sec:
FreeBSD: http://devel.crossip.net/freebsd_receiver.jpg
Linux: http://devel.crossip.net/linux_receiver.jp
The sender dump shows, that the network-card does tso.
From Marc's dump at receiver site:
network io bits/sec:
FreeBSD: http://devel.crossip.net/freebsd_receiver.jpg
Linux: http://devel.crossip.net/linux_receiver.jpg
During the "breaks" between the transfer, I see tcp retransmissions (b
--- On Fri, 11/23/12, Andre Oppermann wrote:
> From: Andre Oppermann
> Subject: Re: Low Bandwidth on intercontinental connections
> To: "Ingo Flaschberger"
> Cc: freebsd-net@freebsd.org
> Date: Friday, November 23, 2012, 10:05 AM
> On 23.11.2012 15:46, Ingo
On 11/23/2012 03:46 PM, Ingo Flaschberger wrote:
> Am 23.11.2012 13:47, schrieb Marc Peters:
>> PR filed: http://www.freebsd.org/cgi/query-pr.cgi?pr=173859
>
> Downloads from ftp1.us.freebsd.org to Europe (ping time ~170ms), I see
> up & down ramping of transfer speed (600kb/sec - 50kb/sec)
> ove
On 23.11.2012 15:46, Ingo Flaschberger wrote:
Am 23.11.2012 13:47, schrieb Marc Peters:
PR filed: http://www.freebsd.org/cgi/query-pr.cgi?pr=173859
Downloads from ftp1.us.freebsd.org to Europe (ping time ~170ms), I see up &
down ramping of transfer
speed (600kb/sec - 50kb/sec)
over serverall
Am 23.11.2012 13:47, schrieb Marc Peters:
PR filed: http://www.freebsd.org/cgi/query-pr.cgi?pr=173859
Downloads from ftp1.us.freebsd.org to Europe (ping time ~170ms), I see
up & down ramping of transfer speed (600kb/sec - 50kb/sec)
over serverall releases:
FreeBSD 6.3-PRERELEASE
FreeBSD 7.2-S
On 23 November 2012 04:47, Marc Peters wrote:
> On 11/22/2012 06:09 PM, Adrian Chadd wrote:
>> Hi Marc,
>>
>> You definitely have enough information now for a PR. Would you please
>> file all of this into a PR so one of the IP stack people can take a
>> look?
>
> PR filed:
>
> http://www.freebsd.o
On 11/22/2012 06:09 PM, Adrian Chadd wrote:
> Hi Marc,
>
> You definitely have enough information now for a PR. Would you please
> file all of this into a PR so one of the IP stack people can take a
> look?
PR filed:
http://www.freebsd.org/cgi/query-pr.cgi?pr=173859
>
> Thanks,
>
>
> Adrian
nearly every packet is fragmented, if i read th [TCP segment of a
reassembled PDU] correct. Those have a length of 1364. Thera are also
lots of [TCP Window Update] (every two to three acks from the receiving
host, where the tcpdump took place). After some time, there were lots of
[TCP Dup ACK] fro
Hi Marc,
You definitely have enough information now for a PR. Would you please
file all of this into a PR so one of the IP stack people can take a
look?
Thanks,
Adrian
On 22 November 2012 07:42, Marc Peters wrote:
> On 11/22/2012 02:20 PM, Ingo Flaschberger wrote:
>> Am 22.11.2012 13:38, sch
On 11/22/2012 02:20 PM, Ingo Flaschberger wrote:
> Am 22.11.2012 13:38, schrieb Marc Peters:
>> interesting, the MTU is way lower, than i expected. Through the VPN
>> tunnel, only 1322 bytes are possible without fragmentation. ScreenOS
>> adds 42 additional bytes per paket and the FreeBSD box is re
--- Original message ---
From: "Ingo Flaschberger"
To: freebsd-net@freebsd.org
Date: 22 November 2012, 15:27:48
Subject: Re: Low Bandwidth on intercontinental connections
> Am 22.11.2012 14:16, schrieb Ingo Flaschberger:
> >
> >
> >>> *) try a ra
Am 22.11.2012 14:16, schrieb Ingo Flaschberger:
*) try a rate-shaping queue outgoing (not really good - as shaping
works
best on incomming interfaces):
sorry - told something wrong.
shapeing works best on outgoing interfaces (not incomming)
you need dummynet (and ipfw for this example):
Am 22.11.2012 13:38, schrieb Marc Peters:
interesting, the MTU is way lower, than i expected. Through the VPN
tunnel, only 1322 bytes are possible without fragmentation. ScreenOS
adds 42 additional bytes per paket and the FreeBSD box is receiving
1364 bytes, according to tcpdump. From the outsi
Am 22.11.2012 13:38, schrieb Marc Peters:
interesting, the MTU is way lower, than i expected. Through the VPN
tunnel, only 1322 bytes are possible without fragmentation. ScreenOS
adds 42 additional bytes per paket and the FreeBSD box is receiving 1364
bytes, according to tcpdump. From the outside
On 11/22/2012 12:22 PM, Ingo Flaschberger wrote:
>
>>> *) check and compare tcpdump
>> for the FreeBSD hosts on the receiver side, it showed a lot of window
>> size changes and from time to time a lot of duplicate ACKs. i will file
>> a PR (as Adrian asked) and see to get a matching tcpdump and SI
*) check and compare tcpdump
for the FreeBSD hosts on the receiver side, it showed a lot of window
size changes and from time to time a lot of duplicate ACKs. i will file
a PR (as Adrian asked) and see to get a matching tcpdump and SIFTR output.
*) can you check which ping-sizes work?
ping
On 11/22/2012 10:57 AM, wishmaster wrote:
>
>> The ping times are okay, as for the distance (DE to US):
>>
>> ping 172.16.3.10
>> PING 172.16.3.10 (172.16.3.10) 56(84) bytes of data.
>> 64 bytes from 172.16.3.10: icmp_req=1 ttl=62 time=155 ms
>> 64 bytes from 172.16.3.10: icmp_req=2 ttl=62 time=15
On 11/21/2012 07:49 PM, Julian Elischer wrote:
> On 11/21/12 7:41 AM, Marc Peters wrote:
>> Hi list,
>>
>> we are experiencing low throughput on interncontinental connections with
>> our FreeBSD Servers. We made several tests and are wondering, why this
>> would be. The first tests were on an IPSEC
On 11/21/2012 06:52 PM, Ingo Flaschberger wrote:
> Am 21.11.2012 18:32, schrieb Marc Peters:
>> Hi Ben,
>>
>> i don't think this is memory related, too. We used plain CLI scp ot ftp
>> from base, both times.
>>
>> Here is the requested data:
>>
>> Linux ---> FreeBSD:
>>
>> root@linux:~# scp jdk-6u3
On 11/22/2012 12:22 AM, Andre Oppermann wrote:
> On 21.11.2012 16:41, Marc Peters wrote:
>> Hi list,
>>
> -snip-
>> Doing some googling brought up a lot of tuning hints, but nothing worked
>> for us. We tweaked some sysctls:
>>
>> kern.ipc.maxsockbuf=16777216
>> net.inet.tcp.sendbuf_max=16777216
>>
On 21.11.2012 16:41, Marc Peters wrote:
Hi list,
-snip-
Doing some googling brought up a lot of tuning hints, but nothing worked
for us. We tweaked some sysctls:
kern.ipc.maxsockbuf=16777216
net.inet.tcp.sendbuf_max=16777216
net.inet.tcp.recvbuf_max=16777216
net.inet.tcp.sendbuf_inc=16384
net
.. and there's also some SACK stuff and RTT prediction that you may be
totally running afoul of over that high latency link?
(I thought this stuff was fixed in -HEAD and -9?)
Adrian
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mai
On 11/21/12 7:41 AM, Marc Peters wrote:
Hi list,
we are experiencing low throughput on interncontinental connections with
our FreeBSD Servers. We made several tests and are wondering, why this
would be. The first tests were on an IPSEC VPN between our datacenter in
DE and Santa Clara, CA. We are
Hi!
Firstly - please file a PR.
Secondly - there's some great tcp counters in 'netstat -sp tcp' (and
ip, and udp, and icmp.) You can zero them; netstat -sp tcp -z. I
suggest dumping them before/after and compare the values.
Adrian
On 21 November 2012 07:41, Marc Peters wrote:
> Hi list,
>
>
Am 21.11.2012 18:32, schrieb Marc Peters:
Hi Ben,
i don't think this is memory related, too. We used plain CLI scp ot ftp
from base, both times.
Here is the requested data:
Linux ---> FreeBSD:
root@linux:~# scp jdk-6u33-linux-x64.bin 172.16.3.10:
Password:
jdk-6u33-linux-x64.bin
On Wed, Nov 21, 2012 at 9:20 AM, Kevin Oberman wrote:
> On Wed, Nov 21, 2012 at 8:58 AM, Benjamin Villain
> wrote:
> > I don't think this is about disk or memory leak as transfering files
> locally
> > seem to work fine.
> >
> > Can you test transferring files from (and to) your Linux boxes to (
On 11/21/2012 05:58 PM, Benjamin Villain wrote:
> I don't think this is about disk or memory leak as transfering files
> locally seem to work fine.
>
> Can you test transferring files from (and to) your Linux boxes to (and
> from) the FreeBSD servers to check that it is not a network issue inside
On Wed, Nov 21, 2012 at 8:58 AM, Benjamin Villain
wrote:
> I don't think this is about disk or memory leak as transfering files locally
> seem to work fine.
>
> Can you test transferring files from (and to) your Linux boxes to (and from)
> the FreeBSD servers to check that it is not a network issu
I don't think this is about disk or memory leak as transfering files locally
seem to work fine.
Can you test transferring files from (and to) your Linux boxes to (and from) the
FreeBSD servers to check that it is not a network issue inside your DCs.
King regards,
--
Ben
Mehmet Erol Sanlit
On Wed, Nov 21, 2012 at 7:41 AM, Marc Peters wrote:
> Hi list,
>
> we are experiencing low throughput on interncontinental connections with
> our FreeBSD Servers. We made several tests and are wondering, why this
> would be. The first tests were on an IPSEC VPN between our datacenter in
> DE and
Hi list,
we are experiencing low throughput on interncontinental connections with
our FreeBSD Servers. We made several tests and are wondering, why this
would be. The first tests were on an IPSEC VPN between our datacenter in
DE and Santa Clara, CA. We are connected with two gigabit uplinks in
eac
32 matches
Mail list logo
