On 7/11/19 12:52 pm, Eugene Grosbein wrote:
> 07.11.2019 8:36, Lawrence Stewart wrote:
>
>>>> AES-GCM can run at over 1GB/sec on a single core, so as long as the
>>>> traffic can be processed by multiple threads (via multiple queues
>>>> for example), i
On 6/11/19 9:45 am, Olivier Cochard-Labbé wrote:
> On Tue, Nov 5, 2019 at 8:15 PM John-Mark Gurney wrote:
>
>> AES-GCM can run at over 1GB/sec on a single core, so as long as the
>> traffic can be processed by multiple threads (via multiple queues
>> for example), it should be doable.
>>
>>
> I d
On 09/05/2018 11:00, Lawrence Stewart wrote:
> On 09/05/2018 06:04, Tom Jones wrote:
>> On Tue, May 08, 2018 at 05:14:49PM +0530, Harsh Jain wrote:
>>> Hi All,
>>>
>>> We have observed memory leak with TCP network traffic in "newreno".
>>>
>
On 09/05/2018 06:04, Tom Jones wrote:
> On Tue, May 08, 2018 at 05:14:49PM +0530, Harsh Jain wrote:
>> Hi All,
>>
>> We have observed memory leak with TCP network traffic in "newreno".
>>
>> Output of vmstat -m
>>
>> in_mfilter 3 3K - 3 1024
>> in_multi 4 1K
On 29/03/2017 21:49, Rui Paulo wrote:
> On Wed, 2017-03-29 at 21:46 -0500, Lawrence Stewart wrote:
>> [resurrecting an old thread]
>>
>> On 19/06/2014 23:08, Hiroki Sato wrote:
>>> Larry Rosenman wrote
>>> in <20140619140801.ga65...@thebighonker.lerct
[resurrecting an old thread]
On 19/06/2014 23:08, Hiroki Sato wrote:
> Larry Rosenman wrote
> in <20140619140801.ga65...@thebighonker.lerctr.org>:
>
> le> > le> Ideas? (I may be an idiot, so any criticism welcomed).
> le> > le>
> le> > le> if you need the 1841's config, I can supply that as we
lstewart added a comment.
In https://reviews.freebsd.org/D5872#130806, @sepherosa_gmail.com wrote:
> In https://reviews.freebsd.org/D5872#130805, @lstewart wrote:
>
> > In https://reviews.freebsd.org/D5872#130179, @sepherosa_gmail.com wrote:
> >
> > > We probably can leave the cwnd
lstewart added a comment.
In https://reviews.freebsd.org/D5872#130179, @sepherosa_gmail.com wrote:
> We probably can leave the cwnd resetting to later rexmt timeout or possible
later fast retransmit (I think fast retransmit could kick in under some cases,
if ENOBUFS happened); instead of
lstewart added a comment.
In https://reviews.freebsd.org/D5872#128556, @hiren wrote:
> In https://reviews.freebsd.org/D5872#128555, @lstewart wrote:
>
> > I thought that had been fixed ages ago... oops.
>
>
> Fixed? i.e. doing something other than setting cwnd to 1 seg?
Y
lstewart added a comment.
I thought that had been fixed ages ago... oops. It should be calling
cc_cong_signal() with a new congestion type. Just leave that line as is for the
moment though as Mike says.
REVISION DETAIL
https://reviews.freebsd.org/D5872
EMAIL PREFERENCES
https://reviews.
lstewart added a comment.
... but replace with a macro to check that the rexmit/persist timer is armed
if appropriate!
REVISION DETAIL
https://reviews.freebsd.org/D5872
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences/
To: sepherosa_gmail.com, network, glebi
lstewart added a comment.
I agree with Mike's proposal (although FYI, I do belive tcp_output() will
send an ACK on RTO). TCP ACKs are intentionally unreliable by design and
setting the retransmit timer there is nonsense - either there is a bug
elsewhere which needs to be fixed, or it is try
Outback Dingo and Jason,
On 20/10/2015 10:43, Jason Hellenthal wrote:
> Hahaha was this written in notepad or did someone forget to turn off dos
> style line encodings.
>
>> On 20/10/2015 09:50, Outback Dingo wrote:
>> Nigel...
>>
>> seriously...
>>
Publicly ridiculing someone for such a minor
On 09/03/15 10:54, hiren panchasara wrote:
> I am failing to understand the reason behind this behavior.
>
> What should the congestion window (snd_cwnd) be set to when we hit loss?
> It seems that we set it to 1 segment right now.
> https://svnweb.freebsd.org/base/head/sys/netinet/tcp_input.c?rev
lstewart added a comment.
Ok, but that's anecdotal and gives us reviewers nothing to go on - without any
methodology or raw data who knows whether the LRO change is solely responsible
for the improvement and if it introduced any undesired side effects. It's also
possible that with tuning, the s
lstewart added a comment.
I hope I didn't delete it... from what I could see online, the "Abandon"
Phabricator action is the means by which a reviewer indicates they have
permanently rejected the patch (as opposed to suggesting changes).
As to people using the patch, can you say who and why?
lstewart abandoned this revision.
lstewart added a comment.
Hans,
Just because some hardware is capable of coalescing more than 64k of data
doesn't mean we should feel obligated to support the functionality. I'd be
curious to understand the anticipated use cases that led to hardware support
be
On 04/22/15 19:19, Peter Holm wrote:
> On Wed, Apr 22, 2015 at 11:45:21AM +1000, Lawrence Stewart wrote:
>> Hi Peter,
>>
>> On 04/15/15 21:04, Peter Holm wrote:
>>> Seen during i386 stress tests.
>>>
>>> db_trace_self_wrapper(c11e20fc,0,c11b79d4,1eb,
Hi all,
An interesting observation I made last night digging into some pcap
files captured on a server doing TSO/LRO and client side bridge seeing
all packets as they were on the wire...
When doing TSO, the NIC takes the stack supplied template IP/TCP header
and increments the IP ID field for eac
Hi Peter,
On 04/15/15 21:04, Peter Holm wrote:
> Seen during i386 stress tests.
>
> db_trace_self_wrapper(c11e20fc,0,c11b79d4,1eb,e47578e0,...) at
> db_trace_self_wrapper+0x2a/frame 0xe47578b0
> kdb_backtrace(c139e637,2,c120851d,e4757984,e4757940,...) at
> kdb_backtrace+0x2d/frame 0xe4757918
>
On 04/07/15 15:10, Marek Salwerowicz wrote:
> Hi list,
>
> I am trying to find correct setup of sysctl's for following machines
> (VMs under Vmware Workstation 8) to test large TCP window size:
>
>
> There are 2 boxes, each of them has following setup:
> - % uname -a
> FreeBSD freeA 10.1-RELEASE
On 03/24/15 07:49, Eggert, Lars wrote:
> Anyone else seeing this on -current right now?
>
> /usr/home/elars/src/sys/modules/siftr/../../netinet/siftr.c:493:7: error:
> data argument not used by format string [-Werror,-Wformat-extra-args]
> pkt_node->flowid,
>
[BCCed to freebsd-net@freebsd.org]
Hi all,
Please consider the code below from FreeBSD 10.1's TCP input processing:
/*
* In ESTABLISHED state: drop duplicate ACKs; ACK out of range
* ACKs. If the ack is in the range
* tp->snd_una < th->th_ack <= tp->snd_
Hi Midori (& Lars),
On 03/31/14 16:37, Midori Kato wrote:
> Hi FreeBSD developpers,
>
> I'm Midori Kato. I'm working on the DCTCP implementation in the FreeBSD
> with Lars Eggert. I mail you because I would like to ask you a code
> review and testing. The attached patch is not good enough to test
On 06/09/14 18:47, hiren panchasara wrote:
> On Mon, Jun 9, 2014 at 1:31 AM, Lawrence Stewart wrote:
>> On 6/8/2014 9:07 PM, hiren panchasara wrote:
>
>>> I wish to MFC this change and following actual dctcp changes (which
>>> I'll commit to -head in coming w
On 6/8/2014 9:07 PM, hiren panchasara wrote:
On Sun, Jun 1, 2014 at 12:31 AM, hiren panchasara
wrote:
On Tue, Apr 8, 2014 at 9:14 PM, hiren panchasara
wrote:
On Tue, Apr 8, 2014 at 8:46 PM, Adrian Chadd wrote:
Hi! Cool! can you file a FreeBSD PR with this?
I'm testing this patch right now
On 03/04/14 13:10, Kubilay Kocak wrote:
> On 5/03/2014 6:39 AM, hiren panchasara wrote:
>> On Wed, Aug 14, 2013 at 8:46 PM, Lawrence Stewart
>> wrote:
>>> On 08/15/13 02:44, Andre Oppermann wrote:
>>>> On 14.08.2013 04:36, Lawrence Stewart wrote:
>>>
On 08/15/13 02:44, Andre Oppermann wrote:
> On 14.08.2013 04:36, Lawrence Stewart wrote:
>> Hi Andre,
>>
>> [RE team is BCCed so they're aware of this discussion]
>>
>> On 07/06/13 00:58, Andre Oppermann wrote:
>>> Author: andre
>>> Date: F
Hi Lars,
On 08/14/13 18:46, Eggert, Lars wrote:
> Hi,
>
> On Aug 14, 2013, at 10:36, Lawrence Stewart wrote:
>> I don't think this change should have been MFCed, at least not in its
>> current form.
>
> FYI, Google's own data as presented in the HTTPBIS
On 08/14/13 16:33, Julian Elischer wrote:
> On 8/14/13 11:39 AM, Lawrence Stewart wrote:
>> On 08/14/13 03:29, Julian Elischer wrote:
>>> I have been tracking down a performance embarrassment on AMAZON EC2 and
>>> have found it I think.
>> Let us please avoid confl
On 08/14/13 03:29, Julian Elischer wrote:
> I have been tracking down a performance embarrassment on AMAZON EC2 and
> have found it I think.
Let us please avoid conflating performance with throughput. The
behaviour you go on to describe as a performance embarrassment is
actually a throughput diffe
Hi Andre,
[RE team is BCCed so they're aware of this discussion]
On 07/06/13 00:58, Andre Oppermann wrote:
> Author: andre
> Date: Fri Jul 5 14:58:24 2013
> New Revision: 252789
> URL: http://svnweb.freebsd.org/changeset/base/252789
>
> Log:
> MFC r242266:
>
>Increase the initial CWND
On 07/04/13 13:06, Outback Dingo wrote:
> On Wed, Jul 3, 2013 at 10:01 PM, Lawrence Stewart <mailto:lstew...@freebsd.org>> wrote:
>
> On 07/04/13 10:18, Kevin Oberman wrote:
> > On Wed, Jul 3, 2013 at 4:21 PM, Steven Hartland
> mailto:kill...@mu
On 07/04/13 10:18, Kevin Oberman wrote:
> On Wed, Jul 3, 2013 at 4:21 PM, Steven Hartland
> wrote:
>
>>
>> - Original Message - From: "Outback Dingo" >>
>> To: "Lawrence Stewart"
>> Cc:
>> Sent: Thursday, July 04, 2013
On 07/03/13 22:58, Outback Dingo wrote:
> On Wed, Jul 3, 2013 at 4:50 AM, Lawrence Stewart <mailto:lstew...@freebsd.org>> wrote:
>
> On 07/03/13 14:28, Outback Dingo wrote:
> > Ive got a high end storage server here, iperf shows decent network io
> >
On 07/03/13 14:28, Outback Dingo wrote:
> Ive got a high end storage server here, iperf shows decent network io
>
> iperf -i 10 -t 20 -c 10.0.96.1 -w 2.5M -l 2.5M
>
> Client connecting to 10.0.96.1, TCP port 5001
> TCP window size: 2.50
On 05/09/13 11:51, Ouyahia Nourimane wrote:
> hello, i'm a student
> i have a project about mipv6 and i wish that you can help me
> i want to test mipv6 with freebsd but i didn't realize how to configure
> kame
> which is the last version that support kame and can you give me iso image
> of this ve
, Angelogiannopoulos, Aris wrote:
> On 05/06/13 18:31, Lawrence Stewart wrote:
>> On 05/06/13 18:18, Angelogiannopoulos, Aris wrote:
>>> I noticed that the sent_inflight_bytes variable doesn’t take
>>> into account the SACKd bytes in case SACK is used.
>>>
>>
start playing with the code and
provide feedback, bug reports, fixes, praise and/or abuse ;)
The "Multipath TCP for FreeBSD" project team consists of:
Nigel Williams: lead R&D engineer
Lawrence Stewart: supporting R&D engineer
Grenville Armitage: principal inve
On 03/06/13 01:03, Andre Oppermann wrote:
> On 05.03.2013 04:21, Lawrence Stewart wrote:
>> On 03/05/13 03:35, Andre Oppermann wrote:
>>> On 26.02.2013 14:38, Lawrence Stewart wrote:
>>>> Hi Andre,
>>>
>>> Hi Lawrence, :-)
>>>
>&
On 03/05/13 03:35, Andre Oppermann wrote:
> On 26.02.2013 14:38, Lawrence Stewart wrote:
>> Hi Andre,
>
> Hi Lawrence, :-)
>
>> A colleague and I spent a very frustrating day tracing an accounting bug
>> in the multipath TCP patch we're working on at CAIA t
Hi Andre,
A colleague and I spent a very frustrating day tracing an accounting bug
in the multipath TCP patch we're working on at CAIA to a bug in
sbsndptr(). I haven't tested it with regular TCP yet, but I believe the
following patch fixes the bug (proposed commit log message is at the top
of the
On 02/21/13 20:20, Sepherosa Ziehau wrote:
> On Wed, Feb 20, 2013 at 11:59 AM, Lawrence Stewart
> wrote:
>> Hi Sephe,
>>
>> On 02/20/13 13:37, Sepherosa Ziehau wrote:
>>> On Wed, Feb 20, 2013 at 9:46 AM, Lawrence Stewart
>>> wrote:
>>&g
Hi Sephe,
On 02/20/13 13:37, Sepherosa Ziehau wrote:
> On Wed, Feb 20, 2013 at 9:46 AM, Lawrence Stewart wrote:
>> *crickets chirping*
>>
>> Time to move this discussion forward...
>>
>>
>> If any robust counter-arguments exist, now is the time for us t
*crickets chirping*
Time to move this discussion forward...
On 02/14/13 12:36, Lawrence Stewart wrote:
> On 02/14/13 01:48, Andre Oppermann wrote:
>> On 13.02.2013 15:26, Lawrence Stewart wrote:
>>> On 02/13/13 21:27, Andre Oppermann wrote:
>>>> On 13.02.2013
On 02/14/13 05:37, Adrian Chadd wrote:
> On 13 February 2013 02:27, Andre Oppermann wrote:
>
>> Again I'd like to point out that this sort of modification should
>> be implemented as a congestion control module. All the hook points
>> are already there and can readily be used instead of adding m
On 02/14/13 01:48, Andre Oppermann wrote:
> On 13.02.2013 15:26, Lawrence Stewart wrote:
>> On 02/13/13 21:27, Andre Oppermann wrote:
>>> On 13.02.2013 09:25, Lawrence Stewart wrote:
>>>> The idea is useful. I'd just like to discuss the implementation
>
On 02/13/13 21:27, Andre Oppermann wrote:
> On 13.02.2013 09:25, Lawrence Stewart wrote:
>> FYI I've read the whole thread as of this reply and plan to follow up to
>> a few of the other posts separately, but first for my initial thoughts...
>>
>> On 01/23/13 07:
On 02/10/13 16:05, Kevin Oberman wrote:
> On Sat, Feb 9, 2013 at 6:41 AM, Alfred Perlstein wrote:
>> On 2/7/13 12:04 PM, George Neville-Neil wrote:
>>>
>>> On Feb 6, 2013, at 12:28 , Alfred Perlstein wrote:
>>>
On 2/6/13 4:46 AM, John Baldwin wrote:
>
> On Wednesday, February 06, 201
On 02/08/13 07:04, George Neville-Neil wrote:
>
> On Feb 6, 2013, at 12:28 , Alfred Perlstein wrote:
>
>> On 2/6/13 4:46 AM, John Baldwin wrote:
>>> On Wednesday, February 06, 2013 6:27:04 am Randall Stewart wrote:
John:
A burst at line rate will *often* cause drops. This is becau
FYI I've read the whole thread as of this reply and plan to follow up to
a few of the other posts separately, but first for my initial thoughts...
On 01/23/13 07:11, John Baldwin wrote:
> As I mentioned in an earlier thread, I recently had to debug an issue we were
> seeing across a link with a h
On 01/25/13 01:12, Andre Oppermann wrote:
> On 24.01.2013 14:28, Lawrence Stewart wrote:
>> On 01/16/13 06:27, John Baldwin wrote:
>>> One other thing I noticed which is may or may not be odd during this,
>>> is that
>>> if you have a connection with TCP_NODELA
On 01/16/13 06:27, John Baldwin wrote:
> On Tuesday, January 15, 2013 3:29:51 am Lawrence Stewart wrote:
>> Hi John,
>>
>> On 01/15/13 08:04, John Baldwin wrote:
>>> I was looking at TCP congestion control at work recently and noticed a few
>>
>> Poor
On 01/23/13 07:28, John Baldwin wrote:
> On Tuesday, January 22, 2013 3:57:23 am Lawrence Stewart wrote:
>> On 01/16/13 06:16, John Baldwin wrote:
>>> On Tuesday, January 15, 2013 3:49:33 am Lawrence Stewart wrote:
>>>> On 01/15/13 07:50, John Baldwin wrote:
>&g
On 01/16/13 06:16, John Baldwin wrote:
> On Tuesday, January 15, 2013 3:49:33 am Lawrence Stewart wrote:
>> On 01/15/13 07:50, John Baldwin wrote:
>>> The constants used for TCP and UDP socket options (TCP_NODELAY, etc.) are
>>> currently defined as hex values that ar
On 01/16/13 02:12, Eggert, Lars wrote:
> Hi,
>
> On Jan 15, 2013, at 14:09, Lawrence Stewart wrote:
>> You're not dense - the build glue to allow an algorithm to be specified
>> in a kernel config file doesn't exist.
>
> ah, that explains it. I guess it doe
Hi Lars,
On 01/15/13 23:47, Eggert, Lars wrote:
> Hi,
>
> mod_cc(4) says:
>
> Algorithm modules can be compiled into the kernel or loaded as kernel
> modules using the kld(4) facility.
>
> Maybe I'm dense, but I can't figure out how to statically compile
> mod_cc modules into the kernel? (I'm u
On 01/15/13 07:50, John Baldwin wrote:
> The constants used for TCP and UDP socket options (TCP_NODELAY, etc.) are
> currently defined as hex values that are individual bits. However, socket
> options are never masked together, they are used as a simple enumeration of
> discrete values. Using
Hi John,
On 01/15/13 08:04, John Baldwin wrote:
> I was looking at TCP congestion control at work recently and noticed a few
Poor you ;)
> "odd" things in the current code. First, there is this chunk of code in
> cc_ack_received() in tcp_input.c:
>
> static void inline
> cc_ack_received(stru
On 10/12/12 03:25, Eggert, Lars wrote:
Hi,
is anyone in BSD-land working on de-bufferbloating the kernel, similar to what
the Linux folks are currently doing?
I'll be committing the CAIA Delay-Gradient (CDG) TCP congestion control
algorithm shortly. It's still experimental, but it has some u
On 06/04/12 13:33, Colin Percival wrote:
On 06/03/12 20:14, Lawrence Stewart wrote:
On 06/04/12 02:51, Colin Percival wrote:
I've attached a new patch which:
1. adds a IFCAP_TSO_MSS "capability" and a if_tx_tso_mss field to struct ifnet,
A minor thing, but I don't like th
On 06/04/12 02:51, Colin Percival wrote:
On 05/30/12 08:30, Andrew Gallatin wrote:
On 05/30/12 10:59, Colin Percival wrote:
The Xen virtual network interface has an issue (ok, really the issue is with
the linux back-end, but that's what most people are using) where it can't
handle scatter-gathe
On 06/03/12 15:18, Kevin Oberman wrote:
On Fri, Jun 1, 2012 at 2:48 AM, Lawrence Stewart wrote:
On 05/31/12 13:33, Kevin Oberman wrote:
[snip]
I used SIFTR at the suggestion of Lawrence Stewart who headed the
project to bring plugable congestion algorithms to FreeBSD and found
really odd
On 05/31/12 13:33, Kevin Oberman wrote:
[snip]
I used SIFTR at the suggestion of Lawrence Stewart who headed the
project to bring plugable congestion algorithms to FreeBSD and found
really odd congestion behavior. First, I do see a triple ACK, but the
congestion window suddenly drops from 73K to
n unusual cases.
I used SIFTR at the suggestion of Lawrence Stewart who headed the
project to bring plugable congestion algorithms to FreeBSD and found
really odd congestion behavior. First, I do see a triple ACK, but the
congestion window suddenly drops from 73K to 8K. If I understand
CUBIC, it sho
On 10/26/11 22:53, John Baldwin wrote:
On Wednesday, October 26, 2011 3:54:31 am Pawel Jakub Dawidek wrote:
On Mon, Oct 24, 2011 at 08:14:22AM -0400, John Baldwin wrote:
On Sunday, October 23, 2011 11:58:28 am Pawel Jakub Dawidek wrote:
On Sun, Oct 23, 2011 at 11:44:45AM +0300, Kostik Belousov
On 10/22/11 19:49, Pawel Jakub Dawidek wrote:
The panic message says:
panic: tcp_input negative window: tp 0xfe007763e000 rcv_nxt
3718269252 rcv_adv 3718268291
I only have picture of the backtrace:
http://people.freebsd.org/~pjd/misc/panic_negative_window.jpg
ewww that
Sorry for the delay in responding.
On 08/29/11 21:30, Andre Oppermann wrote:
On 29.08.2011 02:08, Lawrence Stewart wrote:
On 08/14/11 23:53, Steven Hartland wrote:
- Original Message - From: "Lawrence Stewart"
Here's my tweaked version of Andre's patch:
http:
On 08/14/11 23:53, Steven Hartland wrote:
- Original Message - From: "Lawrence Stewart"
Here's my tweaked version of Andre's patch:
http://people.freebsd.org/~lstewart/patches/misctcp/tcp_reass.c-logdebug%2bmissingsegment-20110811-lstewart.diff
Still testing t
On 08/11/11 22:31, Slawa Olhovchenkov wrote:
On Thu, Aug 11, 2011 at 11:30:29AM +1000, Lawrence Stewart wrote:
On 08/05/11 16:57, Slawa Olhovchenkov wrote:
On Fri, Aug 05, 2011 at 12:02:18AM +1000, Lawrence Stewart wrote:
[snip]
The real fix which is somewhere down on my todo list is to
On 08/05/11 16:57, Slawa Olhovchenkov wrote:
On Fri, Aug 05, 2011 at 12:02:18AM +1000, Lawrence Stewart wrote:
[snip]
The real fix which is somewhere down on my todo list is to make all
these memory constraints elastic and respond to VM pressure, thus
negating the need for a hard limit at all
On 08/05/11 00:19, Steven Hartland wrote:
- Original Message - From: "Lawrence Stewart"
[snip]
So I suppose the question is should maxsegments be larger by
default due to the recent changes e.g.
- V_tcp_reass_maxseg = nmbclusters / 16;
+ V_tcp_reass_maxseg = nmbclusters /
Hi Steven, Andre and Slawa,
Firstly, sorry for the delay diving into this. I just returned from some
travel.
Comments inline...
On 08/02/11 21:35, Steven Hartland wrote:
- Original Message - From: "Steven Hartland"
- Original Message - From: "Andre Oppermann"
...
I believe
On 02/01/11 04:17, John Baldwin wrote:
> Somewhat related fallout to the bug reported on security@ recently, I think
> this KASSERT() in tcp_output() is bogus:
>
>
> KASSERT(len + hdrlen + ipoptlen == m_length(m, NULL),
> ("%s: mbuf chain shorter than expected", __func__));
>
>
s
> distributed over a number of developers who take various interests in
> the topic. At the risk of pointing fingers:
>
> Lawrence Stewart has recently been involved in pluggable
> congestion control, new congestion control algorithms, TCP tracing, and
> various other things,
On 11/13/10 00:18, Lawrence Stewart wrote:
> On 11/12/10 21:41, Kostik Belousov wrote:
>> On Fri, Nov 12, 2010 at 09:21:29PM +1100, Lawrence Stewart wrote:
>>> On 11/12/10 20:44, Lawrence Stewart wrote:
>>>> On 11/07/10 17:32, Lawrence Stewart wrote:
>>>>
On 11/12/10 21:41, Kostik Belousov wrote:
> On Fri, Nov 12, 2010 at 09:21:29PM +1100, Lawrence Stewart wrote:
>> On 11/12/10 20:44, Lawrence Stewart wrote:
>>> On 11/07/10 17:32, Lawrence Stewart wrote:
>>>> On 11/03/10 09:30, Andre Oppermann wrote:
>>>>
On 11/12/10 20:44, Lawrence Stewart wrote:
> On 11/07/10 17:32, Lawrence Stewart wrote:
>> On 11/03/10 09:30, Andre Oppermann wrote:
>>> On 02.11.2010 01:11, Maxim Dounin wrote:
>>>> Hello!
>>>>
>>>> On Mon, Sep 27, 2010 at 03:17:59PM +0200,
Hi All,
A quick note that this evening, I made the first in a series of upcoming
commits to head that modify the TCP stack fairly significantly. I have
no reason to believe you'll notice any issues, but TCP is a complex
beast and it's possible things might crop up. The changes are mostly
related t
On 11/07/10 17:32, Lawrence Stewart wrote:
> On 11/03/10 09:30, Andre Oppermann wrote:
>> On 02.11.2010 01:11, Maxim Dounin wrote:
>>> Hello!
>>>
>>> On Mon, Sep 27, 2010 at 03:17:59PM +0200, Andre Oppermann wrote:
>>>
>>>> On 27.09.2010 1
On 11/12/10 07:39, Julian Elischer wrote:
> On 11/11/10 6:36 AM, Christopher Penney wrote:
>> Hi,
>>
>> I have a curious problem I'm hoping someone can help with or at least
>> educate me on.
>>
>> I have several large Linux clusters and for each one we hide the compute
>> nodes behind a head node
On 11/03/10 09:30, Andre Oppermann wrote:
> On 02.11.2010 01:11, Maxim Dounin wrote:
>> Hello!
>>
>> On Mon, Sep 27, 2010 at 03:17:59PM +0200, Andre Oppermann wrote:
>>
>>> On 27.09.2010 10:12, Maxim Dounin wrote:
Hello!
On Mon, Sep 13, 2010 at 09:24:53PM +0400, Maxim Dounin wrote:
>
On 10/25/10 17:40, Sriram Gorti wrote:
> Hi,
>
> On Sat, Oct 23, 2010 at 5:29 AM, Lawrence Stewart
> wrote:
>> On 10/22/10 18:10, Sriram Gorti wrote:
>>> Hi,
>>>
>>> On Mon, Oct 18, 2010 at 3:08 AM, Lawrence Stewart
>>> wrote:
>>&
On 10/22/10 18:10, Sriram Gorti wrote:
> Hi,
>
> On Mon, Oct 18, 2010 at 3:08 AM, Lawrence Stewart
> wrote:
>> On 10/04/10 22:12, Lawrence Stewart wrote:
>>> On 10/01/10 22:20, Andre Oppermann wrote:
>>>> On 01.10.2010 12:01, Sriram Gorti wrote:
>&
On 10/18/10 23:19, Julian Stecklina wrote:
> Hello,
>
> I am trying to find out what the status of Mobile IPv6 in the FreeBSD
> network stack is. So far I discovered some traces in the rtadvd man
> page, but the rtadvd code doesn't seem to contain Mobile IPv6
> support.. The most recent info I fou
On 10/04/10 22:12, Lawrence Stewart wrote:
> On 10/01/10 22:20, Andre Oppermann wrote:
>> On 01.10.2010 12:01, Sriram Gorti wrote:
>>> Hi,
>>>
>>> In the following is an observation when testing our XLR/XLS network
>>> driver with 16 concurrent instance
On 10/01/10 22:20, Andre Oppermann wrote:
> On 01.10.2010 12:01, Sriram Gorti wrote:
>> Hi,
>>
>> In the following is an observation when testing our XLR/XLS network
>> driver with 16 concurrent instances of netperf on FreeBSD-CURRENT.
>> Based on this observation, I have a question on which I hope
ny feedback and hope you enjoy playing with the code
and tools.
Cheers,
Lawrence Stewart, David Hayes and Grenville Armitage
http://caia.swin.edu.au
NB: "CAIA-Hamilton Delay" and "Hamilton Delay" are our working names for
algorithms which do not have established names in
Hi Igor,
I'm sorry I missed this way back when you sent it.
On 05/12/10 22:47, Igor Sysoev wrote:
It seems that net.inet.tcp.slowstart_flightsize does not work in 8-STABLE.
For a long time I used slowstart_flightsize=2 on FreeBSD 4, 6, and 7 hosts.
However, FreeBSD-8 always starts with the sing
On 06/10/10 04:44, Jung-uk Kim wrote:
bpf(4) can only timestamp packets with microtime(9). I want to expand
it to be able to use different format and resolution. The patch is
here:
http://people.freebsd.org/~jkim/bpf_tstamp.diff
With this patch, we can select different format and resolution o
On 05/05/10 06:51, sth...@nethelp.no wrote:
The following was done on a 7.3-STABLE system.
While debugging an IPv6 path MTU problem I discovered to my surprise
that the TCP host cache (use "sysctl net.inet.tcp.hostcache.list" to
see it) is also used by UDP and ICMP, at least for IPv6. Scenario:
On 02/05/10 19:34, Lawrence Stewart wrote:
Hi Frank,
On 02/03/10 00:11, Frank Schuster wrote:
Hello,
[snip]
1.) Is this in freebsd possible and if it, how is it?
Have a look at the SIFTR tool I've been working on. You can grab it from
here:
http://people.freebsd.org/~lstewart/pa
Hi Frank,
On 02/03/10 00:11, Frank Schuster wrote:
Hello,
I want to debug a tcp connection but I can't find how can I do this.
I want to plot the cwnd and ssthresh over the time.
I come from the "linux-world" and there is tcp_probe, but what can I do on
Freebsd.
1.) Is this in freebsd possib
Hi Jerry,
On 02/01/10 09:49, Jerry Toung wrote:
Hello list,
my employer is asking me to implement westwood, this is most likely happen
on 8.0.
before I start, I'd like to know for what reason it hasn't been done in the
main tree?
is it that no one has had time, or it only work in a lab environm
Doug Barton wrote:
I cc'ed those who seem to have put the most/recent effort into
sys/dev/wpi.
Is there any objection to turning off WPI_DEBUG by default? it creates
a lot of spam that the average user doesn't need. I use my 3945abg
every day and haven't had any problems with it for ages so I th
Bernhard Schmidt wrote:
On Friday 09 October 2009 19:08:39 Lutz Bichler wrote:
Hi,
does anybody know what happened to the attempts to support Intel WiFi
5100/5300 interfaces in the iwn-driver? Are any patches available which
could be used to start working on support for these interfaces?
I'
Hi All,
I have an Intel 3945ABG in my Toshiba R600 laptop which fairly reliably
panics a while after I associate it with a WPA AP. It will happily
associate and pass packets for some time (10's of minutes) and then
panic. I have managed to trigger it both times I've tried to associate
with th
Learner Study wrote:
Hello experts:
Is there is reason why freebsd TCP implementation limits the number of SACK
blocks on receiver side to MAX_SACK_BLOCKS whereas the sender side SACK
holes are implemented as a linked list?
Any issues if someone decides to use receiver side linked list as well
Hi Qing,
Qing Li wrote:
Qing (added to CC) is aware of the problem. Not sure how far
off the fix is.
I am resuming the work on it, hoping to get it verified and
finalized in a day or so. Sorry about the delay.
Did this ever get fixed? I don't think I saw a follow up to this thread
so just
Hi All,
I'm very pleased to announce the release of a significantly improved
version of our SIFTR (Statistical Information For TCP Research) tool
for FreeBSD. It can be obtained from [1], along with other papers,
patches and software useful for protocol analysis, debugging and
experimental resear
1 - 100 of 117 matches
Mail list logo
