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]
Date:	Mon, 26 Feb 2007 13:20:57 +0100
From:	Andi Kleen <ak@...e.de>
To:	John <linux.kernel@...e.fr>
Cc:	linux-kernel@...r.kernel.org, johnstul@...ibm.com, mingo@...e.hu,
	zippel@...ux-m68k.org, tglx@...esys.com, akpm@...ux-foundation.org,
	jbohac@...e.cz
Subject: Re: CLOCK_MONOTONIC datagram timestamps by the kernel


Mr Anonymous,

> 
> My app expects a stream of UDP datagrams containing compressed video.
> These datagrams have been time stamped by the source using a high 
> resolution clock.

Why do you need another time stamp them? 
> 
> The video stream is played out in real-time. I buffer several packets, 
> then repeatedly arm a one-shot timer (with TIMER_ABSTIME set) to wait 
> until it's time to send the oldest packet.
> 
> AFAIU, if I use the CLOCK_REALTIME clock in my app, and if the sysadmin 
> changes the date, hell will break loose in my app.

Only if your app cannot handle time going backwards.

> I suppose that if I change sock_get_timestamp() in core/sock.c to call 
> __get_realtime_clock_ts() instead of do_gettimeofday() I'll break 50 
> billion applications (ping? traceroute?) that expect a struct timeval?

Not that many, but some probably. 

Letting the kernel do the time stamping is usually quite useless anyways. 
You can as well do it in your application when you receive it. After all
you're interested in when you can read the packet in your app, 
not when the driver processes it.

The kernel time stamping is mainly for sniffing applications that want
to know exactly what's going on on the wire. But even then it's fairly
arbitary because it can be a long time between the packet arriving 
on the PHY and being processed by the driver.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ