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 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/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/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
*) 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 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
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
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 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):
--- On Wed, 11/21/12, Adrian Chadd wrote:
> From: Adrian Chadd
> Subject: Re: FreeBSD boxes as a 'router'...
> To: "Andre Oppermann"
> Cc: "Barney Cordoba" , "Jim Thompson"
> , "Alfred Perlstein" , khatfi...@socllc.net,
> "freebsd-net@freebsd.org"
> Date: Wednesday, November 21, 2012, 1:26
--- 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 rate-shaping queue outgoing (not really
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
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
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
14 matches
Mail list logo
