From owner-freebsd-multimedia Mon May 26 09:29:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA26963 for multimedia-outgoing; Mon, 26 May 1997 09:29:26 -0700 (PDT) Received: from whqvax.picker.com (whqvax.picker.com [144.54.1.1]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id JAA26958 for ; Mon, 26 May 1997 09:29:24 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Mon, 26 May 1997 12:28:15 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA17069; Mon, 26 May 97 12:28:13 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id MAA08695; Mon, 26 May 1997 12:27:14 -0400 Message-Id: <19970526122714.40844@ct.picker.com> Date: Mon, 26 May 1997 12:27:14 -0400 From: Randall Hopper To: Bernie Doehner Cc: multimedia@FreeBSD.ORG Subject: High CPU utiliz w/ fxtv (was Re: Amancio's latest mods...) References: <199705250731.AAA01091@rah.star-gate.com> <19970526120257.54104@ct.picker.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: <19970526120257.54104@ct.picker.com>; from Randall Hopper on Mon, May 26, 1997 at 12:02:57PM -0400 Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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