From: Mark Beland <mark@mc...> - 2003-11-10 19:10:13
Running 2.4.22-um5 with host skas patch. With a tun/tap driver setup in
the um doing ping -f or any measurable amount of network traffic going
into the um causes 'time sleep 1' to take much longer (from 2 to 10
seconds typical) executing the same command on the host shows 1 second
(almost exact) at all times. Tried multiple other uml kernels as well
as host kernels (the results do not seem to vary). This is a p4 2.8
hyperthread. We dissabled the hyperthreading support thinking this
might be the cause but still no change.
Any other suggestions or ideas?
-= I understand other people are also experiencing this problem to
varying degrees. =-
Is this problem architectural in the uml model or is it a bug?
Btw - Thumbs up to the developers, uml is wonderfull.
Phone: (780) 645-4417
Fax: (780) 645-5745
From: Jeff Dike <jdike@ad...> - 2003-11-11 20:04:59
> Running 2.4.22-um5 with host skas patch. With a tun/tap driver setup
> in the um doing ping -f or any measurable amount of network traffic
> going into the um causes 'time sleep 1' to take much longer (from 2 to
> 10 seconds typical)
I have a fix for this in the next patch. It's a long-standing patch from
Sapan Bhatia which sat in my queue since people hadn't been complaining
about it. More recently, people have started moaning, so the fix is in.
Basically, it ties the internal UML clock to the host tsc. It's under the
control of CONFIG_UML_REAL_TIME_CLOCK, which should normally be left on.
However, anyone debugging with UML who doesn't care about accurate timers
may want to turn it off. The reason is that any amount of time spent with
UML stopped while you stare at gdb will cause a lot of ticks to get backed
up, and it will deliver them all as soon as you continue UML. I don't know
if this will take any noticable time, but it's something to consider.