[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1334520061.28012.36.camel@edumazet-glaptop>
Date: Sun, 15 Apr 2012 22:01:01 +0200
From: Eric Dumazet <eric.dumazet@...il.com>
To: Jerry Chu <hkchu@...gle.com>
Cc: David Miller <davem@...emloft.net>,
netdev <netdev@...r.kernel.org>,
Tom Herbert <therbert@...gle.com>
Subject: Re: [PATCH net-next] tcp: RFC6298 supersedes RFC2988bis
On Sun, 2012-04-15 at 11:33 -0700, Jerry Chu wrote:
> [send again - it looks like my previous comment was lost...]
>
> On Thu, Apr 12, 2012 at 10:48 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> > Updates some comments to track RFC6298
> >
> > Signed-off-by: Eric Dumazet <edumazet@...gle.com>
> > Cc: H.K. Jerry Chu <hkchu@...gle.com>
> > Cc: Tom Herbert <therbert@...gle.com>
> > ---
> > BTW, one side effect of the TCP_TIMEOUT_INIT change (3 -> 1) is
> > () latency is 200% worse:
>
> Or even worse - 300% (3/1)?
well, 3 instead of 1 is a 200% increase ;)
>
> >
> > It fires every 200ms and scans 40% of hash table each time, listener
> > socket held.
>
> If this becomes a real issue we could decrease TCP_SYNQ_INTERVAL,
> essentially making the keepalive timer fire more often, but each time with
> less work to do?
Hmm... 200ms is already aggressive for power saving
>
> Also why is
> budget = 2 * (lopt->nr_table_entries / (timeout / interval));
> rather than
> budget = (lopt->nr_table_entries / (timeout / interval)) + 1;
> ?
Thats because if we do that, retransmits could be delayed by 100%,
instead of 50% with this solution.
(right now it takes 2.5 rounds to scan whole table, so a one sec 'timer'
can be fired after 1.6 second)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists