Subject: Re: Doubt regarding the MANAGING THE RTO TIMER

From: der Mouse <[email-masked]>
Date: Wed, 12 Dec 2001 02:13:15 -0500 (EST)

> Good point, the multi-CPU case hadn't occurred to me.

> But don't most multi-CPU motherboards use a common clock for all
> CPUs, at least when they're all running at the same clock rate?  And
> aren't the CPU reset pins driven from the same source? If so, the CPU
> clock counters should be pretty close.

Perhaps.  So?  Do you really want to build a TCP stack that breaks (or
misbehaves badly) because of totally weirded-out RTT estimates when run
on baords that don't match your assumptions?

Or is this solely for heavily-instrumented research use?  In that case,
I withdraw the above objection.

Another possible objection: I've heard of CPUs that throttle back their
clock rate if they start to overheat.  If one CPU heats up and the
other doesn't, will they both throttle back in sync, or will only the
hot one?  If the latter, ISTM this has potential to skew their clock
counters.

Unless, again, you're doing this for research use, in which case you
can just avoid such CPUs, or avoid such CPUs in multi-CPU machines
(though you may want to avoid them entirely, since the time interval
you'll get will depend on how much clock throttling has happened during
the round trip you're timing).

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Alan Cox <[email-masked]>
Date: Wed, 12 Dec 2001 13:59:48 +0000 (GMT)

> hot one?  If the latter, ISTM this has potential to skew their clock

The x86 world they are generally clocked together, but the bus multipliers
are per cpu. The heat control is in current intel, via and amd stuff and
totally changes the cpu clock speed

> the round trip you're timing).

Right. Increasingly I'm finding the tsc is only interesting for micro
benchmarking pieces of code