From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Wed, 6 Oct 93 19:13:11 EDT Subject: Linux-Development Digest #145 Linux-Development Digest #145, Volume #1 Wed, 6 Oct 93 19:13:11 EDT Contents: Re: [PATCH] BogoBoost speedup for Linux (Thomas McWilliams) Re: Linux Slowly Dying Off? (Barzilai Spinak) Simplified loadkeys (Brian McCauley) Re: Linux Slowly Dying Off? (Barzilai Spinak) Xfree vs. BIOS (Michael Griffith) Re: linux scheduler alternatives??? - MY IDEA (Scarrow) Re: linux scheduler alternatives??? - MY IDEA (Thomas Koenig) Re: linux scheduler alternatives??? - MY IDEA (Brandon S. Allbery) TCP Window Size bug? (Kelly Murray) Re: [PATCH] BogoBoost speedup for Linux (Scott D. Heavner) PPP for Linux? Well... almost as good (Patrick Naubert) [Q] Sound from Orchid Faherenhit VA/VLB video (Sohail M. Parekh) Re: Xfree vs. BIOS (Jerry Whelan) Re: CFC/CFI: XSysadmin (Zeyd M. Ben-Halim) ---------------------------------------------------------------------------- From: tmcwill@iat.holonet.net (Thomas McWilliams) Subject: Re: [PATCH] BogoBoost speedup for Linux Date: Wed, 6 Oct 1993 16:28:04 GMT pfau@cnj.digex.com (Thomas Pfau) writes: > This had absolutely no effect on my system. BogoMips stayed at > 9.98, dhryston gives the same result. Is it possible that some > newer systems are shipping with higher DRAM refresh timer values? > > My system is a DECpc420sx (20MHz 486SX). > Yes, it is possible that some newer systems ship with more optimal refresh rates. Actually, your system may be benefitting from the patch but the BogoMips test is not measuring it. Certain refresh implementations allow for transparent refresh anytime the processor's external address bus is inactive. This would be the case on a 486 calculating its BogoMips. All addressing would remain inside the 486s internal cache. Better results are likely to be seen during a lengthy compile, or a system under heavy load executing many processes. Slower 386 class systems are likely to benefit most. I'd be interested in your results under various conditions and various softwares. Try running comparisons with caches disabled and you might be able to tell if your system already provides an improved refresh rate. The more I think about it, the BogoMips test inadequately exercises this patch on 486 class and certain cached 386 systems unless caching is disabled. Of course these systems benefit from the improved refresh rate when caching is enabled, but simplistic benchmarks may fail to properly demonstrate the improvement. Thomas ------------------------------ From: barspi@wam.umd.edu (Barzilai Spinak) Crossposted-To: comp.os.linux.help,comp.os.linux.misc Subject: Re: Linux Slowly Dying Off? Date: 6 Oct 1993 17:13:22 GMT Barzilai Spinak ------------------------------ From: bam@wcl-l.bham.ac.uk (Brian McCauley) Subject: Simplified loadkeys Date: 06 Oct 1993 17:08:16 GMT Reply-To: B.A.McCauley@bham.ac.uk I've started making some changes to loadkeys to simplify the key maps. The standard uk.map contains many errors and rather than make fixes there it seems easier to modify loadkeys. What I am doing is to add a token "auto" which when applied to an entry automatically defines the ctrl and meta varients where they are obvious. E.g. the {uk,us}.map currently says: keycode 7 = six asciicircum control keycode 7 = Control_asciicircum alt keycode 7 = Meta_six to be completely consistant it should say: keycode 7 = six asciicircum control keycode 7 = Control_asciicircum shift control keycode 7 = Control_asciicircum alt keycode 7 = Meta_six shift alt keycode 7 = Meta_asciicircum control alt keycode 7 = Meta_Control_asciicircum control shift alt keycode 7 = Meta_Control_asciicircum [Meta_Control_asciicircum is not actually reconised by loadkeys at present] With my new loadkeys it need simply read: auto keycode 7 = six asciicircum auto control keycode 7 = Control_asciicircum Actually IMHO having ``control keycode 7'' generate Control_asciicircum is wrong in which case all that is needed is: auto keycode 7 = six asciicircum Now isn't that neater. I'll post/upload the paches in a couple of days. Any comments on other things I should change while I'm in there? -- \\ ( ) No Bullshit! | Email: B.A.McCauley@bham.ac.uk . _\\__[oo from | Voice: +44 21 471 3789 (home) .__/ \\ /\@ /~) /~[ /\/[ | +44 21 627 2171 (work) . l___\\ /~~) /~~[ / [ | Fax: +44 21 627 2175 (work) # ll l\\ ~~~~ ~ ~ ~ ~ | PGP: finger bam@wcl-rs.bham.ac.uk ###LL LL\\ (Brian McCauley) | ICBM: 52.5N 1.9W ------------------------------ From: barspi@wam.umd.edu (Barzilai Spinak) Crossposted-To: comp.os.linux.help,comp.os.linux.misc Subject: Re: Linux Slowly Dying Off? Date: 6 Oct 1993 17:25:16 GMT In article <28tk5k$mq2@jake.esu.edu>, James Farrell wrote: > >Hello World! > >John Munsch (johnm@spudge.lonestar.org) wrote: >: I don't think it really matters. Linux is not significantly different from >: any other Unix I've seen so far (with the possible exception of NeXTStep). It >: is nowhere near anything that an end user would ever consider installing. Let >: me describe a system that would "play in Peoria" to you. > >: It: >: 1) Boots from a floppy and presents a character mode interface (in >: color if available) for the beginning of the installation process. >Part of this is very possible, unfortunatly it is very difficult for any >PC application to know exactly what wing-nut maker of hardware you happen >to have. To run something like UNIX, the user _must_ have knowledge of his >hardware, and how to configure/operate it. > >: 2) X is provided as a normal part of the installation process. >This will probably never happen. XFree needs to know exactly what hardware >you have, and what scan rates to use. The could be cured with a BIOS call, >but unfortunately for this, the BIOS is completely shut off and ignored. >This could be solved with a new kernel system call for setting the video >mode, but that would be completely unportable. XFree is not made _for_ >Linux, it's made to be ported to (theoritically) any Unix-like 32 bit OS. >Every one of these OS's would need to have this unprotable video kernel >call for this ugle scheme to work. /* The first time didn't work out. Here it goes again... */ I want to give a humble (and maybe a little naive) comment on that. If, as you say, all the needed video info can be gotten by BIOS calls, a few lines of code could be added to the kernel before it goes into protected mode to find out this info. Then, a little program can be written to install XFree, which asks the kernel "What did you find out?", and then fill in the information in that file that XFree uses when it starts (xcongif or something like that, I think). Now, this may have already been done; so, I may be talking too much... And don't ask ME to do it because 1) I don't have Linux yet, 2) It would take me a few months to learn Linux before I could do it. Barzilai Spinak ------------------------------ From: grif@ucrengr.ucr.edu (Michael Griffith) Crossposted-To: comp.os.linux.help,comp.os.linux.misc Subject: Xfree vs. BIOS Date: 6 Oct 1993 18:14:10 GMT In article <28uv1s$gos@cville-srv.wam.umd.edu>, Barzilai Spinak wrote: [citation deleted] > I want to give a humble (and maybe a little naive) comment on that. >If, as you say, all the needed video info can be gotten by BIOS calls, a few >lines of code could be added to the kernel before it goes into protected mode >to find out this info. Then, a little program can be written to install >XFree, which asks the kernel "What did you find out?", and then fill in the >information in that file that XFree uses when it starts (xcongif or something >like that, I think). Now, this may have already been done; so, I may >be talking too much... [sig deleted] Perhaps you miss the point. Although it might be easy enough for us to interrogate the BIOS in Linux, it will not be so easy to do that for the dozen or so other OS's that Xfree runs on. The Xfree folks are not interested in solutions that only work on one out of many of the operating systems that they support. -- Michael A. Griffith grif@cs.ucr.edu ------------------------------ From: bairds@penchiss10.ee.pdx.edu (Scarrow) Subject: Re: linux scheduler alternatives??? - MY IDEA Date: 6 Oct 93 05:28:16 GMT ken@PSUEDVAX.PSU.EDU (Kenneth J. Hoover) writes: > Can anyone who knows about/uses Windoze NoT send me email to let me know if >WNT does this? NT uses a *lot* of VMSisms. VMS + 111 ----- WNT Scary, huh? -- Shawn L. Baird (Scarrow) | "By all means, take the moral high ground -- bairds@ursula.ee.pdx.edu | all that heavenly backlighting makes you a =========================| much easier target." ==Solomon Short ------------------------------ From: ig25@fg70.rz.uni-karlsruhe.de (Thomas Koenig) Subject: Re: linux scheduler alternatives??? - MY IDEA Date: 6 Oct 1993 19:56:59 GMT bairds@penchiss10.ee.pdx.edu (Scarrow) writes: >ken@PSUEDVAX.PSU.EDU (Kenneth J. Hoover) writes: >> Can anyone who knows about/uses Windoze NoT send me email to let me know if >>WNT does this? NT uses a *lot* of VMSisms. > VMS > + 111 > ----- > WNT >Scary, huh? Intentional, but I still think NWT would have been a better name :) -- Thomas König, ig25@rz.uni-karlsruhe.de, ig25@dkauni2.bitnet The joy of engineering is to find a straight line on a double logarithmic diagram. ------------------------------ From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: linux scheduler alternatives??? - MY IDEA Date: Wed, 6 Oct 1993 11:29:17 GMT In article <28sdon$qdc@genesis.ait.psu.edu> ken@PSUEDVAX.PSU.EDU writes: > I feel, being a VMS sysadmin, that I should point out that OpenVMS (formerly >VAX/VMS) uses a dynamic priority adjustment in its management of system load, >based on a starting "base" priority assigned to the user's process, and I >wouldn't be surprised if Windows NT does this as well. I will hand pointers to If you've ever looked at a Unix internals book, compare proc->p_nice to proc->p_pri sometime. It's nothing new, or particularly (VMS|Unix|NT|what)ish --- just missing from the first draft of that proposed scheduler. ++Brandon -- Brandon S. Allbery kf8nh@kf8nh.ampr.org bsa@kf8nh.wariat.org "MSDOS didn't get as bad as it is overnight -- it took over ten years of careful development." ---dmeggins@aix1.uottawa.ca ------------------------------ From: kem@prl.ufl.edu (Kelly Murray) Subject: TCP Window Size bug? Date: 6 Oct 1993 20:51:08 GMT I've run across what I think might be a bug in the Linux TCP implementation. When I tried to run X programs from a Linux box to my Xterminals, it didn't work. The X connection was made, but then nothing happened. I tracked this down and discovered that the initial TCP connection from the Linux box specifies only a 512 byte window size, but specifies a MSS, or maximum segment size of ~1200 bytes. My TCP implementation employs the "Silly Window Avoidance" technique which will not transmit data on a TCP connection until the window size is big enough to accept a full packet of data. Thus, my Xterminal is waiting for the window size to grow big enough before it sends any data in response to the initial X connection request. I patched my software to deal with this, but I'm wondering whether the Linux software is correct. Looking at the TCP sources, it uses a constant 512 window size for the initial connection. Shouldn't it either send a bigger initial window size, or maybe retransmit the segment with a larger window size that corresponds to the true capability to accept data? -Kelly Murray (kem@prl.ufl.edu) ------------------------------ From: sdh@fishmonger.nouucp (Scott D. Heavner) Subject: Re: [PATCH] BogoBoost speedup for Linux Date: Wed, 6 Oct 1993 20:49:53 GMT Reply-To: sdh@po.cwru.edu Thomas McWilliams (tmcwill@iat.holonet.net) wrote: > BogoBoost (tm) is a patch to the Linux kernel setup code that will > boost your system performance. Generally speed increases on the > order of 2 percent to 5 percent are typical. It is based on the time > tested technique of resetting the DRAM refresh timer to an optimal > rate. Ok, I have a few questions for everyone, and some results/comparisons of the effects of this patch on my computer. First the questions: 1) When is this DRAM timer used? Someone said that the cache could be restructured to hide this, but does cache have anything to do with this? Sorry, I don't know much about hardware architecture, but shouldn't there be something on the motherboard that has no function but to count up to XXX and pump some juice through the DRAM? 2) Does cache or external memory affect BogoMIPS? Linus posted the method to calculate BogoMIPS as the time to do a DEC and a JMP, and it seems all this could be accomplished within the CPU. Now the results: from tcsh's bultin time on the method described below. USER = The time the process spent in user mode in cpu seconds KERNEL = The time the process spent in kernel mode in cpu seconds. TOTAL = The elapsed time in seconds. CPU% = 100% for all tests (same for other params: 0+0k 0+0io 12pf+0w) NORMAL KERNEL: BOGO USER KERNEL TOTAL CACHE(64k) 16.61 66.150 0.070 1:06.21 NO-CACHE 16.61 66.110 0.100 1:06.21 NO-CACHE/NO TURBO 5.11 112.100 0.210 1:52.31 BOGOBOOST KERNEL: BOGO USER KERNEL TOTAL CACHE(64k) 16.61 64.900 0.090 1:04.98 NO-CACHE 16.61 64.900 0.090 1:04.99 NO-CACHE/NO TURBO 5.21 110.240 0.170 1:50.41 Depending on how you do your statistics, you can get a number close to 2% which could be called the speed increase. METHOD: I made a boot floppy containing the patched kernel (I didn't want to risk my hard disk yet) and stuck tcsh and init on it. I set up init to come up single user with no other processes but itself and a tcsh shell. No other file systems were mounted. I modified my hard disk root to come up in the same configuration, but with a normal kernel. I compiled the program below which should be immune to any caching effects with "gcc -N -s test.c" and ran it on a 486-33-ISA machine after first cat'ing the binary to /dev/null to get it into cache to offset any floppy/hard disk errors. /* - BogoTest.c (sdh@po.cwru.edu 06 Oct 1993) - */ #include main() { int i; unsigned char j[1000000], k[1000000]; for (i=0;i<1000000;i++) j[i]=i; for (i=0;i<1000;i++) memcpy(k,j,1000000); } /* ----- */ ------------------------------ From: naubertp@cognos.COM (Patrick Naubert) Subject: PPP for Linux? Well... almost as good Date: Wed, 6 Oct 1993 18:53:44 GMT [ Article crossposted from comp.os.linux.misc ] [ Author was Patrick Naubert ] [ Posted on Wed, 6 Oct 1993 18:51:53 GMT ] Andrew R. Tefft (teffta@cs690-3.erie.ge.com) wrote: : About once a week on average someone asks if there is PPP for Linux. : Nobody ever answers so the general consensus is no -- it seems that : everyone with the capability to produce PPP is satisfied with SLIP. Well, *I* need PPP. I am about to connect a line to a PPP server full-time in order to connect a BBS to the Internet full-time. I need to have a sync line to my host, and I as know (heard) only PPP will support that kind of link. Anyways, I figured that if I want it, I just can't rant and rave for some- one to do it. So I put myself to it. Here's what I did so far : 1- Got the address of the current 386BSD PPP source code. 2- I downloaded it. 3- I printed the kernel diffs out and took a look. I guess Linux and 386BSD kernels aren't the same, duh! :) This might be harder than I thought (and I thought it was going to be impossible...). 4- I prayed to all the gods I know to spontaneously change the source code to be a clean compile on the linux kernel. 5- I woke up the next day and the source hadn't changed. Bummer... (I was very depressed, as this is the technique I used in University, and I was sometimes sucessfull :) ) 6- I am writing this to ask for an amazing amount of help from the Linux community. I will coordinate the effort, but I don't think I can re- write a PPP driver inside a year... I will coordinate in the following matter: - I will list the functions necessary to run the PPP core, and these functions will need to be reverse-engineered into the linux kernel. I need a Linux kernel hacker. PLease line up, one at a time :) - I will start a few runs to compile the PPP core and ask for help on the compiler errors that will appear. I need a dedicated person to answer my pleas. Someone who knows C (obviously) and who knows the quirks of the current GCC implementation. I don't want to have to post in linux.help everytime I get a compile error that I cannot handle. So, until someone tells me I am full of sh*t and that there already is a team working on this, please consider *me* as being the PPP effort coordinator. My name is Patrick Naubert and I live in Ottawa, Canada. I can be reached at naubertp@cognos.com and/or root@qube.ocunix.on.ca I will try to crospost this message to linux.development. TTFN! ------------------------------ From: sohail@trixie (Sohail M. Parekh) Subject: [Q] Sound from Orchid Faherenhit VA/VLB video Reply-To: sohail@rhonda.jsc.nasa.gov Date: Wed, 6 Oct 1993 21:58:47 GMT I have a Orchid Faherenhit VA/VLB video card (S3 based). It has voice anno- tation features. It has microphone and speaker jacks at the back. Under DOS/ MS-Windows I can use it to record and play voice messages. I am not sure - a) How it works ? b) How does the features compare to a regular sound card (SoundBlaster!) ? c) Can I use the sound features of this board under LINUX (like I can under MS-Windows) ? d) If I buy a CD Drive can I use this to play sound CD's ? Sincerely, Sohail -- Sohail M. Parekh Grumman Data Systems sohail@rhonda.jsc.nasa.gov 12000 Aerospace Ave. (713) 483-5912 Houston, TX 77034 ------------------------------ From: guru@camelot.bradley.edu (Jerry Whelan) Crossposted-To: comp.os.linux.help,comp.os.linux.misc Subject: Re: Xfree vs. BIOS Date: 6 Oct 1993 22:28:12 GMT -} > I want to give a humble (and maybe a little naive) comment on that. -} >If, as you say, all the needed video info can be gotten by BIOS calls, a few -} >lines of code could be added to the kernel before it goes into protected mode -} >to find out this info. Then, a little program can be written to install -} >XFree, which asks the kernel "What did you find out?", and then fill in the -} >information in that file that XFree uses when it starts (xcongif or something -} >like that, I think). Now, this may have already been done; so, I may -} >be talking too much... -} [sig deleted] -} -} Perhaps you miss the point. Although it might be easy enough for us -} to interrogate the BIOS in Linux, it will not be so easy to do that -} for the dozen or so other OS's that Xfree runs on. The Xfree folks -} are not interested in solutions that only work on one out of many of -} the operating systems that they support. What the first author is suggesting would actually have no portability impact on XFree86. He is asking for a utility that runs during boot that sucks out the video timing values from the bios. That information could easily be written to in an Xconfig format file. That file can then be used by an XFree86 server with absolutely no modifications to the server source. I agree that this sort of program would be a very good thing. I ask that anyone who writes such a routine make a version that runs under native dos as well as during the linux boot sequence. That way anyone who wants to automagically determine their video mode information, but doesn't necessarily have linux, can do it. After all, the program would only need to be run once unless a new card is installed. =============================================================================== Jerry Whelan guru@stasi.bradley.edu ------------------------------ From: zmbenhal@netcom.com (Zeyd M. Ben-Halim) Subject: Re: CFC/CFI: XSysadmin Date: Wed, 6 Oct 1993 21:43:29 GMT In article <1993Oct6.112349.20817@swan.pyr> iiitac@swan.pyr (Alan Cox) writes: >In article zmbenhal@netcom.com (Zeyd M. Ben-Halim) writes: >>The problem with OI is speed (or the lack thereof) even with 8MB. >And the 4Mb shared library image.. >> >>>Otherwise I would say: xview3? >>xview sources could take a day to compile on a 386-33/4MB. >Funny.. they never took that long when I built xview programs in 4Mb. Unless >you are using UIT and C++ in which case they take all day in 8Mb too. The >good thing about xview is the final binaries are fairly nippy and also the >xview toolkit is so easy to use compared with Xt that you get results much >faster. (Oh and it looks pretty). I know it is not really xview's fault, but any program that includes a lot of initialized structures (bitmaps, cursors) will spend forever while gcc handles it. I compiled xcalentool and it took the better part of the night. Don'y get me wrong, I LIKE xview. I can't stand all that psuedo-oop Xt stuff. For development work, I guess one needs 8MB to feel comfortable. The binaries run ok with 4MB. >>How about tcl/Tk? >What about the security issues. Setuid functions within a tcl/tk program >are a bit tricky. Also many people don't have room for all the tcl/tk stuff >on disk, its not that tiny - mind you nor is xview. I'm not that familiar with the internals of tcl/tk but it is a very good way of quick prototyping, and looks pretty good. As for space, I just checked: tcl/tk - 735k in /usr/local/tcl, 550k in /lib, 19k in /usr/local/bin. xview - 7381k in /usr/openwin, almost 2M just for headers. It is true that not all of /usr/openwin is required for running binaries. >I'd vote xview > >Alan > -- Zeyd M. Ben-Halim zmbenhal@netcom.com 10479 1/4 Santa Monica Blvd, LA, CA, 90025 (310) 470-0281 ------------------------------ ** 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 ******************************