Date: Mon, 26 May 1997 12:27:14 -0400 From: Randall Hopper <rhh@ct.picker.com> To: Bernie Doehner <bad@uhf.wireless.net> Cc: multimedia@FreeBSD.ORG Subject: High CPU utiliz w/ fxtv (was Re: Amancio's latest mods...) Message-ID: <19970526122714.40844@ct.picker.com> In-Reply-To: <19970526120257.54104@ct.picker.com>; from Randall Hopper on Mon, May 26, 1997 at 12:02:57PM -0400 References: <199705250731.AAA01091@rah.star-gate.com> <Pine.BSF.3.95.970525092918.326A-100000@uhf.wdc.net> <19970526120257.54104@ct.picker.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Bernie Doehner:
|I do however notice the load average shoot up to approx. 1.1 when fxtv is
|running. Should fxtv be so CPU intensive? Maybe there is some truth to
|the Pentium 90 minimum warning on the box.
Louis (louie@TransSys.COM) & I noticed this a month or so ago, and I've got
it on my ToDo list to look deeper into this. When doing direct video, it
should need very little CPU.
I dug into it briefly before: the fxtv main X event loop isn't spinning (so
the fxtv code proper isn't burning cycles), but down in the bowels of
NextEvent, it appears the Xlib code is spinning hard checking for data on
the X socket. Attaching fxtv in the debugger to stop it of course gets rid
of the CPU overhead, the system load goes down, and the video keeps going
as it should (what you'd expect with fxtv _actually running_).
Just took a closer look. xscope says no X protocol is being sent between
the client and X server when direct video is running, or when the video is
paused, so that's not it.
ktrace/lsof/netstat say that the kulprit is file descriptor #3, which is
the UNIX X server socket:
/tmp/.X11-unix/X0
Down in XtAppNextEvent, Xlib internally is doing this over-and-over:
256 of these:
2520 fxtv CALL ioctl(0x3,FIONREAD,0xefbfcaf4)
2520 fxtv RET ioctl 0
and then 1 of these:
2520 fxtv CALL select(0x4,0xefbfcad4,0,0,0x815b79c)
2520 fxtv RET select 0
(Any data yet? No. Any data yet? No...) Now why the timeout for the
select is so short, I have no idea. On a hunch, I tried bumping the
timeouts used in fxtv to 1 second -- no difference.
#0 0x82168e1 in ioctl ()
#1 0x813a82b in _X11TransSocketBytesReadable ()
#2 0x813b57f in _X11TransBytesReadable ()
#3 0x811f876 in _XEventsQueued ()
#4 0x810edd8 in XEventsQueued ()
#5 0x80d2e6f in XtAppNextEvent ()
#6 0x7920 in main (argc=1, argv=0xefbfd3e4) at tv.c:391
dtv I notice doesn't have this CPU overhead, so the different might be
related to the delta of X server features used by the two programs.
I'll flip a question to the XFree folks about this, now that I've
accumulated some data. Of course, if anybody has any clues, please let me
know.
Randall
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970526122714.40844>