Re: [uml-user] Re: [uml-devel] Fighting latency

[Blaisorblade <bla...@ya...>]

On Monday 08 November 2004 14:48, nils toedtmann wrote:
> On Fri, Nov 05, 2004 at 12:44:59AM +0100, Blaisorblade wrote:
> > On Thursday 04 November 2004 16:50, nils toedtmann wrote:
> > > Moin,
> > >
> > > in some UMLs i run services which do not like latency, eg. VoIP- and
> > > gameserver. I previously observed my UMLs going into meditation for a
> > > split second every few seconds, but that bucking almost disappeard by
> > > taking the usual tuning steps (SKAS, sysemu, $TMP on tmpfs).
> > > Nevertheless, my UMLs are still not as responsive as i would like them
> > > to. It's not a matter of CPU or network performance. Host and guest are
> > > >=95% idle all the time, bandwidth use is far from my UML-bench- marks.
> > >
> > > I tried to renice the UML processes, but seems not to help (it's hard
> > > to measure, just the "feeling" while listening to audio or
> > > onlinegaming).
> > >
> > > Any suggestions?
> > >
> > > I enabled "PREEMPT" in host kernel. Maybe that's a bad idea?
>
> Any hint for preemtion?
Disable that in UML, because I think UML has some *big* bugs with preemption 
on.

Do whatever you like on your host kernel - however note that some kernel race 
conditions are only triggered by either SMP or PREEMPT, or equally by any of 
them.

> > This problem is an old one. Search the archives for "odd ping problems",
> > which is about long ping delay.

> Hmm, it's more like the "network lag" problem. But pings are ok (as long as
> they are not too big)

>   root@gandalf:~# ping -q -i 0.0005 -s1460 smilla
>   PING smilla 1460(1488) bytes of data.
>
>   --- smilla ping statistics ---
>   1742 packets transmitted, 1742 received, 0% packet loss, time 22482ms
>   rtt min/avg/max/mdev = 1.960/2.831/4.193/0.449 ms, pipe 2, ipg/ewma
> 12.913/2.760 ms
>
> so i guess my latency-unpleasantness (would not call it problem) it's not a
> netwok problem. I have the old "odd ping problem" (ping payloads >20000),
> too, but i do not mind yet ;-)

> > A fix was proposed a while ago, which consisted in mlock()ing the memory.
> > But Jeff Dike refused it because he said "I want to write a much more
> > complex and more optimal solution. Mlock() is an hack".
> >
> > Even so, I'll try to update the patch, fix it on the security side (that
> > one required setuid()'ing UML, which is purposeless) and push it for
> > inclusion, if possible.
>
> Great, i'll try that.
Search for "ramfs" on this list, in these days, and you'll find a simpler 
solution for the same.

Bye
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729