Xref: utzoo comp.unix.sysv386:2821 comp.unix.questions:27446 Path: utzoo!attcan!telly!lethe!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uunet!iphase!floydf From: floydf@iphase.UUCP (Floyd Ferguson ENG) Newsgroups: comp.unix.sysv386,comp.unix.questions Subject: Re: Tuning SYSVR3 (Esix Rev D) (LONG!) Message-ID: <319@iphase.UUCP> Date: 6 Dec 90 22:03:33 GMT References: <1990Dec02.001311.16727@virtech.uucp> <1990Dec4.031037.2718@jwt.UUCP> <1990Dec4.162751.12224@bilver.uucp> Reply-To: floydf@iphase.UUCP (Floyd Ferguson ENG) Organization: Interphase Corp. Dallas TX Lines: 31 >->In article <1990Dec02.001311.16727@virtech.uucp> cpcahil@virtech.UUCP (Conor P. Cahill) writes: >->>Even if you set this variable to some high value, it is still possible >->>that at that new time period following a large disk update, the system >->>will slow down momentarily due to many dirty pages that still need to >->>be written out, so you may be in a no-win situation. > There was some considerable discussion about this maybe two years ago with regards to the Motorola UNIX product. Their version used a linear search to scan for dirty buffers, which worked well until the total buffer cache exceeded 2 MB, then things would periodically get very slow. I don't know if this was pre- or post- bdflush. The other factor that can really slow things down is a controller (or driver) that does not group writes. For instance, the 3.2.0 SCO driver for the HP Vectra ESDI controller will read about 700 KB/sec, but will only write at 70 KB. Needless to say, writing a lot of dirty buffers out will take a while. In article <1990Dec4.162751.12224@bilver.uucp> bill@bilver.UUCP (Bill Vermillion) writes: >I can't tell you what takes priority in a caching controller, but I will >tell you this, it more than makes a system feel snappy. > ....... >that I really WANT one myself. > I would wait until we find out how they work on the new systems (V.4) that are no longer burdened with the problem of statically defined buffer cache allocation. Cache memory is cache memory, regardless of which side of the host bus it resides. The only difference is the algorithm used to access it. Floyd Ferguson uunet!iphase!floydf