From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Mon, 22 Nov 93 09:13:12 EST Subject: Linux-Development Digest #248 Linux-Development Digest #248, Volume #1 Mon, 22 Nov 93 09:13:12 EST Contents: Re: Linux Kernel Buffer questions... (ANDRE SCHR”TER INFORMATIK) 1542B and DSP3160 bad I/O Performance (RAINER SCHIELE INFORMATIK) Re: TAMU X INSTALL (Patrick J. Volkerding) Re: Don't use Motif for free sw: it now requires runtime royalties! (HALLAM-BAKER Phillip) Re: Don't use Motif for free sw: it now requires runtime royalties! (Erik Troan) Re: Linux Kernel Buffer questions... (Kai Petzke) Re: TAMU X INSTALL (Michael Cederberg) separate kernel initialization (Kai Petzke) [Q]: I want to develop EISA Ethernet driver HOWTO ? (PC-Gruppe) ---------------------------------------------------------------------------- From: 81239@novell1.rz.fht-mannheim.de (ANDRE SCHR”TER INFORMATIK) Subject: Re: Linux Kernel Buffer questions... Date: Mon, 22 Nov 1993 09:34:46 GMT In article evanson@plains.NoDak.edu (Kelly Evanson) writes: >From: evanson@plains.NoDak.edu (Kelly Evanson) >Subject: Linux Kernel Buffer questions... >Date: Sun, 21 Nov 1993 10:09:55 GMT > >I have been using Linux for a while now (using the Slackware >distribution currently) and I have a few questions about how >the kernel operates. Mainly requarding the use of memory as >buffers. > >The first time I booted Linux I was surprised to see that I >only had 450K free memory out of 16MB until I looked and saw >that the rest of the memory was being used by kernel buffers. >As I require more and more memory, I see that Linux frees >up buffers for me. Now regarding this procedure, I have a few >questions: > >#1. If I load up my machine (ie Xwindows+30 Clients+compiles+etc) > and I run out of regular memory (ie, > 16MB) and start to swap, > is there a minimum amount of memory withheld to use as a buffer > or do I completely lose my buffers. Is there a way to configure > the minimum amount of free buffers to be allocated? > >#2. Assuming I kill all the processes from #1 and return to a shell > and a few daemons (basically an Idle state) what method is used > to return the new free memory to buffer memory? Or do I ever > get it back? > >#3. What are the buffers, buffering? I've used SCO and it lets you > individually configure various buffer memory, ie Inodes, Disk blocks, > TCPIP buffers, etc. > >Mainly I curious to how the buffers recover from high to low load >transitions and vice-versa. If I turn my machine on an let it run for >3 weeks without a reset, assuming I periodically log-in, run a large >number of processes and memory and then log-out until the next day or >whenever; 3 weeks down the road, will I still be seeing the same >performance level that I did when I initially booted the machine? > >Kelly Evanson >evanson@plains.NoDak.edu > just another question: i had to copy parts of a cd to tape. when i started tar from the cd to the tape after a while the buffers wher 16 mb size and they gave *no* better performance. the tape begun to stream and stoped, begun to stream and stoped, ..., it took more than 5 hours to write 248 mb to tape. the 16 mb buffer werenot filed with a bigger amount of data from the cd-rom and then transferedto tape. the large buffer was completely useless... .now i wonder if there are more circumstances where such a large bufferis useless and a better strategy would have been better (i don't meanany special options to tar..:-) )? andre -- e-mail: A.Schroeter@DKFZ-Heidelberg.de ------------------------------ From: 81264@novell1.rz.fht-mannheim.de (RAINER SCHIELE INFORMATIK) Subject: 1542B and DSP3160 bad I/O Performance Date: Mon, 22 Nov 1993 09:39:23 GMT Hello I have a 1.6 GB DEC Harddisk and the Adaptec 1542B and i have only 800kb read performance(the disk have normal over 4MB disk I/O). Is this the result of using the Adaptec in asynchronus Mode. Give it a way to switch to synchron mode in the kernel. Give it a way to switch to higher DMA Speeds on the Adaptec(Sotfware). Is the 1542b driver going to use the synchron mode in the Future Please Reply when you have the answer , other UNIX give better performance Thanks Rainer ------------------------------ Subject: Re: TAMU X INSTALL From: volkerdi@mhd1.moorhead.msus.edu (Patrick J. Volkerding) Date: 22 Nov 93 05:57:28 -0600 In article <2cq2ar$j36@winx03.informatik.uni-wuerzburg.de> hohndel@informatik.uni-wuerzburg.de (Dirk Hohndel) writes: >Patrick J. Volkerding (volkerdi@mhd1.moorhead.msus.edu) wrote: >: In article <2cnkl9$3il@winx03.informatik.uni-wuerzburg.de> hohndel@informatik.uni-wuerzburg.de (Dirk Hohndel) writes: >: > >: >The problem with the Xconfig file this thread is about, is that you cannot >: >use your calculator on the modes therein, as it uses 1 2 3 ... for clock >: >names so that you don't know which clocks really are used. > >: It's not like you *couldn't* know the clocks you're using if you wanted to. >: If you look at the order in which the clocks are detected by the server, >: these are the same clocks that get numbered, 1, 2, 3, etc. Now, if you go >: down below and cut out modes on the Modes line that use clocks that you >: feel are too high, how unsafe could cycling through really be? > >Err... and this is `easy' and improves the setup process for the beginner ? >This means he not only has to fiddle around with calculating, he >additionally has to find out the clocks he is using... >C'mon... > In all honesty, yes. I know I could set a machine up quicker even taking those precautions. Figuring out which clocks to avoid is a *lot* quicker finding the specs on your card and monitor and then doing all the calculations recommended by the XFree86 documentation. Besides, who among us has never created a totally out of sync mode calculating by hand? I'll bet your monitor stayed scrambled a lot longer before you were able to kill X than it would have if you'd been able to quickly cycle through to "safe spots". >: >People blindly cycling through the modes risk their monitor and their >: >graphic cards. The fun part is, that tou may find a mode that looks nice and >: >stable, and running this mode for a week will kill your card and your >: >monitor. This is not theoretical bla bla, I can prove that this is true. > >: I asked the net whether anyone knew of a real case where this had happened. >: Until we hear of one, it is "theoretical", don't you think? Right now I >: have zero reports of problems. (and counting :^) > >Well. We have at least four reports of people ruining their cards with >stable looking modes. I cannot say whether any of these used Xconfig.1M >So it is not `thoretical' at all. Anyway, I think that trying to ridicule a >risk the developers of software point out, isn't a GoodThing... I'm not trying to ridicule anything. I think XFree86 2.0 is one the greatest pieces of [free] software ever created, and I have all the respect in the world its developers. Still, if you don't know whether Xconfig.1M was even involved, then all you can say for sure is that XFree86 has killed at least 4 video cards. > >My problem with this is that it has potential danger. You wouldn't include a >bomb with your CD, write on it `don't touch' and only because you haven't >heard of someone killed call this `save', would you ? > >(before you flame me on that one, I know it sucks, but you get the picture...) > But while we're on the subject of hidden bombs, this is from the new features list for XFree86 2.0: 11) Hard limits for the maximum dot-clock frequency used are introduced. These provide a rudimentary means of protecting the graphic boards from overclocking. (See the Known Bugs section for some more details). Gee, what a nice new feature. :^) So, it sounds to be like the danger introduced by Xconfig.1M with all your clocks is no worse than the danger of trying all your card's clocks manually under XFree86 1.3 when the user was not protected against overclocking. In fact, it's probably quite a bit safer since you don't spend as much time on the bad modes. The danger of getting one of these modes that supposedly works fine for a while and then kills your card after a few days would be exactly the same in either case. Also, the little notice above is the only mention of a danger of overclocking that I can find anywhere in the XFree86 docs. You definately do a better job of hiding your "bomb warnings" than I do. All the docs I've ever seen have led me to believe that you should try every clock detected from your card to make sure you don't miss any good modes. Anyway - I removed it from the main distribution. It's got a file named README_TAMU_WARNING next to it. It says you guys don't support (and in fact, hate) the file. I've done all I'm going to do. I think you could lighten up a little. --- Patrick Volkerding volkerdi@mhd1.moorhead.msus.edu ------------------------------ Crossposted-To: comp.infosystems.www,comp.windows.x,comp.windows.x.i386unix,comp.windows.x.motif,gnu.misc.discuss,comp.sources.d From: hallam@dxal18.cern.ch (HALLAM-BAKER Phillip) Subject: Re: Don't use Motif for free sw: it now requires runtime royalties! Reply-To: hallam@alws.cern.ch Date: Mon, 22 Nov 1993 11:23:43 GMT In article , ehhchi@maroon.tc.umn.edu (Ed H. Chi) writes: |>In article , R. Stewart Ellis wrote: |>>Mosaic is perhaps the single most important |>>free Internet application and the modal way of acquiring it is to ftp it |>>from one of these sites, already statically linked. If the statements about |>>license fees for every distributed copy are true, then those of us who have |>>been getting Mosaic this way will be cut off. |>> |>>This has always been my greatest reservation about OSF and Motif. |> |> |>What I don't understand is: |> |>Why didn't they use tk/tcl toolkit? It has the ease of Motif programming, |>and it is free! tk/tcl does not provide the same quality of product that Motif does. For a long time tcl was unusable on VMS systems and was flaky for developers. I had very serious hassle trying to get tkwww going because it required a widget that did not work with the new version of tk which we had already installed. I know that I am going to get flamed for saying this buy the UNIX hacker community that love software held together by string and hope but there is a difference between commercial quality software and free stuff. Usually you have to pay for commercial quality stuff, Mosaic being a rare exception (exceptions to the getting commercial quality for stuff you buy rule are far more frequent). |>I vote tk/tcl to be the toolkit of the choice. If you have never looked |>at tk/tcl, it is the time NOW. If you want to use a tk based browser try tkwww it has editing and is very nice. Mosaic is nicer though. |>O'Reilly will be coming out with a tc/tkl Book in the early '94 (it is |>written by a professor at Brekeley whose name has escaped me.) I have |>seen a draft of the book, and this book is *good*. |> |>Is there any chance for Mosiac to be rewritten in tc/tkl?? :) probably won't happen, but it would be a step in the right direction IMHO.> I would guess none whatsoever. Mosaic *is* a Motif interface to libwww. If you want to have another interface then you would throw out virtually all of Mosaic. I can't think offhand of much that would be usefull that has not been absorbed into libwww - thats one of the goals of modular programming. There are a hell of a lot of better improvements to Mosaic that I can think of other than fixing something that isn't broken. In my opinion NCSA made the right move in going for Motif. That allowed them to produce a proffessional quality product. It was the right engineering decision to make. The market agrees since they have chosen to use Mosaic instead of clients like tkwww which apeared earlier. In fact they have been so good at it that people confuse Mosaic with the web. OSF is a company and it has to show a return to its backers. It may be non-profit but it is certainly nor a charity. It has to meet costs and to do that it has to charge for its product. There is a very big difference between producing software that merely works and professional quality stuff. To produce the latter every component in the system has to be built and documented to a very high standard. That takes time and resources and will almost always involve costing money. Come the revolution this will all be different... In the meantime checkout for the 13 clients currently in release. I know of at least 5 more that are in the pipeline. Remember that one of the original goals of W3 was to allow the user the choice of access tool. -- Phillip M. Hallam-Baker Not Speaking for anyone else. ------------------------------ From: ewt@sunSITE.unc.edu (Erik Troan) Crossposted-To: comp.infosystems.www,comp.sources.d Subject: Re: Don't use Motif for free sw: it now requires runtime royalties! Date: 22 Nov 1993 13:08:08 GMT In article , Axel Boldt wrote: >In article ehhchi@maroon.tc.umn.edu (Ed H. Chi) writes: > >> Is there any chance for Mosiac to be rewritten in tc/tkl?? :) >probably won't happen, but it would be a step in the right direction >>IMHO.> > >Been done. Check out tkWWW. Location is in the WWW-FAQ, I guess. > It's also available at sunsite.unc.edu:/pub/languages/tcl/extensions. Don't ya'll know that *everything* is somewhere on sunsite :-). Erik -- ======================================================================== "Could I bend yer ear fer a tick?" ewt@sunsite.unc.edu = Erik Troan ewtroan@vnet.ibm.com (Team MWave) - Strictly Ballroom ------------------------------ From: wpp@marie.physik.tu-berlin.de (Kai Petzke) Subject: Re: Linux Kernel Buffer questions... Date: 22 Nov 1993 13:16:27 GMT In evanson@plains.NoDak.edu (Kelly Evanson) writes: >#1. If I load up my machine (ie Xwindows+30 Clients+compiles+etc) > and I run out of regular memory (ie, > 16MB) and start to swap, > is there a minimum amount of memory withheld to use as a buffer > or do I completely lose my buffers. Is there a way to configure > the minimum amount of free buffers to be allocated? Linux allocates all available memory for buffer space. Only a few kilobytes are reserved for "urgent" needs of memory, which may appear in the middle of interrupts, etc. Now, when you start more and more executables, linux has to find free memory. There are two major ways of getting them: by disallocating buffers ("buffer space"), or by freeing or swapping the pages of user process memory ("process space"). The approach of the kernel is easy: it takes a look at the first buffers, tries to free some of them (buffers may be currently in use!). If this results in a free page, it is fine. The next attempt goes to process space, where it tries to swap a clean page or swap a dirty page from a process. But pages may be shared among several processes, and have to be deallocated from every process separately, or swap space may be full, so this attempt can fail, too. Next attempt goes to buffer space again with an increased number of buffers, which are searched. Then it tries again with process space, taking a look at more pages, and so on. Generally spoken: Linux gives process space priority over buffer space. If your buffers are few, they will stay so, if you do not terminate processes. There has been a big thread about buffer management on this newsgroup recently. Maybe, there will be changes in the future. >#2. Assuming I kill all the processes from #1 and return to a shell > and a few daemons (basically an Idle state) what method is used > to return the new free memory to buffer memory? Or do I ever > get it back? Whenever Linux has to access a new block from disk, it tries to find a new buffer for it. If there are free block due to premature termination of processes, Linux will use these instead of overwriting old buffer blocks. >#3. What are the buffers, buffering? I've used SCO and it lets you > individually configure various buffer memory, ie Inodes, Disk blocks, > TCPIP buffers, etc. These buffers buffer disk blocks. Inodes are hold directly in the kernel. You may notice, that the total amount of user memory decreases, when you use "free" directly after start up and after some time on a heavily loaded system. The maximum number of inodes may be configured in one of the system include files - sorry, I forgot which one. >Mainly I curious to how the buffers recover from high to low load >transitions and vice-versa. ... Some of the memory allocated by the kernel, like that for inodes, is not returned to user space (as far, as I know - I may be wrong here). But for the Megabytes of disk buffers: yes, they can be reused both in process and block space. >Kelly Evanson >evanson@plains.NoDak.edu Kai -- Kai wpp@marie.physik.tu-berlin.de Advertisement by Microsoft in a well-known German magazine: If you don't like our programmes, than make your own ones. However, they expect you to use Microsoft products for this -:) ------------------------------ From: c878109@idcad7.uucp (Michael Cederberg) Subject: Re: TAMU X INSTALL Date: Mon, 22 Nov 1993 12:59:35 GMT >>>People blindly cycling through the modes risk their monitor and their >>>graphic cards. The fun part is, that tou may find a mode that looks nice and >>>stable, and running this mode for a week will kill your card and your >>>monitor. This is not theoretical bla bla, I can prove that this is true. One thing that I would like so see, is a MSDOZE program that could query my card about it's current mode. This way, I'll be able to use the parameters in BIOS which shouldn't burn my card. I realize that not all XFree86 users use MSDOS, but nearly everybody has the ability to boot from an MSDOS-floppy. Michael Cederberg [mceder@find2.denet.dk] -- Technical University of Denmark and State Library of Denmark, Computing Office ------------------------------ From: wpp@marie.physik.tu-berlin.de (Kai Petzke) Subject: separate kernel initialization Date: 22 Nov 1993 13:32:00 GMT Hi, this is a question which is more interesting for those, that have low memory. There have been times, that a Linux kernel was 300 kilobyte in size. Yes, I know, it was less robust and had less functionality at that time. But what about the code, which is used for initialization? I think of the code, which calculates BogoMips, checks for which devices are present, etc. Couldn't we move it all into the /usr/src/linux/init directory, and link it separately? In other words: when compiling the kernel, everything outside the init directory is compiled and linked first. It is everything needed by the kernel, once Linux is running. Linking it should not resolve any undefined symbols, etc. Then, the init routines should be linked against the rest of the kernel. Thus, init functions may call (and very likely even must call) normal kernel functions, or may reference kernel data, but not vice versa. After initialization is completed, the space used for the initialisation routines is discarded. Don't say this isn't feasible or complicated to implement. Even Messy Dos does it. When device drivers are loaded (for example, via DEVICE=foo.sys), the driver tells DOS upon exit, up to which address the driver should be kept resident. So well written DOG drivers have their initialization code last, and tell DOS to strip that upon exit. -- Kai wpp@marie.physik.tu-berlin.de Advertisement by Microsoft in a well-known German magazine: If you don't like our programmes, than make your own ones. However, they expect you to use Microsoft products for this -:) ------------------------------ From: pcgruppe@n1.imsd.uni-mainz.de (PC-Gruppe) Subject: [Q]: I want to develop EISA Ethernet driver HOWTO ? Date: 22 Nov 1993 14:05:24 GMT Hello, I am still using Longshine EISA Ethernet Cards with WFW. The Card s are fast and nice. I want t to use this cards also with LINUX and there is manpower to develop a driver, BUT i dont know how to write a driver for LINUX. I get everything i need from longshine, like information about the chipset used, its registers, SCO Driver sources, some Assembler code ... . Please help me and LINUX will get EISA ethernet power. There is no planning for commercial use of this so it will be released from the first beta version. REINER from pcgruppe@n1.imsd.uni-mainz.de ------------------------------ ** FOR YOUR REFERENCE ** The service address, to which questions about the list itself and requests to be added to or deleted from it should be directed, is: Internet: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.development) via: Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU Linux may be obtained via one of these FTP sites: nic.funet.fi pub/OS/Linux tsx-11.mit.edu pub/linux sunsite.unc.edu pub/Linux End of Linux-Development Digest ******************************