From owner-freebsd-net Wed May 9 3:54:15 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 97D7337B423 for ; Wed, 9 May 2001 03:54:09 -0700 (PDT) (envelope-from oscar@ac.upc.es) 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 f49As2413230 for ; Wed, 9 May 2001 12:54:02 +0200 (MET DST) Message-ID: <3AF921CA.5C446E40@ac.upc.es> Date: Wed, 09 May 2001 12:54:03 +0200 From: Oscar-Ivan Lepe-Aldama Organization: DAC/UPC X-Mailer: Mozilla 4.76 [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. Best regards, -- ======================================================================== 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