ping(8) faster than light (do_get_fast_time) (fwd)

Hi,

I have encountered the following strange problem that is related to the RedHat bug

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id7485

A "ping localhost" on RedHat 7.1 will generate the warning

Warning: time of day goes back, taking countermeasures.

Tracing ping(8) with tcpdump shows that echo request and echo reply packets have exactly the same time stamp.

The "RELNOTES" file of the RedHat iputils package says

* By Pekka Savola <[email protected]>
- SIOCGSTAMP/SO_TIMESTAMP are sensitive to bug in kernel. When get_fast_time != gettimeofday (f.e. timestampless x86), returned stamp can be out of sync with gettimeofday. Workaround is not to use SIOCGSTAMP/SO_TIMESTAMP on such systems.

It appears that this is actually the reason for the above problem.

The deeper reason is that on IA64, *do_get_fast_time() equals do_normal_gettime(), which simply returns xtime. On other architectures do_get_fast_time() is set to do_gettimeofday() in time_init(), which avoids the problem.

1) Is do_gettimeofday () too slow on IA64 to use it for do_get_fast_time() ?

2) If yes, would it be possible to susbtitute a do_get_fast_time() that is faster and less accurate than do_gettimeofday(), but still better than do_normal_gettime() ?

3) If no, the ping(8) program on IA64 should IMO be changed to not use SO_TIMESTAMP (equivalent to "ping -U" with the RH7.1 ping).

Martin

Martin Wilck     <[email protected]>
FSC EP PS DS1, Paderborn      Tel. +49 5251 8 15113

Martin> The deeper reason is that on IA64, *do_get_fast_time() Martin> equals do_normal_gettime(), which simply returns xtime.

This distinction doesn't make sense on ia64 because there is no (slow) gettimeofday() to begin with.

Martin> 1) Is do_gettimeofday () too slow on IA64 to use it for Martin> do_get_fast_time() ?

I have no idea what you mean here. On ia64 do_gettimeofday() returns xtime plus an itc based time offset. The kernel is careful to return only monotonically increasing time values, even in cases where the ITCs in different CPUs are not perfectly synchronized.

Martin> 3) If no, the ping(8) program on IA64 should IMO be changed Martin> to not use SO_TIMESTAMP (equivalent to "ping -U" with the Martin> RH7.1 ping).

We should first find out what the real problem is. What timestamps are present at the time ping is complaining? If the earlier timestamp is bigger than the later one, there is a bug somewhere. If they're equal (unlikely, given that we do ITC-based interpolation), ping shouldn't complain.

	--david

Then, unless I'm completely mistaken, time_init() should change the pointer do_get_fast_time to use do_gettimeofday() rather than do_normal gettime(). Unless this is done, get_fast_time() will simply return xtime. Or am I overlooking something?

Yes, but get_fast_time() doesn't (see above), and that's the function that is called for getting timestamps for socket buffers.

Martin

Martin Wilck     <[email protected]>
FSC EP PS DS1, Paderborn      Tel. +49 5251 8 15113

Martin> Yes, but get_fast_time() doesn't (see above), and that's the Martin> function that is called for getting timestamps for socket Martin> buffers.

Ah, yes, my oversight. We should initialize do_get_fast_time. Thanks for tracking this down.

	--david