lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1337964880.3347.52.camel@edumazet-glaptop>
Date:	Fri, 25 May 2012 18:54:40 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Srećko Jurić-Kavelj 
	<srecko.juric-kavelj@....hr>
Cc:	Dave Taht <dave.taht@...il.com>,
	Chris Friesen <chris.friesen@...band.com>,
	netdev@...r.kernel.org
Subject: Re: Using jiffies for tcp_time_stamp?

On Fri, 2012-05-25 at 18:23 +0200, Srećko Jurić-Kavelj wrote:
> On Fri, May 25, 2012 at 6:17 PM, Dave Taht <dave.taht@...il.com> wrote:
> > On Fri, May 25, 2012 at 4:58 PM, Chris Friesen
> > <chris.friesen@...band.com> wrote:
> >> I don't know if it would make any difference to the tcp algorithms, but
> >> certainly on some architectures you can get a fast and accurate hardware
> >> timestamp.
> >
> > I would be interested in someone doing that experiment in light of the
> > codel work.
> 
> I've looked this up in other implementations, e.g. FreeBSD uses 1ms
> granularity no matter what HZ says, NetBSD has 500ms ticks, ...
> 
> I guess that granularity also depends on the retransmit timers used. I
> didn't make out what's the precision of the timers that Linux uses in
> TCP, but I guess it uses high resolution timers? At least on x86?
> 
> I've done a simple experiment by repeatedly calling clock_gettime
> (from userspace, but I guess it ends up as a vsyscall). I get >17
> million calls per second on a Q6600.

linux TCP uses high precision timestamps (ktime_get_real()) where
needed.

# find net|xargs grep -n TCP_CONG_RTT_STAMP
net/ipv4/tcp_veno.c:205:	.flags		= TCP_CONG_RTT_STAMP,
net/ipv4/tcp_vegas.c:308:	.flags		= TCP_CONG_RTT_STAMP,
net/ipv4/tcp_cubic.c:478:		cubictcp.flags |= TCP_CONG_RTT_STAMP;
net/ipv4/tcp_output.c:815:	if (icsk->icsk_ca_ops->flags & TCP_CONG_RTT_STAMP)
net/ipv4/tcp_lp.c:317:	.flags = TCP_CONG_RTT_STAMP,
net/ipv4/tcp_yeah.c:229:	.flags		= TCP_CONG_RTT_STAMP,
net/ipv4/tcp_illinois.c:326:	.flags		= TCP_CONG_RTT_STAMP,
net/ipv4/tcp_input.c:3496:				if (ca_ops->flags & TCP_CONG_RTT_STAMP &&

Other than that HZ=1000 seems fine.

HZ=100 seems a poor choice, we have NO_HZ since a long time.



--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ