> On June 22, 2016 at 7:53 AM Yuchung Cheng wrote:
>
> Thanks for the patience. I've collected data from some Google Web
> servers. They serve both a mix of US and SouthAm users using
> HTTP1 and HTTP2. The traffic is Web browsing (e.g., search, maps,
> gmails, etc but not Youtube videos). The me
> On June 15, 2016 at 10:38 PM Eric Dumazet wrote:
>
> I guess the problem is that some folks use smaller rto than
> RTAX_RTO_MIN , look at tcp_rto_min()
Due to the nature of the Linux calculation, this is probably more of a reason
to use the RFC 6298 calculation. When a smaller MinRTO as 200ms
> On June 15, 2016 at 8:02 PM Yuchung Cheng wrote:
>
> Let's say the SRTT is 100ms and RTT variations is 10ms. The variation
> is low because we've been sending large chunks, and RTT is fairly
> stable, and we sample on every ACK. The RTOs produced are
>
> RFC6298: RTO=1s
> Linux: RTO=300ms
> Th
* Yuchung Cheng | 2016-06-14 14:33:18 [-0700]:
>> + tp->rttvar_us = tp->mdev_us;
>AFAICT we can update rttvar_us directly and don't need mdev_us anymore?
Yes, v3 will remove mdev_us.
>This is more aggressive than RFC6298 that RTO <- SRTT + max (G,
>K*RTTVAR) where G = MIN_RTO = 20
* Yuchung Cheng | 2016-06-13 15:38:24 [-0700]:
Hey Eric, Yuchung,
regarding the missed mdev_max_us: internal communication problem. Daniel well
respin a v2 removing the no longer required mdev_max_us.
>Thanks for the patch. I also have long wanted to evaluate Linux's RTO vs RFC's.
>
>Since this
> On April 15, 2016 at 10:47 AM Yuki Machida
> wrote:
>
> >> commit 9d289715eb5c252ae15bd547cb252ca547a3c4f2
> >> Author: Hagen Paul Pfeifer
> >> Date: Thu Jan 15 22:34:25 2015 +0100
> >>
> >> ipv6: stop sending PTB packets for MTU &l
> On July 16, 2015 at 9:23 PM Joe Perches wrote:
>
> It might be useful to have these performance impacting
> changes guarded by something like CONFIG_CC_OPTIMIZE_FOR_SIZE
> with another static __always_inline __ and a function &
> EXPORT_SYMBOL or just a static inline so that where code size
> i
> On July 16, 2015 at 2:48 PM "Motejlek, Petr"
> wrote:
>
> Could you please give me some example of such a tc command that
> would tell me the statistics? I am not sure what you mean.
tc -s qdisc show dev eth0
> Is there a way I can manipulate the internal rbtree queue size, please?
Sure, the
> On July 16, 2015 at 1:28 PM "Motejlek, Petr"
> wrote:
> I was wondering what queues/buffers does netem use and how does one
> control or monitor them?
netem uses his own rbtree based queue. You can use tc(1) to get
statistics.
> I could not find this information anywhere and I am not that goo
On 15 June 2015 at 22:54, Phil Sutter wrote:
> As I see it, a user has no way of detecting the listening socket in this
> address family: it does not show in /proc/net/{tcp,udp} nor do
> 'netstat', 'ss' or 'lsof' print any additional information about those
> sockets over pure IPv6 ones.
Probabl
>This patch isn't ok ( maybe this patch benefit from gcc padding behaviours):
Ignore this - I thought this function returns a pointer ...
(take a look at my email signature :-)
HGN
--
COFFEE.EXE Missing - Insert Cup and Press Any Key.
-
To unsubscribe from this list: send the line "unsubs
* Rainer Baumann | 2006-12-15 11:39:28 [+0100]:
>Patch for linux kernel 2.6.18.13:
>http://tcn.hypert.net/tcn_kernel_configfs.patch
This patch isn't ok ( maybe this patch benefit from gcc padding behaviours):
static struct pktdelay get_next_delay(struct netem_sched_data *q)
{
struct pktdelay r
* Alexey Dobriyan | 2006-11-03 03:09:05 [+0300]:
>On Wed, Nov 01, 2006 at 03:06:24PM +0100, Florian Westphal wrote:
>> convert sprintf(a,b) to strcpy(a,b). Make tipc_bclink_name[] const.
>
>Ahhh, I missed the start of threads.
>
>Patch is useless because it changes one unbounded string function in
* Stephen Hemminger | 2006-10-27 07:41:02 [-0700]:
>Please no, it makes the socket option useless.
Technical no, in the sense of usability for everybody yes. You are right
Stephen, as a programmer I understand you complete!
But on the other side: We know for sure that this IS a problem if we all
change
congestion control algorithm.
Signed-off-by: Hagen Paul Pfeifer <[EMAIL PROTECTED]>
---
net/ipv4/tcp_cong.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/tcp_cong.c b/net/ipv4/tcp_cong.c
index af0aca1..c1ae2e9 100644
--- a/net/ipv4/tcp_cong.c
++
strator has the knowledge to
select a proper standard, system-wide algorithm (the remaining 0.1% are
for testing purpose). If we let the user select an alternative algorithm we
introduce one potential weak spot - so we ban this eventuality.
HGN
Signed-off-by: Hagen Paul Pfeifer <[EMAIL PROTECT
* John Heffner | 2006-10-26 13:29:26 [-0400]:
>My reservation in doing this would be that as an administrator, I may
>want to choose exactly what congestion control is available any any
>given time. The different congestion control algorithms are not
>necessarily fair to each other.
ACK, comp
Hi Stephen,
is your rt-patch to netem public available?
Best regards
HGN
--
Signed and/or encrypted mails preferd. Key-Id = 0x98350C22
Fingerprint = 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22
Key available under: www.jauu.net/download/gnupg_key
-
To unsubscribe from this list: send
* Ben Greear | 2006-10-23 17:44:24 [-0700]:
>Since IOCTLs are out of favor these days, what would be
>a preferred way to get a block of binary data out of the
>kernel?
I suggest netlink socket for that purpose! Netlink scales also well if the
amount of data "surprisedly" rise.
>Thanks,
>Ben
HGN
* Rainer Baumann | 2006-09-22 08:15:13 [+0200]:
>Patch for linux kernel 2.6.16.19: http://tcn.hypert.net/tcnKernel_procfs.patch
Coding Style need at least some work ...
Whitespaces around operators and parentheses, useless parentheses, braces for
the else branch, mixes C99/C89 comments, indentat
* Andi Kleen | 2006-09-19 12:03:51 [+0200]:
>How about a single auto selection heuristic: e.g. check the handshake
>latencies
>and if they are too long switch from reno to the newer one deemed most
>stable?
Thats absolute no practicable solution to discover the 'right' algorithm.
The latenzy is
* Irfan Habib | 2006-08-02 23:04:41 [+0500]:
>Hi,
>
>For research purposes we are considering to develop a program to alter
>the bandwidth of a system via the software, so instance: a machine has
>100 MB/s and we change it to 1MB/s.
>
>Does something like this already exist? Or is there a way to d
* Stephen Hemminger | 2006-04-21 08:19:17 [-0700]:
>2.6.13 still had lots of problems, things didn't really get working
>right till 2.6.15 or later. Especially with TSO.
--verbose?
>I have a tool using kprobe's see
>http://developer.osdl.org/shemminger/prototypes/tcpprobe.tar.gz
>I try to keep
23 matches
Mail list logo
