Date: Mon, 1 Feb 1999 21:29:54 +0100 From: Andre Albsmeier <andre.albsmeier@mchp.siemens.de> To: John Dowdal <jdowdal@destiny.erols.com> Cc: Stormy Henderson <stormy@futuresouth.com>, stable@FreeBSD.ORG Subject: Re: network slowdown with rc5des Message-ID: <19990201212954.A17716@internal> In-Reply-To: <Pine.BSF.4.05.9902011317000.8524-100000@destiny.erols.com>; from John Dowdal on Mon, Feb 01, 1999 at 01:27:45PM -0500 References: <19990201111258.A89636@rain.futuresouth.com> <Pine.BSF.4.05.9902011317000.8524-100000@destiny.erols.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 01-Feb-1999 at 13:27:45 -0500, John Dowdal wrote: > On Mon, 1 Feb 1999, Stormy Henderson wrote: > > > A happy camper (John Dowdal, jdowdal@destiny.erols.com) once wrote... > > > There is a dramatic network slowdown on 3.0-stable when usign 100BT > > > cards and rc5des at the same time. The rc5des process causes the > > > slowdown even if it is set to idprio 1. > > > > I think you have the priority backwards (or didn't type the 3 hard > > enough). The manpage for idprio states: > > > > Priority is an integer between 0 and RTP_PRIO_MAX (usually 31). 0 is > > the highest priority > > > > Be happy... > > I did idprio 1 -PID, where PID is the PID of the rc5des job. IT worked, > because the rc5des process shows up with a nice value of 22. > > Also from the idprio man page: > > A process with an idle priority will run only when no other process is > runnable and then only if its idle priority is equal or greater than all > other runnable idle priority processes. > > This should imply that it doesn't matter whether I use 1 or 31 for > priority, because I do not have any other processes with idle priority. > > Based on the behavior (and not te sources), it appears that the > ethernet-card-is-ready interrupt is placed into a queue to be scheduled > later, instead of immediately preempting the idprio processes. IT also > appears that the interrupt will preempt the kernel idle loop causing > better performance if I kill -STOP the rc5des process. The big question > is why the system behaves differently when its executing a idprio job and > its internal idle loop. Interesting, yesterday I sent a message covering the same topic to -questions. I attach it below. I replaced rc5des (which was here also the initial reason to investigate a little) with a little shell script. It does mainly the same: Stressing the cpu. I have observed this behavior for a long time now; I am still runinng 2.2.8-STABLE... -Andre ---------------------- snip --------------------------------------- How idle is idletime scheduling priority really ? I wonder what effect has idle priority on system activities, I fear not much. Let's assume the following scenario: Two hosts (2.2.8-STABLE) connected via 100MBit with a 35MB file for testing via ftp. Small test shell script: #!/bin/sh while true; do true done 1. Both hosts idle: Speed 10.17 MB/s ftp> get aa local: aa remote: aa 227 Entering Passive Mode (192,168,18,2,156,75) 150 Opening BINARY mode data connection for 'aa' (36746099 bytes). 100% |**********************************************************************| 35884 KB 00:00 ETA 226 Transfer complete. 36746099 bytes received in 3.45 seconds (10.17 MB/s) 2. Sending host with the above script running: Speed 185.48 KB/s ftp> get aa local: aa remote: aa 227 Entering Passive Mode (192,168,18,2,156,79) 150 Opening BINARY mode data connection for 'aa' (36746099 bytes). 100% |**********************************************************************| 35884 KB 00:00 ETA 226 Transfer complete. 36746099 bytes received in 193.47 seconds (185.48 KB/s) 3. Same as 2. but script runs with idprio 5: 689.14 KB/s ftp> get aa local: aa remote: aa 227 Entering Passive Mode (192,168,18,2,156,78) 150 Opening BINARY mode data connection for 'aa' (36746099 bytes). 100% |**********************************************************************| 35884 KB 00:00 ETA 226 Transfer complete. 36746099 bytes received in 52.07 seconds (689.14 KB/s) 4. Receiving host with the above script running: Speed 949.32 KB/s ftp> get aa local: aa remote: aa 227 Entering Passive Mode (192,168,18,2,156,84) 150 Opening BINARY mode data connection for 'aa' (36746099 bytes). 100% |**********************************************************************| 35884 KB 00:00 ETA 226 Transfer complete. 36746099 bytes received in 37.80 seconds (949.32 KB/s) 5. Same as 4. but script runs with idprio 5: Speed 991.28 KB/s ftp> get aa local: aa remote: aa 227 Entering Passive Mode (192,168,18,2,156,83) 150 Opening BINARY mode data connection for 'aa' (36746099 bytes). 100% |**********************************************************************| 35884 KB 00:00 ETA 226 Transfer complete. 36746099 bytes received in 36.20 seconds (991.28 KB/s) So we get: no process : 10170 KB/s sender running : 185 KB/s sender running with idprio 5 : 689 KB/s receiver running : 949 KB/s receiver running with idprio 5: 991 KB/s What bugs me is that the rates are so bad in the both idprio'ed cases. Is there an explanation for that behaviour? Is it possible to catch the case when the system is _really_ idle so my process runs only then? Thanks, -Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990201212954.A17716>