netdev - Re: [RFC] dccp ccid-3: High-res or low-res timers?

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: <20081116.224834.166724077.davem@davemloft.net>
Date:	Sun, 16 Nov 2008 22:48:34 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	gerrit@....abdn.ac.uk
Cc:	leandroal@...il.com, acme@...hat.com, ian.mcdonald@...di.co.nz,
	dccp@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [RFC] dccp ccid-3: High-res or low-res timers?

From: Gerrit Renker <gerrit@....abdn.ac.uk>
Date: Sat, 15 Nov 2008 11:50:42 +0100

> 1. Handling unavoidable waiting times
> -------------------------------------
>  One can not expect that, if the scheduling clock says 'send in x
>  microseconds', a packet will indeed leave after x microseconds; due to
>  waiting times. An example is in net/dccp/timer.c, when the socket is
>  currently locked - we wait for a "small" amount of time:
> 
> 	bh_lock_sock(sk);
> 	if (sock_owned_by_user(sk))
> 		sk_reset_timer(sk, &dp->dccps_xmit_timer, jiffies + 1);
> 	else
> 		dccp_write_xmit(sk, 0);
> 	bh_unlock_sock(sk);

This should not happen often enough to be statistically meaningful.

If it does we have serious lock contention and we should fix that.

> 2. Dependency on high-resolution timers
> ---------------------------------------
>  Committing the CCID-3/CCID-4 implementations to using high-resolution
>  timers means that the modules can not be built/loaded when the kernel
>  does not offer sufficient resolution.
> 
>  This has recently made it hard for someone using CCID-3 to find out
>  why DCCP would not run, where the cause was that high-resolution timers
>  were not enabled in the kernel.

This could be argued as a bug in the hrtimer interface.  What it should
do is let you use the interfaces always, and the kernel gives you as
fine a resolution as the current configuration supports.

> 3. Noise in the output
> ----------------------
> When tracking the speed of a car every 10 seconds, there is a lot of variation
> in the values, due to stopping at traffic lights, accelerating etc. But when
> considering a larger timescale, one can say that the average speed from city
> A to city B was xx mph, since the whole journey took 2.5 hours.

This argument is sound.

> 4. Not sure using high-resolution is the answer
> -----------------------------------------------
> While a fine-grained timer resolution may be desirable, it is not
> necessarily a must. The implementation of rate-based pacing in TCP
> (http://www.isi.edu/~johnh/PAPERS/Visweswaraiah97b.html) for instance
> also used low(er) resolution timers and it worked.
> 
> The RFC for CCID-3 (http://www.rfc-archive.org/getrfc.php?rfc=5348) also
> does not high-resolution; it supports coarse-grained timestamps (section
> 6.3 and RFC 4342) and discusses implementation issues when using a 
> lower resolution (section 8.3).
> 
> The counter-argument could be that CCID-3 is a transport protocol with a
> built-in Token Bucket Filter so that similar considerations apply as for
> the Qdisc API (net/sched/sch_api.c).
> 
> Summing up, I have doubts that basing CCID-3 will bring advantages and
> would much rather go the other way and (consistently) use lower resolution.
> 
> Thoughts?

I wouldn't bother with high resolution timers, mostly because they are more
expensive and the benefit of them here is at best "unknown".
--
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