On Feb 10, 2013, at 11:36, Andrey Zonov wrote:
> Google made many many TCP tweaks. Increased initial window, small RTO,
> enabled ignore after idle and others. They published that, other people
> just blindly applied these tunings and the Internet still works.
MANY people are experimenting with
The following reply was made to PR bin/131567; it has been noted by GNATS.
From: Andrey Simonenko
To: bug-follo...@freebsd.org
Cc:
Subject: Re: bin/131567: Update for regression/sockets/unix_cmsg
Date: Mon, 11 Feb 2013 11:38:02 +0200
Correctness of unix_cmsg verified on 7.1-STABLE, 9.1-STABLE
Note: to view an individual PR, use:
http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).
The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.
S Tracker
On 09.02.2013 15:41, Alfred Perlstein wrote:
However, the end result must be far different than what has occurred so far.
If the code was deemed unacceptable for general inclusion, then we must find a
way to provide a
light framework to accomplish the needs of the community member.
We've got
On 05.02.2013 22:40, John Baldwin wrote:
On Tuesday, February 05, 2013 12:44:27 pm Andre Oppermann wrote:
I would prefer to encapsulate it into its own not-so-much-congestion-management
algorithm so you can eventually do other tweaks as well like more aggressive
loss recovery which would fit you
On 10.02.2013 11:36, Andrey Zonov wrote:
On 2/10/13 9:05 AM, Kevin Oberman wrote:
This is a subject rather near to my heart, having fought battles with
congestion back in the dark days of Windows when it essentially
defaulted to TCPIGNOREIDLE. It was a huge pain, but it was the only
way Windows
Synopsis: [socket] [patch] Update for regression/sockets/unix_cmsg
Responsible-Changed-From-To: freebsd-net->pluknet
Responsible-Changed-By: pluknet
Responsible-Changed-When: Mon Feb 11 12:27:51 UTC 2013
Responsible-Changed-Why:
Take.
http://www.freebsd.org/cgi/query-pr.cgi?pr=131567
___
Old Synopsis: flow control systcl consistency for em drivers
New Synopsis: [em] [patch] flow control systcl consistency for em drivers
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Mon Feb 11 14:11:01 UTC 2013
Responsible-Changed-W
On Sun, Feb 10, 2013 at 12:02 AM, Ronald F. Guilmette
wrote:
>
>
> I want to thank all of the various people who offered help, advice,
> and suggestings regarding this problem. It's all really appreciated.
>
> Since I first posted about this issue, I have diligently tried to
> isolate/debug the p
On 11 February 2013 03:18, Andre Oppermann wrote:
> In general Google does provide quite a bit of data with their experiments
> showing that it isn't harmful and that it helps the case.
>
> Smaller RTO (1s) has become a RFC so there was very broad consensus in
> TCPM that is a good thing. We don
Hi all,
During my efforts to convert ath(4) and net80211(4) to if_transmit
based queues, I've noticed that the error counters aren't being
incremented correctly.
In the ifq past, the _ENQUEUE macro(s) did this, with a call to
IFQ_DROP() if the frame is being dropped.
This was done behind the ifq
On Fri, 2013-02-08 at 10:16 -0800, Jack Vogel wrote:
> For those that may have run across the story on Slashdot about this NIC,
> here is our statement:
>
> Recently there were a few stories published, based on a blog post by an
> end-user, suggesting specific network packets may cause the Intel®
Old Synopsis: TCP wrappers caused quite a lot of warnings during "make
buildworld"
New Synopsis: [tcp] [patch] TCP wrappers caused quite a lot of warnings during
"make buildworld"
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Tue
On 2/11/13 3:10 AM, Andre Oppermann wrote:
On 09.02.2013 15:41, Alfred Perlstein wrote:
However, the end result must be far different than what has occurred
so far.
If the code was deemed unacceptable for general inclusion, then we
must find a way to provide a
light framework to accomplish t
Hi all,
I want to know if there is a way to find out if an interface address is
assigned by dhcp or statically? For example, any distinctive flag or
something like that on ifconfig output! or any other way except processing
dhclient leases files?
___
fre
On Sat, Jan 26, 2013 at 6:22 PM, Dave Duchscher wrote:
> On Jan 26, 2013, at 7:05 AM, h bagade wrote:
>
> > I've found a patch which is going to do what I really want:
> > http://lists.freebsd.org/pipermail/freebsd-net/2010-December/027196.html
> >
> > but when I apply it on my freebsd 8.2 with e
On Feb 11, 2013 10:44 PM, "h bagade" wrote:
>
> Hi all,
>
> I want to know if there is a way to find out if an interface address is
> assigned by dhcp or statically? For example, any distinctive flag or
> something like that on ifconfig output! or any other way except processing
> dhclient leases
Just a OOB thought...
But couldn't you adjust a dhclient script to be run up success and assign a
description to the interface that the address was dynamically configured by
DHCP.
Wouldn't scale well in a large deployment but then again it might for you.
BOL
--
Jason Hellenthal
JJH48-ARIN
18 matches
Mail list logo
