netdev - Re: Using jiffies for tcp_time

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 25 May 2012 20:35:30 +0200
From:	Srećko Jurić-Kavelj 
	<srecko.juric-kavelj@....hr>
To:	Eric Dumazet <eric.dumazet@...il.com>
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, May 25, 2012 at 6:54 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> 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 &&

Didn't know about TCP_CONG_RTT_STAMP.

Thing is, the device I'm connecting to doesn't even support TCP time
stamp option. The returning SYN ACK packet only has maximum segment
size 1460 bytes in options.

>From the net/ipv4/tcp_input.c code, RTT is estimated using

#define tcp_time_stamp          ((__u32)(jiffies))

from include/net/tcp.h.

Could ktime_get_real() be used for tcp_time_stamp instead of jiffies?


> Other than that HZ=1000 seems fine.
>
> HZ=100 seems a poor choice, we have NO_HZ since a long time.

I have:
$ grep HZ /boot/config-2.6.32-41-generic
CONFIG_NO_HZ=y
CONFIG_HZ_100=y
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=100
CONFIG_MACHZ_WDT=m

>From what I've seen in the code, NO_HZ doesn't make jiffies go away,
it simply doesn't use regular CONFIG_HZ interrupt to update, but
updates them when has an opportunity?

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