[sldev] Linux 64 bit framerate stutter (0.5 - 2.0 second frame periodically [every 5 to 60 seconds])

[Bane Darrow]

On Thu, Mar 13, 2008 at 4:38 AM, Robin Cornelius <robin.cornelius at gmail.com>
wrote:

> Bane Darrow wrote:
> > So I've been trying to use a custom build of the client on x86_64
> > gentoo. They didn't have a package, so I decided to just build it
> > myself. I should point out my goal isn't to develop on the client,
> > merely run it. Maybe add some minor things over time.
>
> BTW what version is this you are building 1.19.0 or 1.19.1.0?


I'm building straight out of the svn release branch.

>
>
> > >
> > Anyway, the latest issue is every 15 to 60 seconds, I get a couple
> > frames that take anywhere from half a second to 2 seconds. This is not a
> > pleasant experience. Especially for watching movies.
> >
>
> Hmm, a few possible reasons, but as its curl related are you by any
> chance seeing any crazy dump times such as
>
> INFO: dumpReceiveCounts: Dump: 2 messages processed in 10.0925 seconds
> (or in your case 2 seconds?)
>
> in your logs at all?


Yes, besides the stutter itself, that was where I started dropping timers
in. It seems to be a result of the stutter (mReceiveTime is too old) rather
than where the actual stutter is.


>
>
> > <irrelevant>
> > LLFastTimer doesn't work on x86_64 linux, since it uses some assembly,
> > but changing that to use gettimeofday() like the LL_DARWIN version does
> > work fine, so tracking this down I first had to fix that.
>
> This is the patch we all seem to be using
> http://jira.secondlife.com/browse/VWR-1165
> which just does what you say but looks like it got given up on and
> forgotten.


Guess no one cares 'bout 64 bit :)


>
>
> > </irrelevant>
>
> >
> > I finally traced it down to llurlrequest.cpp:process_impl where it calls
> > mDetail->mCurlRequest->perform(). That eventually calls through to
> > LLCurl::Multi::perform(), which calls curl_multi_perform(). From this
> > point, it's hard to debug, as I'm not sure the best places to add new
> > LLFastTimer() calls. It could either be getting stuck inside curl, or
> > inside one of the callbacks in linden code. Finding it is hard because
> > the stutters aren't long enough that I can break in and see where the PC
> > is. I'm working blindly with narrowing it down with LLFastTimers. I
> > looked around in JIRA and found
> > http://jira.secondlife.com/browse/VWR-92. That looks suspiciously like
> > what I'm seeing, however Torley said it's fixed and the bug is resolved.
>
> VWR-92 could have been many things. There were all sorts of possible
> stutters and hiccups when that was reported.
>
> >
> > So, I guess what I'm asking.. is anyone familiar with this, or seen it?
> > Is VWR-92 actually fixed? And more generally... is anyone familiar
> > enough with the SL IOpump and curl to give some pointers on where I
> > might want to add some more LLFastTimers? How was VWR-92 fixed, so I can
> > maybe start looking there?
> >
>
> i'm on my own anti-stutter mission which may or may not be the same as
> yours, as my stutters are 10 seconds i may stand a chance of a gdb break.


Please let me know what you find out, and I'll do the same.


>
>
> Robin
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080313/64b47ca8/attachment-0001.htm