From owner-freebsd-net Mon Jan 8 4:36: 7 2001 Delivered-To: freebsd-net@freebsd.org Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by hub.freebsd.org (Postfix) with ESMTP id 94A7E37B6A9 for ; Mon, 8 Jan 2001 04:33:07 -0800 (PST) Received: from ac.upc.es (fonoll.ac.upc.es [147.83.32.14]) by roura.ac.upc.es (8.11.0/8.11.0) with ESMTP id f08CZfO02123; Mon, 8 Jan 2001 13:35:45 +0100 (MET) Message-ID: <3A59B41D.B20E31ED@ac.upc.es> Date: Mon, 08 Jan 2001 13:35:41 +0100 From: Oscar-Ivan Lepe-Aldama Organization: DAC/UPC X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: es, en MIME-Version: 1.0 To: net@freebsd.org Subject: On the performance of the xl driver Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I have a 4.1.1 box set up as a router that seems to have trouble dealing with packet rates exceeding 1000 pkt/s. The router is a 100Mhz Pentium with 16MB of RAM and two 3Com905B-TX ethernet adapters attached each to a Ethernet subnetwork. The problem manifests itself when some packets experience a huge forwarding latency, relatively to the average value. The average forwarding latency time is 52us while the troubled packets exhibit a latency of up to 6000us. I have observed that this is due to a call to the xl_stats_update() routine while the kernel is at a high priority level (perhaps splimp). This happens as part of the xl_intr routine, when the network-adapter's interrupt status word has its XL_STAT_STATSOFLOW bit set. The xl_stats_update() takes almost 6000us to complete and processing for whichever packet that arrives during this time will be deferred. Moreover, I have observed that this only happens when the packet rate is 1000 pkt/s or more. At lower rates, the XL_STAT_STATSOFLOW bit is never set because the network-adapter's statistics buffer is periodicaly clean at a "sufficient" pace -the xl_stats_update() is called from softclock() at a low kernel's priority level.- To make matters worst, this is a phenomenon directly proportional to the packet rate. So the question is weather this is a bug or not and why. Another point. To temporarly solve this I have disable the network adapter's XL_STAT_STATSOFLOW interrupt (at if_xlreg.h, #define XL_INTRS) but I don't know what are the implications of this, so any comments are welcome. Cheers, P.S. I'm not subscribed to the list so please Cc to my email account. Thanks. -- ======================================================================== 0 0 0 Oscar-Ivan Lepe-Aldama | UPC-Campus Nord, DAC 0 0 0 e-mail: oscar@ac.upc.es | Modul D6, despatx 116 0 0 0 phone: +34 93 401 7187 | Jordi Girona, 1-3 U P C fax: +34 93 401 7055 | 08034 Barcelona - SPAIN WWW: http://www.ac.upc.es/homes/oscar/ ======================================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message