From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Wed, 24 Nov 93 20:13:20 EST Subject: Linux-Development Digest #258 Linux-Development Digest #258, Volume #1 Wed, 24 Nov 93 20:13:20 EST Contents: Re: 1542B and DSP3160 bad I/O Performance (Eric Youngdale) Re: WANTED: COBOL compiler (gostling delano javier andres) Re: TCL/Tk vs Motif/C++ or TCL/Tk with C++? (Amancio Hasty Jr) Re: 1542B and DSP3160 bad I/O Performance (Eric Youngdale) console.c questions ("John E. Davis") Linux/68k Version 0.06 released (Hamish Macdonald) Re: Don't use Motif for free sw: it now requires runtime royalties! (Barry Margolin) Re: Linux/68k Version 0.06 released (Marc Duponcheel) Re: corewar (Eric Dumas (Gandalf)) ---------------------------------------------------------------------------- From: eric@tantalus.nrl.navy.mil (Eric Youngdale) Subject: Re: 1542B and DSP3160 bad I/O Performance Date: Wed, 24 Nov 1993 20:41:55 GMT In article hm@seneca.ix.de writes: >RAINER SCHIELE INFORMATIK (81264@novell1.rz.fht-mannheim.de) wrote: >: > 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 > >I have the same problem with the same configuration. However, I suspect that >the slow buffer cache in pre-0.99pl13q (at least) kernels is guilty as well. >As far as the Adaptec is concerned, I think that it should start synchronuous >transfer as soon as the appropriate jumper is set. At least I didn't find any >hint in the ~/scsi-sources. Eric ? The synchronous negotiation is enabled with a jumper that you set on the Adaptec - from what I recall this cannot be set via software, so the kernel does not have anything to do with this part. If my memory is correct, the 1542C can have synchronous negotiation enabled on a device by device basis, while the 1542B would have it enabled for all devices. The reason that it is apparently left turned off on the default configuration is that some devices do not like synchronous negotiation. The upshot is that the data transfers may be slower, but with some configurations the system may be more reliable. I found that my system would hang at boot time with SN enabled, so I have obviously not really studied this very much - I vaguely recall that this had something to do with buggy firmware on one of my scsi devices. Note that even without the synchronous negotiation enabled, the Adaptec can do synchronous transfers, but for this to happen the scsi device itself must initiate the negotiation. I should also point out that the clustering stuff will not appear until sometime after pl14 (I will probably get it to Linus shortly after pl14 appears). Given the radical nature of some of the changes, I would like to have a lengthy testing period so as to make sure that everything is stable on all systems. Also, I would like to modify ext2 to explicitly request clusters when reading files, and I have not gotten around to making the required patches (I was kind of hoping that someone else would get excited enough about this to do it :-). The memory usage patterns that seem to develop in normal usage often lead to clustering anyway, so this has not been a high priority. There has also been discussion about fixing things so that certain dirty disk blocks (inodes, superblocks, and bitmaps) will be written back more frequently so there would be less disk corruption if you had a power failure. This has yet to be fully implemented, but it would be trivial to add on top of the rest of the clustering code. -Eric -- "The woods are lovely, dark and deep. But I have promises to keep, And lines to code before I sleep, And lines to code before I sleep." ------------------------------ Crossposted-To: comp.os.linux.help From: jgostlin@isluga.puc.cl (gostling delano javier andres) Subject: Re: WANTED: COBOL compiler Date: Wed, 24 Nov 1993 21:03:34 GMT (zzassgl@gl.mcc.ac.uk) wrote: : Nick Hilliard (nick@quay.ie) wrote: : > [Book against Pascal] : : It may be a ``devastating attack on the deficiencies of *an old standard* : Pascal''. It says nothing about modern Pascal implementations - and he : particularly mentions how his critisism is restricted to unextended Pascal, : a language that almost nobody uses today. That's exactly what's being said about pascal. To make it worthwhile, you must use non-standard implementations, and that means a BIG decrease in portability. -Javier Gostling D. ------------------------------ Crossposted-To: comp.windows.x,comp.windows.x.motif From: hasty@netcom.com (Amancio Hasty Jr) Subject: Re: TCL/Tk vs Motif/C++ or TCL/Tk with C++? Date: Wed, 24 Nov 1993 20:33:56 GMT On the topic of an object paradigm for tcl/tk: This is from a thread in comp.windows.interviews. Please ignore the stuff about tk vs. interviews and read what Mr Linton has done with tcl. I am including the full message to avoid mis-interpretation on my part. X11R6 is going to fun :) ========start======== In article , hasty@netcom.com (Amancio Hasty Jr) writes: |> Don't forget to send him how long does it take to compile IV apps vs |> Tk, the size of IV apps vs TK and the portability of TK apps. |> On the latter, I have a large script that runs on the sparc or on |> my 386bsd box -- it requires just one line change to specify a |> different path for my "wish", tk's interpreter. Yeah, I can create |> a symbolic link and fix the problem. The large scrip is a mini |> network management platform -- it can do snmp set,get,getnext, |> plot snmp variables, run reqression test, auto-configure a router |> prior to executing a given script, it can alter its basic functionality |> by providing a mechanism to edit primitive snmp operations, presents |> the snmp mib tree as a menu. You are not making a relevant comparison. The fast turnaround and interpretation of scripts comes from Tcl, not Tk. Several people have interfaced Tcl to InterViews. In Fresco, we have connected Tcl to the dynamic invocation mechanism in CORBA so that any class can be created and manipulated without manual registry of Tcl commands. This approach should work for other scripting languages as well. ============end message =========== Enjoy, Amancio -- This message brought to you by the letters X and S and the number 3 Amancio Hasty | Home: (415) 495-3046 | ftp-site depository of all my work: e-mail hasty@netcom.com | sunvis.rtpnc.epa.gov:/pub/386bsd/X ------------------------------ From: eric@tantalus.nrl.navy.mil (Eric Youngdale) Subject: Re: 1542B and DSP3160 bad I/O Performance Date: Wed, 24 Nov 1993 21:28:22 GMT In article <1993Nov24.160443.2278@pe1chl.ampr.org> rob@pe1chl.ampr.org (Rob Janssen) writes: >In pcg@aber.ac.uk (Piercarlo Grandi) writes: >>Eric Youngdale has done some real coding; the real research was done >>well over thirty years ago. It was (re)discussed recently in >>comp.arch.storage. Do you want a repost of that thread? (I am going to >>get it from my home archive for some guy who wants a copy...). Err, yes. I would have had substantially different interests back when the real research was done. It depends upon how much over 30 years ago this all took place, but at best all I would have been interested in would have been things like stuffed toys and cartoons (-:. >Well, I did not mean to say that Eric did the research on clustering in >general. >I heard that IDE drives were faster than what I found for my SCSI drive >under Linux, and my setup was a lot faster under DOS as well. Therefore, >I asked if there could be a problem with the SCSI drivers on Linux. That >turned out to be a FAQ, and Eric had written a benchmark program that >proved (by reading large chunks directly through the driver) that the >driver was not the performance bottleneck. Indeed. With a DEC DSP 5400, a BT445S and a 486/66, someone has reported data rates as high as 5.388 Mb/sec when reading the same data over and over again from the cache on the disk. The rate drops to about 3.2Mb/sec - 4.5Mb/sec if you are constantly reading different blocks so as to force the disk to actually read something from the medium. The lower numbers are on cylinders with fewer sectors per track where one would expect a lower data throughput. >Apparently not satisfied with that, he proceeded to research the case, and >found that because of unfortunate memory allocation effects, the driver was >always asked to transfer (one or more) 1K blocks, even when full 4K blocks >were being read to memory. He fixed that, and the performance increased >notably. Yes, now get numbers like 1.2 - 1.4Mb/sec with my disk (the theoretical maximum based upon the srawread numbers is more like 1.7Mb/sec). Other people with VLB/EISA boards have reported numbers in excess of 2.0Mb/sec. I am not entirely sure where all of the remaining overhead lies, but I suspect that it is just the cululative delay built in by all of the things that the buffer cache/filesystem does. I have given thought to try and streamline this a bit so that in principle clustering would require less overhead, but this could add overhead in other places, so I am not sure that it is worth the trouble. One of these days, I will run a user-mode simulation with profiling so that I can try and identify any remaining bottlenecks. >Forgive me if the term "research" to find the cause of a problem with a >running system is inappropriate, and is associated with "fundamental >research" only. What would be the English term to use instead? I can >hardly think it is called "coding", I would assume that is the term for >implementing the changes that improve things after you have done "research". It was a bit more than just coding. I actually have spent some time with simulations of the buffer cache and I identified some bottlenecks there as well. The bdflush daemon was written to address some of these problems, but it was not required by the clustering modifications. I do appreciate that the original work was undoubtably more thorough. -Eric -- "The woods are lovely, dark and deep. But I have promises to keep, And lines to code before I sleep, And lines to code before I sleep." ------------------------------ From: davis@pacific.mps.ohio-state.edu ("John E. Davis") Subject: console.c questions Reply-To: davis@pacific.mps.ohio-state.edu (John E. Davis) Date: Wed, 24 Nov 1993 22:04:20 GMT Hi, I just discovered from going through the console driver code kernel sources that ^[[0m resets the terminal colors. Is this a good idea? Whenever I login in to a remote system and an ESC [ m is received, the colors go back to black and white. I would prefer it it ESC [ m just turns off highlighting/bold/underlining and leaves the colors alone. Finally, it would be nice to have AL and DL termcap capibilities in the console. (These insert and delete multiple lines). I believe something like ^[[%dL works but it does not work well. FInally, I have noticed that ^[[K (erase to end of line) sometimes fails. Any thoughts? -- _____________ #___/John E. Davis\_________________________________________________________ # # internet: davis@amy.tch.harvard.edu # bitnet: davis@ohstpy # office: 617-735-6746 # ------------------------------ From: Hamish.Macdonald@bnr.ca (Hamish Macdonald) Crossposted-To: comp.unix.amiga Subject: Linux/68k Version 0.06 released Date: 24 Nov 1993 22:06:20 GMT This message announces the availability of version 0.06 of Linux/68k. It can be ftped from directory /pub/linux/680x0 at tsx-11.mit.edu. A precompiled kernel executable and the Amiga "bootstrap" program can be found in kern-0.06.tar.gz in the "kernel" subdirectory. The kernel source can be found in linux-0.06.tar.gz in the "src" subdirectory. Compilation of this new version of the kernel requires gas-2.2. Minor changes to the stock gas-2.2 distribution were required in order to generate an m68k-linux assembler. The patches for these changes are available in the "tools" subdirectory. The new features of this release over 0.05 include: *) A number of bug fixes. *) linux/386 patches up to 0.99pl13 applied. *) A memory management rewrite supporting the following new features: 1) 68040 support. I've made the changes that I think are required in order to support the 68040. *I am unable to test these, so I'll have to leave it up to someone else with an '040 to test them*, and notify me of problems/changes required.. 2) Multiple non-contiguous memory chunks (Linux will now use all the FAST memory on an Amiga). * 68040 Floating Point Support Package incorporated. This release still contains only support for the Amiga. Hopefully the people working on MacIntosh and Atari support will have some sources for inclusion soon. Again, note that the 68040 changes need debugging. Please let me know if this kernel runs on your Amiga, and the type of Amiga and cards/peripherals you have. The compressed minix file system in the "filesys" directory can be used as a ram disk to boot with the kernel, or can be copied to a floppy or SCSI hard disk. To boot the kernel on an Amiga, use the supplied "bootstrap" command. To boot with the ram disk image, uncompress the file system image and type: bootstrap -r filesys To boot from a floppy image, uncompress the file system image and copy it to an Amiga format floppy. This can be done using the "flat:" handler. Then type: bootstrap If you somehow have a linux/68k minix file system on a SCSI hard disk partition, you can boot from the partition by supplying the device number to the bootstrap program: bootstrap -b [number] The major number for SCSI disks is "0x08", and the minor number depends on the disk and partition. linux/68k searches for SCSI disks from target 0 to target 7, and for Logical Units 0 through 7 on each target. The minor number can be calculated by (disk_number)*16 + partition_number. The first disk found is disk 0. Partition 0 is the whole disk. Partition 1 is the first partition found in the RigidDiskBlock partition table on the Amiga hard disk. Thus 0x0801 is the first partition on the first disk found. 0x0818 is the second partition on the second hard disk found. For example, I have two SCSI hard disks. The first is at target 5, LUN 0 and the second at target 6, LUN 0. The first has three partitions, used for Linux and the second has 4 partitions used for AmigaDOS. Thus I have: devnum linux device name ------ ------------------------------------ 0x0800 sda (the entire disk at target 5 : BE CAREFUL) 0x0801 sda1 (1st partition on disk at target 5) 0x0802 sda2 (2nd partition on disk at target 5) 0x0803 sda3 (3rd partition on disk at target 5) 0x0810 sdb (the entire disk at target 6 : BE CAREFUL) 0x0811 sdb1 (1st partition on disk at target 6) 0x0812 sdb2 (2nd partition on disk at target 6) 0x0813 sdb3 (3rd partition on disk at target 6) 0x0814 sdb4 (4th partition on disk at target 6) My Linux root partition is on the 2nd partition of my first drive, so I boot with: bootstrap -b 0x0802 After booting from one of the above methods, if the kernel supports your SCSI driver, you should be able to create a minix file system on one of your hard disk partitions if you wish. Determine the size of your partition in 1K blocks (take the number of 512 byte sectors from HDToolBox and divide by two), and determine which special file to use in /dev (see above). *DOUBLE CHECK* that the major/minor numbers for the special device (ls -l /dev/xxx) are correct. If they are incorrect or the device special file doesn't exist, use mknod to change or create the device special file. Then execute: /etc/mkfs /dev/xxxx size This will create a minix file system on the hard disk partition. You can then mount this partition under /mnt and copy files to it: /etc/mount /dev/xxxx /mnt When finished copying, unmount the partition: /etc/umount /mnt sync a few times, and then reboot. You can then boot the kernel by providing "bootstrap" with the device number to boot from. Again, you do any mucking around with hard disks at your OWN RISK. I bought a separate hard disk to use solely for linux before I began playing with hard disk drivers and file systems for safety purposes. DEBUGGING NOTE: The early stages of the kernel startup will send out characters to the serial port to indicate how far it gets. The serial port is set to 9600 baud, 8 bits, one stop bit. You'll need a NULL modem to hook it up to a terminal. The code should assert DTR. ------------------------------ From: barmar@think.com (Barry Margolin) Crossposted-To: comp.windows.x,comp.windows.x.i386unix,comp.windows.x.motif,gnu.misc.discuss,comp.sources.d Subject: Re: Don't use Motif for free sw: it now requires runtime royalties! Date: 24 Nov 1993 22:39:16 GMT In article mjr@syl.dl.nec.com (Matt Ranney) writes: >mkl@rob.cs.tu-bs.de (Mario Klebsch DG1AM) writes: >>But please don't forget that these staticaly linked executables do >>not only need more space on disk, but also need more virtual memory >>when executiing. And this means a lot more swapping, if the user does > >Do they really? How much more? I thought that the only difference in >memory usage between using shared and static libs was roughly the size >of the .sa file. Is this incorrect? Yes and no. You're correct if you're just talking about multiple processes running the same program. They'll share all the same text pages in both the shared and non-shared library cases. The savings comes when you run multiple programs that use the same shared library. In the non-shared case, each program will have its own copy of the libraries in virtual memory, and they'll be paging against each other, reducing performance. With shared libraries, all these processes would map the same libraries into their address spaces, and there will be less contention for main memory. -- Barry Margolin System Manager, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar ------------------------------ From: marc@offline.be (Marc Duponcheel) Crossposted-To: comp.unix.amiga Subject: Re: Linux/68k Version 0.06 released Date: 25 Nov 93 00:00:19 GMT In article <2d0lss$kok@bmerha64.bnr.ca> Hamish.Macdonald@bnr.ca (Hamish Macdonald) writes: > *) A memory management rewrite supporting the following new features: > 1) 68040 support. > > * 68040 Floating Point Support Package incorporated. If someone gets Linux running on a A4000/40 *please* post to this group ! -- marc. ################################################################################ email preferred address marc@offline.be [= me@home] aka marc@offline.UUCP ub4b!offline!marc offline!marc if [me@home] fails mdu@abacus.be [= me@brussels.work] or mdp@cimad.be [= me@antwerp.work] fido 2:292/603.26 Marc.Duponcheel@p26.f603.n292.z2.FidoNet.Org [= me@home] bix mduponcheel mduponcheel@BIX.com [= me@home] ################################################################################ ------------------------------ From: dumas@taliesin.emi.u-bordeaux.fr (Eric Dumas (Gandalf)) Subject: Re: corewar Date: Wed, 24 Nov 1993 14:35:55 GMT Version Francaise : Meme chose : tout sur ce que vous avez sur les corewares serait la bienvenue dans ma boite aux lettres... English Version : Same thing : all you've got about corewares is welcome on my mailbox... Merci..................................Thank You (Un probleme de langage dites-vous ? Is it any language problem ?) -- |------------------------------------------------------------| | __ Eric DUMAS | | / \ dumas@taliesin.emi.u-bordeaux.fr | | | ___ | | \__| andalf -- Licence informatique - Bordeaux | | This is a Wizard Production ! | |------------------------------------------------------------| ------------------------------ ** 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 ******************************