From: Digestifier To: Linux-Activists@senator-bedfellow.mit.edu Reply-To: Linux-Activists@senator-bedfellow.mit.edu Date: Thu, 26 Aug 93 13:13:16 EDT Subject: Linux-Activists Digest #171 Linux-Activists Digest #171, Volume #6 Thu, 26 Aug 93 13:13:16 EDT Contents: Re: Tractatus Linuxicus Newbius (David Truckenmiller) Help! Can't compile Pine3.07 (Richard Wooden) Linux & StarLAN? (Eric S. Wallace) Help! Hosed my dos partition... (David Gabrius) Problems with ftpd Re: SCSI Performance (Yet (Eric Youngdale) Re: SCSI Performance (Yet Again) (Eric Youngdale) Re: SCSI Performance (Yet Again) (Wolfgang Schelongowski) Re: SCSI Performance (Yet Again) (Wolfgang Schelongowski) Re: SCSI Performance (Yet Again) (Piercarlo Antonio Grandi) Re: lpr cannot connect to lpd - Slackware 1.01 ---------------------------------------------------------------------------- From: trucken@exa.cs.umn.edu (David Truckenmiller) Subject: Re: Tractatus Linuxicus Newbius Date: Thu, 26 Aug 1993 14:29:09 GMT In jkowalik@gandalf (Yarek Kowalik / LGS) writes: >ksh@prl.ufl.edu (Kevin S Ho) writes: >: In article , trucken@milli.cs.umn.edu (David Truckenmiller) writes: >: |> >: |> > I am a philosopher myself, and I really think no one should be allowed >: |> >to wield power over technology who cannot pass a course in literary >: |> >criticism. >: |> OK. >: I don't know if I can pass a course, but since when does literary >: criticism have anything to to with operating systems? >Hear, hear... The pre-previous poster is saying that those who cannot >pass the course in literary criticism should not be allowed to "wield power" >over technology. I would rather argue that those who *do not understand* >technology should *not* wield power over it, and my belief is that there are >more of the later than those of the first. Yes. It is far more dangerous to wield power over that which you don't understand. Worse, those that know a little, are far more dangerous than those who know nothing. My personal belief is that this is why lots of things are screwed up. Before limiting technolgy, it might be wise for "leaders" to try and understand it first. (Soapbox mode off now.) >: |> The point is, this stuff is complicated, and there should be a step-by- >: |> step guide, and mostly there already is for Linux. The techincal jargon >: |> creeps in because that is how we talk. What is needed now is for people >: |> like you that have learned the hard way, but can speak in non-jargonese, >: |> to write manuals. >: The point being that if we don't speak like ourselves, we get really wordy. >: Try learning a foreign language and writing a book in it.......That's hard. >: >I understood from your reply that you cannot communicate ideas about computer >in English without using technical jargon, and so it would be hard for you to >"write a book" in layman English... I don't think it is so difficult. After >all you did write most of your response in tech-less English. And it was about >computers, and it was not too difficult, was it? No, not anymore, but I have been practicing for a very long time. Writing _anything_ takes time, and patience. I'm more and more in awe of anyone who can write an entire book on a subject. It is _much_ easier to simply speak in jargon. Even then, clearly writing something down, even in jargon, is much harder than simply telling someone how it works. Writing is a noble act, and we should encourage those that do it well. >I think that most books for >non-initiated in the Computer Wisardry lack a certain progressive teaching >of the terminology.. Once that terminology is taught, one can get very >precise in their books, and be fairly certain that the reader would >understand... but maybe Computer Science is too young to have a stable >terminology, and besides who would want to read an OS manual for the first >to last page? It is a complex matter, and there are many things that should >be done. Like, why not teach some of the jargon to kids, so when they grow up >it would become an integrated in their language (if it is not already) and >understood that a hard disk is not a floppy in a hard case. Well, I think that kids already know more than we suspect. :-) >If things continue progressing as thy are, which they most likely will, the >gap between those who understand computers and those who do not will become >wider. Yes. >And even in the new generation that gap will remain, even though >people will not be as scared to use them (due to more powerful and easier >to use Operating Sytems), because there will be relatively few people in the >society who will be taught to understand them. Yes, again. Look at radio and televison. Could you tell me precisely how they work? Probably not, (unless you're an EE type), but you use them and their "software" anyway. If you wanted to know more about how a TV set worked, you'd never think of calling up Larry King and complaining that the techies at the TV station speak in too much jargon. You'd go to the library, read a book, maybe take a few courses, and educate yourself about the technology of broadcasting. This doesn't mean that you'll stop using the software, (who could give up the Simpson's? :-/), or that you'd start building a TV set, (though before Heathkit went under, people did), but rather, you'll know more about how it works, and gain new understanding about things you hear about, (like why the Fed's are selling off frequencies). >Personally I look at Linux >as an excercise, a very good one, that will teach me (and many other people) >how to run, make and operate a good system. I will probably teach a lot of us >how to make OS user friendly, be it through good manuals, or other important >ways. Yes. And this is why I like it so much. >Because I think of Linux as being an excercise on a large scale >I think its accessablity to "outsiders" will be limited for a while ( I am >not excluding a possibility that Linux will not go beyond that). Advances >in technology always lag in real life applicatons. Part of the inaccessability to "outsiders", IMHO, is desirable. I mean, after all, we are NOT Larry King. :-)! This is not to say that all outsiders are bad, or that we should hate them. Rather, they have very important things to say, and many times their comments will shape the way we view things, increase our own understanding of a topic, and prod us into productive change. (Not to mention maybe inviting us to a party.) I merely bristle when someone else blames me for not letting me into "our club". I'll point them in the right direction for the knowledge they need to learn. And I'll answer their questions, and get really excited with them when the light bulb clicks on. But I'll never accept the blame that they can't understand because of me. Well, I feel better now. :-) Sorry about all that. Let's see, the sun is shining outside, and it is the first day of the State Fair. Later, I'm outta here! -Dave -- --- Dave Truckenmiller (trucken@cs.umn.edu) [ ASCII picture ] Linux, Linux, Linux, Linux, Linux, Linux. [ under development ] ------------------------------ From: rwooden@access.digex.net (Richard Wooden) Subject: Help! Can't compile Pine3.07 Date: 26 Aug 1993 11:16:13 -0400 I am having alot of trouble compiling Pine3.07. Could someone else with SLS 1.03 tell me what parameter they gave the build command to successfully build Pine? Thanks rwooden@access.digex.net ------------------------------ From: esw@po.CWRU.Edu (Eric S. Wallace) Subject: Linux & StarLAN? Date: 26 Aug 1993 15:22:46 GMT I have an AT&T StarLAN ethernet card. Is there any hope of getting this to work with Linux? I don't know if its a 'clone' of any of the boards listed in the NET FAQ, and my school (who distributed it) seems to know less than I do. Eric Wallace esw@po.cwru.edu ------------------------------ From: gabrius@gem.valpo.edu (David Gabrius) Subject: Help! Hosed my dos partition... Date: 26 Aug 1993 15:27:39 GMT Well, I goofed. Having *never* installed lilo (in the 10 months that I've been running linux), I decided to bite the bullet and with the new SLS 1.03 install set lilo up. I have two drives, /dev/hda1 being the dos partition, /dev/hda2 being OLD linux, /dev/hda3 being swap, and /dev/hdb1 being all 0.99.12a. I tried setting lilo up to allow me to boot dos off of /dev/hda1 and linux off of /dev/hdb1, and it took me several tries. Somewhere during the attempts at installation I hosed /dev/hda1's boot record. 'fdisk /mbr' doesn't work to fix it. The partition table according to dos fdisk says that the /dev/hda1 partition is a primary dos, but the system is UNKNOWN. Help! I have a backup, so I've just got to wait for my SCSI controller to get here, but I want to know if there's any other way to fix it. (Actually, it also made me realize how little I use under DOS now that octave works pretty well and that dosemu is pretty good.) Thanks! -- David Gabrius gabrius@gem.valpo.edu Pro Student, Computer Engineering perfessr@imsa.edu (IMSA '90) "And you can find/Your own way out/You can build/And I can will..." -U2 "You miss too much these days if you stop to think..." -U2 | PGP22 available ------------------------------ From: pramod@radon.ece.uiuc.edu () Subject: Problems with ftpd Date: Thu, 26 Aug 1993 10:55:41 GMT Hi, I was wondering if anyone out there knows why I am having the following problem. It seems that I cannot do a ftp and login to my machine from a remote host. The only login it seems to allow is anonymous. My ftpusers file does not contain any logins for that matter, so it should not prevent login on that basis. I am running kernel pl11 and Net-2. Thanks, Pramod ------------------------------ From: eric@tantalus.nrl.navy.mil (Eric Youngdale) Subject: Re: SCSI Performance (Yet Date: Thu, 26 Aug 1993 16:05:50 GMT In article <1.11636.2381.0N279333@satalink.com> john.will@satalink.com (John Will) writes: >B >On *my* system this won't cause a problem; I only have 12MB. But on a 32MB >B >ISA machine the driver had better check the physical address of the user's >B >buffer and do a copy if it's over 16MB, or things will go BOOM! Not to >B >mention the 64K boundary problem... > >That's only when DMA is being used, and since I have problems with the >current kernel (99pl12) and my Adaptec 1542B when I go over 16mb on my >system, I'd say it wouldn't get much worse. With PIO disk controllers, >like IDE drives, the 16mb boundary doesn't exist. I should point out that you are an isolated case. I have 20Mb and an Adaptec, and I have no trouble. I know other people with memory in the 20-32 Mb range, and it works fine. There us code in the top level drivers to allocate special bounce buffers that are guaranteed to be at addresses < 16Mb for use in DMA I/O, and I have had no indications that this is not working correctly. If you have problems with the Adaptec when going > 16Mb, then I suggest that you check your SIMMS, and make sure that you have them installed correctly. If some of them have different speeds, or they are not seated correctly this could explain part of the problem. The 64Kb boundary problem is not relevant to scsi controllers - all of the supported cards that use DMA use bus mastering DMA, which means that the scsi adapters and not the motherboards drive the address lines, and hence you do not need to worry about the 64Kb boundary problem. -Eric -- "When Gregor Samsa woke up one morning from unsettling dreams, he found himself changed in his bed into a lawyer." ------------------------------ From: eric@tantalus.nrl.navy.mil (Eric Youngdale) Subject: Re: SCSI Performance (Yet Again) Date: Thu, 26 Aug 1993 16:16:27 GMT In article <1993Aug25.181139.17869@swan.pyr> iiitac@swan.pyr (Alan Cox) writes: > >Before people go berserk with wild optimizations the Linux driver doesn't >handle two optimizations it could (at least if it does then Linus has >cleverly concealed it 8-)) > >2. Request merging - Multiple requests can be merged into one > disk operation. This should enable better use to be made of the > DMA potentially. Request merging does take place for requests that are contiguous (i.e. requests to read adjacent sectors on the disk). These merged requests are used in the scsi code by drivers that use DMA by making use of a feature called scatter-gather. -Eric -- "When Gregor Samsa woke up one morning from unsettling dreams, he found himself changed in his bed into a lawyer." ------------------------------ From: ws@xivic.bo.open.de (Wolfgang Schelongowski) Subject: Re: SCSI Performance (Yet Again) Date: Wed, 25 Aug 93 12:04:32 MEST jhenders@jonh.wimsey.bc.ca (John Henders) writes: > ws@xivic.bo.open.de (Wolfgang Schelongowski) writes: > > >How about > > date;dd if=/dev/sda of=/dev/null bs=131072 count=512;date > > A more accurate measure of the scsi code, IMHO, would be to use code > which would use scsi read and write instructions to do real low level > i/o, removing all other variables. That would measure the "bare metal", and most people would find it difficult to do. What I proposed was measuring the "bare metal" plus the lowest level SCSI-driver where everybody can easily get at. Comparing that with the "bare metal" would give some clue where the below mentioned speed is lost. > >That took 69 seconds => 950 KByte/sec for raw I/O. Under BSDI, > >the numbers are 36 seconds on /dev/rsd0a => 1820 KByte/sec. > > >As I'm still running 0.99 pl6 the numbers for Linux may have > >changed (hopefully to the better). Can somebody test it and > >post the results so we have _numbers_ to compare and not > >assumptions ? > > >My System: noname 486/33, AHA1542B, Fuji M2624FA. It makes no > >difference for Linux whether I use async or sync SCSI. > > I ran the above test and got 103 seconds, with a 386/40 and a Maxtor > 120 HD. A test for scsi i/o should not be affaected by processor speed, > should it? No. But I forgot to mention that I have 256KB of CPU/Main-Memory cache. And your drive (its probably called a Maxtor 7120S here) has 15ms access time and only 1536 KByte/sec transfer speed. According to the specs of my drive it can easily saturate the ISA-Bus. And what is your patch-level ? -- Wolfgang Schelongowski ws@xivic.bo.open.de or ...!uunet!Germany.EU.net!xivic.bo.open.de!ws "No matter what the game, no matter what the rules, the same rules apply to both sides." -- Hoyle's Law ------------------------------ From: ws@xivic.bo.open.de (Wolfgang Schelongowski) Subject: Re: SCSI Performance (Yet Again) Date: Wed, 25 Aug 93 12:18:47 MEST bill@yossarian.ucsd.edu (Bill Reynolds) writes: > In article ws@xivic.bo.open.de (Wolfgang Sche > > How about > date;dd if=/dev/sda of=/dev/null bs=131072 count=512;date > (This does only a read, you have to save and restore via dd > if you want to test write. Just be _very_ careful about _where_ > you test ! Maybe you should backup the disk.) > > That took 69 seconds => 950 KByte/sec for raw I/O. Under BSDI, > the numbers are 36 seconds on /dev/rsd0a => 1820 KByte/sec. > > Hmm.. I don't know what my problem is. 486/66 clone AHA1742, 1G > Fujitsu disk, in extended mode with 32M of main memory on an EISA bus, > I get 261s for the above command => 257 KByte/sec. > I'm running Linux yossarian 0.99.11 #3 Tue Jul 6 18:58:52 MDT 1993 i486 > > (Wait a sec, as your humble narrator tries some stuff). > > Ok, the above was done with X and term running (interrupts up the > wazoo!). Killing all extraneous processes, I get 61s => 1100 Kb/sec - > much better! So it's obvious that these benchmarks depend on a lot > more than just disk/bus speed. I did my test without X. I even killed lpd, and the network daemons always show 0:00 on ps ax as this is a standalone machine. But _you_ use an _EISA_ machine with a _1742_ in extended mode and a (supposed) M2694ESA/SA/FA. You should get a much better throughput than a mere 115% of mine. As this group expires soon (probably no longer read by the developers anyway) AND you have a rather up-to-date release 0.99.11 against my 0.99.6 AND a real fast hardware, could you please alert the developers of the SCSI- and SCSI-disk-driver ? They ought to be interested in a possibly 200% speed increase. I'm available for e-mail discussion about this subject until I go on holiday. -- Wolfgang Schelongowski ws@xivic.bo.open.de or ...!uunet!Germany.EU.net!xivic.bo.open.de!ws "No matter what the game, no matter what the rules, the same rules apply to both sides." -- Hoyle's Law ------------------------------ From: pcg@decb.aber.ac.uk (Piercarlo Antonio Grandi) Subject: Re: SCSI Performance (Yet Again) Reply-To: pcg@aber.ac.uk (Piercarlo Grandi) Date: Thu, 26 Aug 1993 16:21:44 GMT On Mon, 23 Aug 1993 01:34:12 GMT, Remco Treffkorn (root@hip-hop.suvl.ca.us) wrote: : Actually one would want to have an idea of how good each of these : components is *in isolation*; : : 1) the generic SCSI code : 2) the HA specific SCSI code : 3) the disk SCSI code : 4) the filesystem code : 5) the cache handling code. Do you volunteer to find out ? ;-) I have been trying, informally -- I am really keen on IO performance. But it's not so easy -- one dos not have the right hooks in the kernel/device drivers. : Also, it is rather useful to observe not only how long (elapsed) the : operations take, but also the system CPU time taken. Yes and no and yes. I think that goes hand in hand. It is like saying you get wet when it rains. It is more interesting than you think. In theory elapsed tiem should be much larger than CPU time, unless the kernel/drivers/cache/filesystem code are poorly written and they also take a lot of CPU time, as in SVR4 or Ultrix. Linux seems, from first impressions, rather leaner than those, and CPU time not such big worry. : that the biggest problems are, in order of decreasing : importance: : a) the filesystems don't do read/write clustering. Iozone does sequential reads/writes. Where is the gain? It makes a lot of difference if the driver can issues a single scatter/gather command to read/write multiple blocks or not. : b) advising for expected access patterns should be : possible/automatic. Right, but sequential writes do not benefit too much from it. No, they would benefit *most* from it. Caches, even buffer caches, tend to use LIFO style policies; sequential is FIFO. Even if read-ahead/write behind are implemented, advising can tune their lengths. I tend to agree with your list in part. I still *feel* that with what there is the performance should be better. Yes, but I think this is not so much a problem with the kernel/drivers as with the policies of cache and filesystem. If I understand you correctly, you are saying the current numbers are as good as they can be, given the current design. My gut feeling is that this is not so. Bah, bah. The numbers I have seen are 'as good as possible'. This is a bit clouded by the fact that raw disk devices are not available. ------------------------------ From: bhv@cycad.ufh.ac.za () Subject: Re: lpr cannot connect to lpd - Slackware 1.01 Reply-To: bhv@cs.ufh.ac.za Date: Thu, 26 Aug 93 15:22:32 GMT bhv@cycad.ufh.ac.za wrote: : I've recently installed Slackware 1.01 and wish to print remotely : via TCP/IP. I've read the FAQ and done everything, but I still : do not get lpr to connect with lpd. Furthermore, when I re-start : lpd (ie. faking a crash), I find that the remote host reports : that my machine is dropping the connection. Once in a blue moon, : tough, the printout gets trough. : Any ideas? : -- : Herman Venter, Dept of Computer Science : University of Fort Hare, Alice, Ciskei I now seem to have fixed the problem: I got the source (lpd-590.tar.gz) and recompiled it, after which lpr/lpd works. So what's up with Slackware :-? -- Herman Venter, Dept of Computer Science University of Fort Hare, Alice, Ciskei ------------------------------ ** 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-Activists-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux) via: Internet: Linux-Activists@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 tupac-amaru.informatik.rwth-aachen.de pub/msdos/replace The current version of Linux is 0.99pl9 released on April 23, 1993 End of Linux-Activists Digest ******************************