From owner-freebsd-hackers Tue Dec 16 19:40:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA02439 for hackers-outgoing; Tue, 16 Dec 1997 19:40:49 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA02431 for ; Tue, 16 Dec 1997 19:40:43 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id OAA01300; Wed, 17 Dec 1997 14:04:26 +1030 (CST) Message-Id: <199712170334.OAA01300@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: jak@cetlink.net (John Kelly) cc: Mike Smith , Greg Lehey , FreeBSD Hackers Subject: Re: 3com 3c509 card In-reply-to: Your message of "Wed, 17 Dec 1997 04:14:07 GMT." <34974b92.96107160@mail.cetlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Wed, 17 Dec 1997 14:04:26 +1030 From: Mike Smith Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id TAA02434 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > All you have established is that a known ~50% improvement in the CPU > > utilisation of the driver has not affected the amount of CPU used for > > your FTP transfer. > > If it's true that the driver is 50% more efficient with the SMC Ultra > 16, then how is it possible that the FTP code performs worse to keep > the total percentage about the same? Are you saying that the driver > component is so small that the improvement is drowned out by the FTP? This would appear to be the logical conclusion, presuming no other influences exist. Without demonstrating the latter, however, you can't be sure of anything. > > First thing anyone should learn; how to measure things. Whether you're > > talking engineering, physics, chemistry or computing; if you don't know > > what you're measuring, the numbers mean nothing. > > If I can't route 4 ethernet interfaces with SMC Ultras then a rigorous > academic exercise has no value for my purposes. I just want a rough > projection that's reasonably accurate. "AT Bus Design" (Edward Solari, Annabooks), p 6-101, quoted without permission, excerpt from table 6-3: ISA AND E-ISA PLATFORM STANDARD ACCESS MEMORY CYCLE LENGTH BUS OWNER CYCLE BEGINS CYCLE ENDS CYCLE CYCLE SIZE LENGTH --------------------------------------------------------------- PLAT FORM (sic) .5 TCLK TO END COMMAND 8 BITS 6 TCLK CPU ACT BALE ACT PERIOD 16 BITS 3 TCLK For reference, TCLK is the period of BCLK, ie. 1 TCLK ~= 120ns for the standard 8.33MHz BCLK. So a 16-bit memory cycle on the ISA bus takes at least 360ns. If you flip that the other way around and account for the other .5 TCLK idle before BALE can go active again, you get about 2.5 16-bit cycles per microsecond, or about 5MB/sec ISA memory bandwidth. Of couse, you could just say that the 5MB/sec figure has been generally known for the last decade or so, but I thought a really simple adademic wank might convince you of the basic usefulness of measurement doctrine. Now, if you take into account just a little CPU overhead, interrupt cycle overhead, metadata overhead, you will quickly see that you're not going to route 4MB/sec aggregate traffic through anything on the ISA bus, period. Personally, I'd recommend a 4-port Zynx card. mike