From bsd-test.placo.com!root@agora.rdrop.com  Mon Jan 17 02:55:43 2000
Return-Path: <bsd-test.placo.com!root@agora.rdrop.com>
Received: from agora.rdrop.com (agora.rdrop.com [199.2.210.241])
	by hub.freebsd.org (Postfix) with ESMTP id C18FF15197
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 17 Jan 2000 02:55:41 -0800 (PST)
	(envelope-from bsd-test.placo.com!root@agora.rdrop.com)
Received: (from uucp@localhost)
	by agora.rdrop.com (8.8.5/8.8.7) with UUCP id CAA14187
	for FreeBSD-gnats-submit@freebsd.org; Mon, 17 Jan 2000 02:55:39 -0800 (PST)
	(envelope-from root@bsd-test.placo.com.UUCP)
Received: from bsd-test.placo.com (bsd-test [192.168.1.40])
	by toybox.placo.com (8.8.8/8.8.8) with ESMTP id CAA00446
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 17 Jan 2000 02:31:36 -0800 (PST)
	(envelope-from root@bsd-test.placo.com)
Received: (from root@localhost)
	by bsd-test.placo.com (8.9.3/8.9.3) id CAA00357;
	Mon, 17 Jan 2000 02:29:59 -0800 (PST)
	(envelope-from root)
Message-Id: <200001171029.CAA00357@bsd-test.placo.com>
Date: Mon, 17 Jan 2000 02:29:59 -0800 (PST)
From: tedm@toybox.placo.com
Sender: bsd-test.placo.com!root@agora.rdrop.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: "fire" screensaver kills network performance
X-Send-Pr-Version: 3.2

>Number:         16157
>Category:       misc
>Synopsis:       "fire" screensave kills network performance
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    green
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Jan 17 03:00:01 PST 2000
>Closed-Date:    Thu Jul 22 06:38:43 GMT 2004
>Last-Modified:  Thu Jul 22 06:38:43 GMT 2004
>Originator:     Ted Mittelstaedt - the Administrator
>Release:        FreeBSD 3.4-RELEASE i386
>Organization:
Cool Dudes Inc.
>Environment:
FreeBSD used as a router

	

FreeBSD running on a Compaq 386/33DX system with 4 EISA network adapter
cards crammed in the system

>Description:

	

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.

>How-To-Repeat:

	

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

>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.


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: gnats-admin->green 
Responsible-Changed-By: jkh 
Responsible-Changed-When: Mon Jan 17 10:21:37 PST 2000 
Responsible-Changed-Why:  
This is Brian's screensaver and now his hot potato. :) 

From: Doug Russell <drussell@saturn-tech.com>
To: freebsd-gnats-submit@FreeBSD.org
Cc: tedm@toybox.placo.com, jkh@FreeBSD.org
Subject: Re: pending/16157: "fire" screensave kills network performance
Date: Thu, 27 Jan 2000 00:40:01 -0700 (MST)

 >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>
 
 
 
 
State-Changed-From-To: open->feedback 
State-Changed-By: schweikh 
State-Changed-When: Sun Sep 29 06:42:55 PDT 2002 
State-Changed-Why:  
Is this still an issue with recent STABLE releases? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=16157 
State-Changed-From-To: feedback->closed 
State-Changed-By: linimon 
State-Changed-When: Thu Jul 22 06:38:28 GMT 2004 
State-Changed-Why:  
Feedback timeout (nearly 2 years). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=16157 
>Unformatted:

This can probably be fixed by not running the saver if resched_wanted().
I need to investigate the code more... a better way would be to make
all of the savers user-land processes, or at least kthreads.  I
wonder what Kazu thinks.
