From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Sat, 20 Nov 93 10:13:10 EST Subject: Linux-Development Digest #241 Linux-Development Digest #241, Volume #1 Sat, 20 Nov 93 10:13:10 EST Contents: Re: Thought... (Richard Watts) Re: How many BogoMips on a Pentium? (Robert Stockmann) Re: Some ideas and reasons for a more modular kernel. (Kevin Brown) Re: No core dumped? (Kevin Brown) Re: How many BogoMips on a Pentium? (Harald Milz) Re: Don't use Motif for free sw: it now requires runtime royalties! (Amancio Hasty Jr) Re: olvwm for linux? (Terry Dawson) Re: Thought... (Matthew S. Crocker) Re: Don't use Motif for free sw: it now requires runtime royalties! (Piercarlo Grandi) Always IN-2000 abort after kernel load. BIOS error? (XonTech) Re: Thought... (Just a fellow traveller...) ---------------------------------------------------------------------------- From: rrw1000@cl.cam.ac.uk (Richard Watts) Subject: Re: Thought... Reply-To: rrw1000@hermes.cam.ac.uk Date: Fri, 19 Nov 1993 15:16:58 GMT In article <2cif2g$ikc@trane.uninett.no>, hta@uninett.no (Harald T. Alvestrand) writes: |> |> Funny you should say that while I am listening to the mbone broadcast |> on my SUN (another non-realtime OS). |> Most UNIX variants on most CPUs have power enough to do this with no |> real problems. I haven't niced up my applications, so the sound drops out |> for a few tenths of a second every time I start heavy disk activity, but |> otherwise, it works nicely. However, I did go on to say that you might get away with it if you had enough CPU time and your ethernet happened to be quick enough. This will mostly be true for small systems on fairly fast networks - you can even get mpegs working quite well on the CL's DECstations on occasions (ie. the middle of the night!). Now try playing an audio file whilst running three or four compilations, an mpeg, and editing a file in emacs - a real-time OS would probably either do it or return a 'scheduler can't comply' error or warning - UNIX will just slow down, breaking the audio and video streams. You can do this kind of thing under UNIX, and you will usually get away with it under low system load, but to rely on it working is not advisable at peak times - on my machine, at least (*)! A BBC micro or an Archimedes running RISCOS, which provides (essentially) non-preemptable single-tasking would be better for this - MS-DOS would at least be reliable (inasmuch as you can call MS-DOS reliable!). Of course, you'd also have to use some kind of reliable network, such as a direct ethernet connection between the two machines (ie. with nothing else using the net) if there was a possibility of network slowdown :-). That said, I was answering a question the poster hadn't asked - sorry! |> [.sig deleted] Richard. (*) my normal working evironment spends most of its time swapping between gcc, X and emacs :-(. Free 16Mb RAM cards gratefully recieved :-). -- nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn lllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm [Ruler ^^^. -- blame xrn ] ------------------------------ From: stock@dutsh7.tudelft.nl (Robert Stockmann) Subject: Re: How many BogoMips on a Pentium? Date: Sat, 20 Nov 1993 06:19:06 GMT hm@seneca.ix.de (Harald Milz) writes: >Frank Lofaro (ftlofaro@unlv.edu) wrote: >: > In article hpasanen@cs.hut.fi (Harri Pasanen) writes: >: > > >: > >If you have booted Linux on a Pentium machine, how many BogoMips did you >: > >get? >: > > >: > This begs the question, does Linux even boot on a Pentium? >Yes, it does, and pleeze don't start this discussion again. Hunting Bogomipses >was widely discussed on c.o.l.m., I think, some weeks ago, and wasted a >considerable bandwidth. Ok but if its concerning pentium's i'm very interested! So if linux does boot on your pentium hot rod, then why don't you give us your Bogo Mips number. I expect it to be the same number as a 486 DX2 66 MHz (35.5 or so). But of course no shame to linus, because at the moment there's even no commercial OS on the market that boost's the power of the pentium. So we just have to wait for the 100 MHz version to get 51.5 or something like that reported as the new record. Robert stockmann ------------------------------ From: kevin@frobozz.sccsi.com (Kevin Brown) Subject: Re: Some ideas and reasons for a more modular kernel. Date: Fri, 19 Nov 1993 21:16:38 GMT In article <2cgu5u$90q@access1.speedway.net> pats@speedway.net (Pat Spinler) writes: [...] >There are at least a few systems out there which seem to have >implemented loadable drivers successfully. Can anyone comment on >QNX's or MACH's loadable devices ? I don't know about those, but a loadable device drivers package does exist for Linux. It's called "modules" and can be found on tsx-11.mit.edu in the directory /pub/linux/ALPHA/QIC-80. >Pat Spinler "Life ? Life is a crock. >pats@speedway.net,pspinler@mr.net You're born, you die, and you're >Work: 505/893-4655 Home: 505/294-5923 lonely a lot in between." -- Kevin Brown kevin@frobozz.sccsi.com This is your .signature virus: < begin 644 .signature (9V]T8VAA(0K0z end > This is your .signature virus on drugs: <> Any questions? ------------------------------ Crossposted-To: comp.os.linux.admin From: kevin@frobozz.sccsi.com (Kevin Brown) Subject: Re: No core dumped? Date: Fri, 19 Nov 1993 22:25:28 GMT In article <2cgic0$nq4@fbi-news.informatik.uni-dortmund.de> muenx@heike.informatik.uni-dortmund.de (Holger Muenx) writes: > >Guten Tag! > >During a major upgrade session on weekend I installed the kernel 0.99.13 and >libs 4.4.4. Everything seems to work fine, except the fact that programs >refuse to dump core. > >That's good news, you say. > >Not really: Those programs are buggy and cause segmentation faults and other >nasty problems. After a segmentation fault I do not find a "core" or >"core." file anywhere. Moreoever, in the message "Segmentation >fault" the usual "core dumped" is omitted. > >Does anybody else experience that problem? How can I get rid of it? It would seem that the core size limit now defaults to zero. In order to fix this, you need to put "ulimit -c " in your /etc/profile (if you're using bash) or the equivalent command for your shell in whatever place would be appropriate. Since the core size limit is a per-process value, I know of no way to change it on a system-wide basis other than by hacking the kernel or hacking init. -- Kevin Brown kevin@frobozz.sccsi.com This is your .signature virus: < begin 644 .signature (9V]T8VAA(0K0z end > This is your .signature virus on drugs: <> Any questions? ------------------------------ From: hm@seneca.ix.de (Harald Milz) Subject: Re: How many BogoMips on a Pentium? Date: Thu, 18 Nov 1993 16:04:11 GMT Reply-To: hm@seneca.ix.de Frank Lofaro (ftlofaro@unlv.edu) wrote: : > In article hpasanen@cs.hut.fi (Harri Pasanen) writes: : > > : > >If you have booted Linux on a Pentium machine, how many BogoMips did you : > >get? : > > : > This begs the question, does Linux even boot on a Pentium? Yes, it does, and pleeze don't start this discussion again. Hunting Bogomipses was widely discussed on c.o.l.m., I think, some weeks ago, and wasted a considerable bandwidth. Ciao, hm -- Harald Milz (hm@seneca.ix.de) ------------------------------ Crossposted-To: comp.windows.x,comp.windows.x.i386unix,comp.windows.x.motif,gnu.misc.discuss,comp.sources.d From: hasty@netcom.com (Amancio Hasty Jr) Subject: Re: Don't use Motif for free sw: it now requires runtime royalties! Date: Fri, 19 Nov 1993 23:23:40 GMT In article mjr@syl.dl.nec.com (Matt Ranney) writes: >rick@digibd.digibd.com (Rick Richardson) writes: > >>Statically linked Motif binaries are simply too large to be of much value. > >Tell that to the thousands of people who run the static binary of >NCSA's Mosaic for X on their Suns. >-- Yeah, but all they have to do is target a few individuals to set an example which can start a "Net" panic and down the drain goes XMosaic... Good Luck because you are going to need it, 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: terryd@extro.ucc.su.OZ.AU (Terry Dawson) Subject: Re: olvwm for linux? Date: Sat, 20 Nov 1993 00:37:25 GMT clark@ist.flinders.edu.au (Steven R Clark) writes: >In article 30i@news.ysu.edu, ai539@yfn.ysu.edu (Kent Fox) writes: >> >>Has anyone recompiled olvwm for a modern linux kernel/gcc/XFree86? >>I'm having problems in slave.c ... and can't seem to trackdown >>getrlimit() or RLIMIT_NOFILE. Any help would be appreciated. >> >> Pat Eyler >> pate@cpu.us.dynix.com >My effort bombed out before that, still tracking down the problem. If you get the >thing to compile, perhaps you could put it on sunsite (some hints in a text file on >how you got it to compile might be a good idea too - I'd be interested anyway) Try including and changing RLIMIT_NOFILE to NOFILE. Oh, and use -DSYSV in the CFLAGS. I assumed it was just a definei for the maximum number of files that could be opened, I didn't check real hard, but I've used the binary that I compiled as a result for months without a problem. Terry -- --- Terry Dawson, terryd@extro.ucc.su.oz.au ------------------------------ From: mcrocker@twain.ucs.umass.edu (Matthew S. Crocker) Subject: Re: Thought... Date: 19 Nov 1993 20:35:14 -0500 >Ethernet really provides more than enough bandwidth for even multiple >simultaneous bi-directional audio streams. Unless you want to transmit CD >quality sound today, 11Khz is more than acceptable for voice communication. anything over 8kHz for voice is overkill, unless your sucking helium (see below)... >I'm pretty sure ITR uses an 11khz sample rate. Even the slowest ethernet >around runs at about 2Mbps. You only need about 4kbps for half duplex >voice communication, 8kbps for full duplex, and this is without any super >fancy codecs, although I think ADPCM is probably warranted. Most ethernet >that has been installed in the last several years runs at 10Mbps, and gives >you even more bandwidth. Summary: just about any ethernet will do. Even >on systems with alot of traffic, you can usually grab 4kbps worth of bandwidth >and if you can't, the network needs to be upgraded. Now if you can't because >one hundred people are doing bidirectional voice over your physical layer, >that's another matter entirely. :) > Hey, who needs Ma Bell? lets just talk over our modems and the internet :) Toll-Free? Well, I guess I'll have to post again... seems I answered this a while ago but it never appeared on the net :( 11Khz is very very very good audio, we don't need that. I think that the goal should be *understandable* speech over the net and that shouldn't be too hard. Now for the class: 8Khz is what the Telephone company uses in its *entire* digital transmission and it is what makes up the basic building blocks for the network. 8k * 8 Bit = 64000 bps which is standard 'toll-quality' "hear a pin drop" audio, We can get away with much less. We will be transmitting speech over the net not music so you need to think of frequency ranges of human speech. I believe (don't have the book in front of me) that human speech is ~300hz - 4kHz, now in order to digitize ananlog accuratly you need 2x(max Hz) sampling rate, anything more than that is overkill so 4kHz * 2 = 8K samples (Telco...) I have heard 16000bps audio before and it is understandable with a nasty echo, I can deal with it, I think most people can. In order to get 16kbps you need to cut the sampling rate and the bits sampled in half (4kx4) this will accuratly reproduce 2kHz audio which is a little higher than most Male voices, This will *not* affect Male voices too much, Female voices will on the other hand go down the tubes. I think the sampling rate should be adjustable. Now, I think UDP packets will work, they have alot less overhead and we don't really need the packets at the same time, frame slipping (packets out of order) sounds like static to the ear, it will kill a modem but voice doesn't matter too much. As long as we can get the packets lined up ok, If it becomes a problem I think we can add a 32-bit packet counter and have the receiving end hold onto an early packet for a second to see if one that belongs before it will come in. I have know idea how big the buffer is for a Sound Blaster (tm) but I will assume 1k , we therefore would need to send 1k packets 16 times a second. I think a CPU can handle this and the network can definatly handle it (you can send 155 Toll quality voice channels on 1 10 mb ethernet). I think we should set up a bufferin size optimal to the network transport layer (1k, 4k) in linux and buffer the incoming packets. I don;t see any reason why linux couldn't handle 16k/s through the net. Now, If we had a sound card that did compression -or- added some sort of huffman-encoding or fractal compression scheme in the process we could boost the sampling/bit rate and still not affect performance. Remember 16k is *not* that bad at all, it is understandable... -Hope this helps, If you want any more help let me know... -Matt/2 -- -Matthew S Crocker "The mask, given time, comes mcrocker@twain.ucs.umass.edu to be the face itself." -anonymous *OS/2*OS/2*OS/2*OS/2*OS/2*OS/2*OS/2*OS/2*OS/2*OS/2*OS/2*OS/2*OS/2*OS/2*OS/2* *linux*linux*linux*linux*linux*linux*linux*linux*linux*linux*linux*linux* ------------------------------ Crossposted-To: comp.windows.x,comp.windows.x.i386unix,comp.windows.x.motif,gnu.misc.discuss,comp.sources.d From: pcg@aber.ac.uk (Piercarlo Grandi) Subject: Re: Don't use Motif for free sw: it now requires runtime royalties! Reply-To: pcg@aber.ac.uk (Piercarlo Grandi) Date: Fri, 19 Nov 1993 16:03:43 GMT >>> On Thu, 18 Nov 1993 21:56:50 GMT, pcg@aber.ac.uk (Piercarlo Grandi) >>> said: pcg> What I understand is that up until 1.1.x the OSF implementation of pcg> Motif did not require runtime royalties; [ ... ] since 1.2.x a pcg> royalty is due for each copy of a program containing OSF Motif pcg> object code; static linking no longer exempts from the royalty. I have received informal confirmation as to this, from some OSF guy and from an OSF licensee that has consulted his company's legal/marketing people. As of 1.2.x statically or dynamically linked binaries using the OSF/Motif libraries involve the payment of a royalty to OSF, in all cases, without exception. There are two ways to pay such royalty: the end user pays it by purchasing his/her own copy of the OSF/Motif runtime package, or the developer distributing the binary pays it for each copy included in the binaries distributed. For most commercial OSes the 1.2.x runtime libraries (and royalty) are bundled in the cost of the OS license, so the developer need not pay the royalty again; thus a developer need pay a royalty only for every copy of an OSF/Motif application that is distributed for an OS (like any free OS) for which an OSF/Motif runtime license is not bundled in, or if they don't have proof that the user has purchased their own copy of the OSF/Motif runtime. If the end user has not paid the runtime royalty either by buying it bundled with the OS or by buying it separately, the developer may avoid paying the royalty only by continuing to use the 1.1.x libraries. Which is what I had written in my original article in a more succinct form, BTW. ------------------------------ From: xontech@nic.cerf.net (XonTech) Subject: Always IN-2000 abort after kernel load. BIOS error? Date: 19 Nov 1993 16:32:51 GMT I am currently using an Always IN-2000 SCSI controller with an AppleCD 300 to try to install the Yggdrasil CD distribution. After loading linux, it sees the IN-2000, configures it for, say, IRQ 15 and port 0x200. Following an IN-2000 prompt it says IN2000 abort and the screen fills with garbage. I have heard that IN-2000 has recently upgraded their BIOS and perhaps I have an older card. Does anyone have any suggestions? Incidentally booting from zImage in tsx-11.mit.edu:/pub/linux/ALPHA/scsi/in2000 gives the same error as the Yggdrasil boot disk. Flipping dip switches to change IRQs and ports hasn't helped yet either, although I haven't tried all possible configurations. Thanks for any and all help! Mark Reeve ------------------------------ From: jedubins@unix.amherst.edu (Just a fellow traveller...) Subject: Re: Thought... Date: 19 Nov 1993 12:15:38 -0500 Richard Watts (rrw1000@cl.cam.ac.uk) wrote: : In article <2cif2g$ikc@trane.uninett.no>, hta@uninett.no (Harald T. Alvestrand) writes: : |> : |> Funny you should say that while I am listening to the mbone broadcast : |> on my SUN (another non-realtime OS). : |> Most UNIX variants on most CPUs have power enough to do this with no : |> real problems. I haven't niced up my applications, so the sound drops out : |> for a few tenths of a second every time I start heavy disk activity, but : |> otherwise, it works nicely. : However, I did go on to say that you might get away with it if you had enough : CPU time and your ethernet happened to be quick enough. This will mostly be : MS-DOS would at least be reliable (inasmuch as you can call MS-DOS reliable!). Actually I think what you said was: > ... this kind of thing requires real-time guaranteed network and OS > performance. Fine - there are OSs and networks that will do this, and very > nice they are too. > Sadly UNIX isn't one of them, and neither is ethernet. Ethernet really provides more than enough bandwidth for even multiple simultaneous bi-directional audio streams. Unless you want to transmit CD quality sound today, 11Khz is more than acceptable for voice communication. I'm pretty sure ITR uses an 11khz sample rate. Even the slowest ethernet around runs at about 2Mbps. You only need about 4kbps for half duplex voice communication, 8kbps for full duplex, and this is without any super fancy codecs, although I think ADPCM is probably warranted. Most ethernet that has been installed in the last several years runs at 10Mbps, and gives you even more bandwidth. Summary: just about any ethernet will do. Even on systems with alot of traffic, you can usually grab 4kbps worth of bandwidth and if you can't, the network needs to be upgraded. Now if you can't because one hundred people are doing bidirectional voice over your physical layer, that's another matter entirely. :) The only reason you would ever need to use a real-time OS for something like this was if you absolutely, positively couldn't have one bit of data out of a meg worth of data come in one second later than it was supposed to. I don't think anybody was asking that question, except maybe you. My ears just aren't that good to sense a one bit difference in a sample a couple of minutes in length. :) : Of course, you'd also have to use some kind of reliable network, such as a : direct ethernet connection between the two machines (ie. with nothing else : using the net) if there was a possibility of network slowdown :-). It's interesting that you say this, as before you stated that you didn't think ethernet was capable enough(passage quoted earlier). : That said, I was answering a question the poster hadn't asked - sorry! : |> [.sig deleted] : Richard. : (*) my normal working evironment spends most of its time swapping between : gcc, X and emacs :-(. Free 16Mb RAM cards gratefully recieved :-). : -- : nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn : lllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll : mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm : [Ruler ^^^. : -- blame xrn ] Now biderectional video _and_ audio? I don't know, haven't thought about it too much, but I think that would be more of an I/O bus limitation on most machines than a limit of the physical network- or UNIX. An OS can't grant a machine with more abilities than it is physically capable of. :) Full screen bidirectional near-lossless video and audio. Hmmm. :) You might need one hell of a CODEC, and apparently the IETF is testing it. The CODEC is really needed not so to provide the capability that one such session could exist over 10MB ethernet, with low traffic, but that multiple such sessions could be running, and you could run bidirectional video and audio over _2Mbps_ ethernet, with the proper codec of course. Jim ------------------------------ ** 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 ******************************