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

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

Date:	Wed, 19 Nov 2008 06:41:08 +1300
From:	"Ian McDonald" <ian.mcdonald@...di.co.nz>
To:	"Gerrit Renker" <gerrit@....abdn.ac.uk>,
	"Ian McDonald" <ian.mcdonald@...di.co.nz>,
	"Leandro Sales" <leandroal@...il.com>,
	"Arnaldo Carvalho de Melo" <acme@...hat.com>,
	"DCCP Mailing List" <dccp@...r.kernel.org>, netdev@...r.kernel.org,
	"DCCP mailing list" <dccp@...f.org>
Subject: Re: [RFC] dccp ccid-3: High-res or low-res timers?

On Tue, Nov 18, 2008 at 7:14 PM, Gerrit Renker <gerrit@....abdn.ac.uk> wrote:
> | The RFC uses an example of 1 msec scheduling and 0.1 msec RTT. However
> | what would be worse is devices on a LAN with 10 msec timer - e.g. two
> | embedded devices at home - I haven't done the maths but I think the
> | rate achievable would be quite low.
> If we use lower-resolution timers I think there should be a
> recommendation (in the Kconfig menu for instance) not to use
> low HZ values.
>
> Previously this was done as a build warning, but it is annoying if
> people do an allmodconfig and are not otherwise interested in DCCP.
>
Agree

> Do you think we could live with clamping the RTT to some sensible
> minimum, since on a local LAN the use of congestion control is
> questionable? I was thinking in the order of 0.5 ... 1msec.
>
I think that is a good idea - if 1 msec, and HZ = 1000 then we
wouldn't lose any transmission capability.

> | Thinking laterally there is another possible solution - something I
> | used way back in the 80s for another project - build your own
> | scheduler! We could set a high resolution timer to tick every 0.1 msec
> | and then use the coarse grained algorithm at that point....
> |
> So we have three possible options - timer-based (low/high), and your
> suggestion above. We can keep these variants open by spawning an
> experimental subtree which provides an alternative implementation, so
> that people could explore alternative algorithms, compare and send patches.
>
> For production use the low-resolution variant is the simplest and less
> expensive option, and it is good that there is consensus about it.
>
Yes - and with your RTT clamping then no need to do my idea around scheduler.

> In a discussion about two years ago there was another
> idea, doing away with the nofeedback timer, by checking the nofeedback
> time at the instant a packet is sent.
>
I think this is useful as reduces the amount of timers going off,
which reduces system load.

-- 
Web: http://wand.net.nz/~iam4/, http://www.jandi.co.nz
Blog: http://iansblog.jandi.co.nz
--
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