1. Why don't sys_time() and sys_stime() don't call do_gettimeofday()
and do_settimeofdat(), respectivley? Just copying xtime.tv_sec and
setting tv_usec to 0 can introduce an offset of nearly 1 second.
If I stime(second), I'd expect the time to be set to exactly that
second, just as settimeofday({second, 0}, tz) would do.
2. Shouldn't sys_time() and sys_stime() be removed from the kernel?
Just libc and statically linked binaries would have to be
recompiled, which is acceptable, IMHO.
3. Is there a reason that time_adjust_step is defined to be a global
var, when it is used only very temporarily in
update_wall_time_one_tick?
4. I sometimes observe the return value of gettimeofday() warping
backwards on two of my three Linux machines. I have also seen
negative ping respone times, which is probably a result of this.
It seems to be a know bug, since the uucp-1.06.1 autoconf script
checks for this bug.
What is happening here? Reading the sources I don't see the reason
for this behavior.
5. If not running xntp and not changing the tick value, tcpdump always
shows timestamps that are multiples of 10ms, i.e. 10000 ticks.
So probably the timestamp of a packet is just a copy of xtime and
do_gettimeoffset() from arch/i386/kernel/time.c is not called.
I guess it is the code in net/core/dev.c
void netif_rx(struct sk_buff *skb)
{
static int dropping = 0;
...
skb->sk = NULL;
skb->free = 1;
if(skb->stamp.tv_sec==0)
skb->stamp = xtime;
do_gettimeoffset() is probably not called for performance reason,
right? Would it be too much of a perfomance hit when running on a
pentium with the cycle counter, i.e. do_fast_gettimeoffset()?
6. Which CPUs have the cycle counter? My IBM 6x86 PR 166+ seems not
to have it. Executing the rdtsc instruction in a user process
causes a illegal instruction core dump while it works on a Intel
Pentium here at work.
Lots of questions. Anyone has some answers?
TIA
urs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu