From owner-freebsd-hackers Sat May 9 05:56:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA10684 for freebsd-hackers-outgoing; Sat, 9 May 1998 05:56:01 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA10668 for ; Sat, 9 May 1998 05:55:57 -0700 (PDT) (envelope-from se@dialup124.zpr.uni-koeln.de) Received: from dialup124.zpr.Uni-Koeln.DE (dialup124.zpr.Uni-Koeln.DE [134.95.219.124]) by Octopussy.MI.Uni-Koeln.DE (8.8.8/8.8.8) with ESMTP id OAA29792; Sat, 9 May 1998 14:55:42 +0200 (MET DST) Received: (from se@localhost) by dialup124.zpr.Uni-Koeln.DE (8.8.8/8.6.9) id MAA01446; Sat, 9 May 1998 12:37:22 +0200 (CEST) X-Face: " Date: Sat, 9 May 1998 12:37:21 +0200 From: Stefan Esser To: Bill Paul Cc: cdillon@wolves.k12.mo.us, hackers@FreeBSD.ORG, Eivind Eklund Subject: Re: Call for testers for ThunderLAN ethernet driver Mail-Followup-To: Bill Paul , cdillon@wolves.k12.mo.us, hackers@FreeBSD.ORG, Eivind Eklund References: <19980505165604.36955@follo.net> <199805051527.LAA29903@skynet.ctr.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: <199805051527.LAA29903@skynet.ctr.columbia.edu>; from Bill Paul on Tue, May 05, 1998 at 11:27:52AM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1998-05-05 11:27 -0400, Bill Paul wrote: > The Prosignia server I have uses an NCR SCSI card in one of its PCI > slots. Dmesg says: > > Probing for devices on PCI bus 0: > chip0 rev 2 on pci0:0:0 > vga0 rev 0 on pci0:11:0 > ncr0 rev 4 int a irq 5 on pci0:12:0 > (ncr0:0:0): WIDE SCSI (16 bit) enabled(ncr0:0:0): 10.0 MB/s (200 ns, offset 15) > (ncr0:0:0): "COMPAQ WDE4360W 1.52" type 0 fixed SCSI 2 > sd0(ncr0:0:0): Direct-Access > sd0(ncr0:0:0): WIDE SCSI (16 bit) enabled > sd0(ncr0:0:0): 40.0 MB/s (50 ns, offset 15) > 4094MB (8386000 512 byte sectors) > tlc0 rev 16 int a irq 9 on pci0:16:0 > tlc0: Ethernet address: 00:80:5f:7d:fb:b7 > tl0 at tlc0 physical interface 1 > tl0: 10/100Mbps full duplex autonegotiating > tl0: autoneg complete, link status good (full-duplex, 100Mb/s) > chip1 rev 1 on pci0:20:0 > chip2 rev 0 on pci0:20:1 I've got some other Compaq machine at work which can't be installed over the network currently for lack of a NetFlex / ThunderLan driver. When are you going to commit the driver ? > One thing I have noticed about the NCR SCSI subsystem though. While I > was working on the driver I used a debugging kernel built using config -g. > This results in a large kernel image because of all the debug symbols; > typically the image was 9MB or so. (Of course used strip -d to make a > second image to actually boot from; the debug image is just for gdb.) > When time came to link the image, this naturally resulted in a lot of > disk activity, however I noticed that during this time, there seemed > to be a delay when trying to initiate disk I/O in another process. > That is, if I switched to another terminal and tried to do an 'ls -l' > on some directory (which hadn't been cached yet) while the kernel was > linking, the 'ls' command would hang there for a second or so until > the disk activity from the linker process died down. In other words, it > seems as though one I/O bound process can sort of monopolize the SCSI > bus. This could easily be SOP, but I hadn't noticed behavior like this > with other hardware before. Hmmm, that should not depend on the driver, actually. A simple test should be a "dd" to /dev/null from both /dev/rsd0c and /dev/sd0c and to measure the impact on the simultanous "ls -l". Then you should copy a large amount of data (/dev/zero :) into a file in the same partition were you perform the ls, and to another disk drive, if possible. The results of these tests should point out the effect of the buffer cache vs. raw accesses to the device, and of the driver vs. the drive (impact of large transfer to one drive on another drive ...) There has been quite some discussion of delays caused by the elevator algorithm in pathological cases, one or two years ago. (IIRC, writing huge amounts of data to a new file system could block other processes.) Regards, STefan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message