Bug 16157

Summary:	"fire" screensave kills network performance
Product:	Base System	Reporter:	tedm <tedm>
Component:	misc	Assignee:	Brian Feldman <green>
Status:	Closed FIXED
Severity:	Affects Only Me
Priority:	Normal
Version:	3.4-RELEASE
Hardware:	Any
OS:	Any

Description tedm 2000-01-17 11:00:01 UTC

	

System was configured as a router at the end of a T1.  Network throughput
was measured at around 175K characters per second routed through the
server which was considered highly satisfactory.  During the course of
testing network throughput tanked at 3K characters per second.  Subsequent
investigation revealed that the "fire" screensaver had kicked on at
precisely the moment that network performance had tanked.  The "fire"
screensaver was disabled and network performance returned to it's
normal high level.

Fix: 

Disable screensaver.


The reason that I'm filing this is that it caught me by surprise, and I'm
sure that it probably is something that would catch a lot of people
unaware.  Sure, I know that maybe if I was running some damn Celeron
600Mhz then maybe I might not notice when the screensaver switches on.
However, this is not a fix - why does the stupid screensaver impact
the system performance at all?  The screensaver should be written so that
it only gets CPU cycles that are leftover after everything else is
done in the system.

I didn't test out any other screen savers because I didn't have the time
to mess with them, but I'm sure that the same problem would happen
with others.  Something needs to be done with the scrensaver module,
maybe it needs to renice the saver processes or something, but it can't
be allowed to pass unnoticed.  Even if there was a warning in sysinstall
against enabling the screensaver on a network server or router that 
would be something.

Believe it or not the same kind of problem was written up recently
about Windows NT's 3D GL screensavers - they make NT Server tank
too.  It looks like we stepped in the same cowpie that those
guys did.  But, we can fix it - NT can't.
How-To-Repeat: 
	

Select "fire" and wait for it to turn on and then measure throughput
while it's running.

Comment 1 jkh freebsd_committer

2000-01-17 18:21:37 UTC

Responsible Changed
From-To: gnats-admin->green

This is Brian's screensaver and now his hot potato. :)

Comment 2 drussell 2000-01-27 07:40:01 UTC

>testing network throughput tanked at 3K characters per second. Subsequent
>investigation revealed that the "fire" screensaver had kicked on at
>precisely the moment that network performance had tanked.  The "fire"
>screensaver was disabled and network performance returned to it's
>normal high level.

"fire" isn't the only one that will do things like this.
Even on a relatively fast router system system, I started noticing:

sio1: 2 more silo overflows (total 693)
sio1: 2 more silo overflows (total 695)

Similar problem, same cause.  Anything requiring many interrupts or
general system load doesn't get proper handling with some of the
screensavers active at the default nice level.  This system was relatively
old (2.2.[678]) when the problem cropped up, so I don't know which
screensavers still have problems, and I can't even seem to find an
app-defaults/XScreenSaver file that has the nice 15 or so commands I added
to the offending screensavers at the time when I did a quick checkover.

I'm not exactly sure why "nicing" the screensavers worked, as they were
being called by xscreensaver anyway, and it's supposed to nice 10 them by
default.  I suppose it probably only worked to a certain extent, but
happened to be enough to eliminate the symptoms on that particular
machine.  (K6-2-233, Cirrus Logic 5446 PCI video, IIRC)  I also remember
it got noticably worse when the X server itself was -niced, even say -5.
This leads me to believe that it is probably worse on video hardware that
is particularly bad about holding up the system while drawing, etc, or is
just plain slow.  (The 5446, for example, can often cause interrupt
related pauses on audio playback through a sound card, etc, at least
slightly moreso than some others, although generally it works very well.)

I think I'll do a build of xscreensaver on 4.0-CURRENT, and see if I can
pinpoint any more current problems.

Later......						<Doug>

Comment 3 Jens Schweikhardt freebsd_committer

2002-09-29 14:42:55 UTC

State Changed
From-To: open->feedback

Is this still an issue with recent STABLE releases?

Comment 4 Mark Linimon freebsd_committer

2004-07-22 07:38:28 UTC

State Changed
From-To: feedback->closed

Feedback timeout (nearly 2 years).