Subject: Linux-Development Digest #764
From: Digestifier <Linux-Development-Request@senator-bedfellow.MIT.EDU>
To: Linux-Development@senator-bedfellow.MIT.EDU
Reply-To: Linux-Development@senator-bedfellow.MIT.EDU
Date:     Fri, 27 May 94 11:13:08 EDT

Linux-Development Digest #764, Volume #1         Fri, 27 May 94 11:13:08 EDT

Contents:
  Re: 8k nfs performance (Alan Cox)
  Re: Video Blaster (Alan Cox)
  Re: 8k nfs performance (Heiko Herold)
  Re: bug in 1.1.15 (Matthew Dillon)
  Re: Linux/SCO compatibility? (olav woelfelschneider)
  Re: script to implement ``dump levels'' (was Re: Anybody working on BSD dump porting?) (Rob Janssen)
  Re: can Linux notify w/ SIGIO or SIGPOLL??? (Rob Janssen)
  Re: How to print faster (Rob Janssen)
  Re: Symmetric Multiprocessing for Linux? (Rob Janssen)
  Re: Symmetric Multiprocessing for Linux? (Timothy Cullip)
  Re: Symmetric Multiprocessing for Linux? (Thomas Dunbar)
  Re: 8k nfs performance (Kirk Reiser)
  Kudos -- CPU speed and load (Samson H. Lee)
  Why is my Emacs binary so big (2.2M) (Michael MNUK)
  Re: 1.1.15 breaks SCSI (Harald Milz)
  Re: PROBLEM: bad serial I/O (Mark Lord)
  Re: Skinny Dip (lilo (SpRiNg 94 GpA 3.64))
  Re: SIGHUP - Where do we go from here? (lilo (SpRiNg 94 GpA 3.64))
  Svgalib with ati vga wonder XL24 (Mitchell Diamond)

----------------------------------------------------------------------------

From: iiitac@uk.ac.swan.pyr (Alan Cox)
Subject: Re: 8k nfs performance
Date: Thu, 26 May 1994 13:46:25 GMT

In article <2s0q88$fei@galaxy.ucr.edu> cvarner@corsa.ucr.edu (Curtis Varner) writes:
>       The way these experiments were run was by dd'ing a file from
>an nfs-mounted directory (size = 1311748 bytes) sending the file to 
>/dev/null, and timing how long it took to receive the file.  I am in

Try the other way.. Linux to Sun the other way should be more than 
doubled on write

Alan


------------------------------

From: iiitac@uk.ac.swan.pyr (Alan Cox)
Subject: Re: Video Blaster
Date: Thu, 26 May 1994 13:51:47 GMT

In article <k5Vwmc1w165w@bentek.mese.com> bra@bentek.mese.com (Ben Adams) writes:
>valliant@unm.edu (Denny Valliant) writes:
>
>>      Has anyone written anything for the video blaster.  I have drivers for
>> DOS, but have not been able to find anything for Linux.  When I try to run th
>> driver in DosEmu, it tells me that it is already installed.  If anyone has se
>> anything out there, please mail me.
>
>It would seem that a interface for video overlay cards should be 
>setup.  Then the video blaster and other video overlay cards could
>have drivers developed.   BTW I have a Video blaster also...

Nothing stops you writing a video blaster driver now - assuming you can 
obtain suitable programming specifications. It'll probably need to work as
a character device which can be read to read the frame buffer, possibly written
and has ioctls for moving the 'overlay' window around. It probably is a good
idea to make the ioctl() calls generic in case someone wants to do a driver
for a different overlay card. All you really then need as an X application
that includes a blank canvas to drop the picture into and which when moved
by the window manager moves the tv picture to follow it.

Alan




------------------------------

From: hman@arianna.dei.unipd.it (Heiko Herold)
Subject: Re: 8k nfs performance
Date: 27 May 1994 10:24:37 GMT

In article <2s0q88$fei@galaxy.ucr.edu>,
Curtis Varner <cvarner@corsa.ucr.edu> wrote:
>Hello Everyone,
>
>       I just compiled 1.1.13, the first kernel to have the 8k nfs
>and I thought I would post a few timings I made.  A friend of mine,
>Mike Griffith in the CS dept. here at UCR had related to me that
>Sun-to-linux nfs had speeded up quite a bit with the 8k nfs, but did
>not know what linux-to-linux performance increase, if any, there
>would be. 
[...]

Hmm I took the sources of the 1.1.13 kernel, and patched it up to 15.
make dep ; make clean ; make ...
now I've got about 127kb/sec reading (yeah, cheap WD card, same
subnet), BUT writing on the nfs partition still stops about at 16 kb/sec.

Is this normal (syncronous (sp?) writing?) or am I doing something wrong ?
Should I stick with the 1.1.13 kernel instead ?
Oh, another thing: I used the ide20.patch, too, but this should not be
the problem: in the meantime I tried the same kernel without the ide20
patches, same thing...fast read, slow write.

Heiko Herold

-- 
\________________/ hman@[paola][chiara][maya].dei.unipd.it \________________/
 DON'T PANIC - The Hitch Hiker's Guide to the Galaxy            {itself}
 PANIC - The Hitch Hiker's Guide to the Galaxy MK II        {Mostly Harmless}
      (perceiving the Whole Sort of General Mish Mash)       [Douglas Adams]

------------------------------

From: dillon@apollo.west.oic.com (Matthew Dillon)
Subject: Re: bug in 1.1.15
Date: 26 May 1994 08:11:31 -0700

In article <2s28dq$klm@vixen.cso.uiuc.edu> supat@meishan.animal.uiuc.edu (Faarungsang) writes:
:When I type the following command then it work:
:
:rsh -l supat meishan 'xterm -display 128.174.78.37:0'&
:
:but when I save this command as "meishan"
:and type meishan then it has following error:
:
:stty: TCGETS: Operation not supported on socket
:
:This error start in 1.1.12
:Up to 1.1.11 the command work fine.
:
:Could you fix this problem?
:
:Thanks,
:supat

    "stty: TCGETS: Operation not supported on socket" ... seems like somebody
    is trying to change the tty modes on the socket rsh uses.

    Since the socket is not a tty, the error message is correct.

    What is likely occuring is that your .cshrc on meishan is trying to run
    'stty' or trying to run a program which runs 'stty'.  Perhaps earlier
    Linux systems did not generate the error message, but it is the correct
    thing to do.

                                                -Matt

-- 

    Matthew Dillon              dillon@apollo.west.oic.com
    1005 Apollo Way             ham: KC6LVW (no mail drop)
    Incline Village, NV. 89451  Obvious Implementations Corporation
    USA                         Sandel-Avery Engineering
    [always include a portion of the original email in any response!]


------------------------------

From: wosch@rbg.informatik.th-darmstadt.de (olav woelfelschneider)
Subject: Re: Linux/SCO compatibility?
Date: 27 May 1994 11:34:59 GMT

> 
> | Also, will binaries from other Unix systems run under Linux?  i.e SCO?  BSD? 
> | SunOS?
> +------------->8
> 
> SunOS???  What makes you think a Sparc binary would work?
> 
Errrrhm, there once was a Sun386i machine, running SunOS ...

Sorry, but I had to mention this...

Olav

-- 
/======================================\
| Olav "Mac" Woelfelschneider          |
| wosch@rbg.informatik.th-darmstadt.de |
| mclaud@axposf.pa.dec.com             |
+--------------------------------------+
| I refuse to grow up,                 |
| I don't want to lose my humor...     |
\======================================/

------------------------------

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: script to implement ``dump levels'' (was Re: Anybody working on BSD dump porting?)
Reply-To: pe1chl@rabo.nl
Date: Fri, 27 May 1994 07:49:39 GMT

In <2s2q9f$72j@nwfocus.wa.com> ken@chinook.halcyon.com (Ken Pizzini) writes:

>In article <CqEHuw.3Bw@pe1chl.ampr.org>, Rob Janssen <pe1chl@rabo.nl> wrote:
>>The only problem left is that you cannot backup the filesystem without
>>modifying it in any way.  Either the atime is modified because you read
>>the file, or the ctime is modified because you attempt to reset the atime.
>>This is a bug in the system interface, IMHO, but it could be fixed.

>Since the alternative being proposed is based on raw disk access,
>and you really should only do that on an unmounted or read-only
>mounted file system, you can accomplish the same thing with
>a tar-like approach by remounting the filesystem to be backed-up
>readonly.  Granted, a system interface solution would allow you
>to backup "live", but at least the "remount readonly" solution
>is a useful workaround in those cases where you would be using
>"dump" anyway.

Well, usually we don't run the backup on a really live system, but we don't
like to tear everything down either.  Such systems usually run a lot
of server processes, and shutting everything down is time consuming.
So, after business hours everything is brought to a quiescent state
and the system is backed up with all processes still running (or better:
sleeping)
Because of that, re-mounting is unpractical.

I tried doing a read-only NFS mount, but at least on the system (SVR4) I
tried it on it does not work: when you mount read-only via NFS, the
times on the server filesystem *are still updated* :-(

It looks like an extra system call is the only viable solution, but it
won't happen, ofcourse...

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

------------------------------

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: can Linux notify w/ SIGIO or SIGPOLL???
Reply-To: pe1chl@rabo.nl
Date: Fri, 27 May 1994 07:53:36 GMT

In <1994May26.201756.22488@ll.mit.edu> kpl@ll.mit.edu (Kevin P. Lawton) writes:


>Hi,

>I'd like to be notified asynchronously with a signal when there
>is a change in status of a file descriptor (read,write,etc).

>Is there a mechanism in Linux for this?

It looks like it is being introduced right now, at least for ttys.
Unfortunately, the new tty code breaks a lot of things here right now,
so there is still some debugging to do.  Patches arrive every day, so
it should be ok soon.

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

------------------------------

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: How to print faster
Reply-To: pe1chl@rabo.nl
Date: Fri, 27 May 1994 07:59:01 GMT

In <2s353s$c06@news1.svc.portal.com> foulds@shell.portal.com (David - Foulds) writes:

>The printer driver lp.c seems to need a longer busy-loop,
>at least on my machine (486-SX33) and with my printer
>(Panasonic KX-P4410 laser with 2.5MB).  The busy loop
>that waits to send the next char in lp_char_interrupt
>only counts to 3 before giving up.  I increases the count
>to 30 or so (and also increased LP_BUFFER_SIZE to 2048)
>and reduced the time to print ghostscript 200K raster
>files (or whatever you call them) i.e. images of postscript
>pages after having been ghostscripted from 4 minutes to 50 seconds.
>This was while crunching the postscript in another process.
>On an empty machine the time per page went from 80 seconds 
>to 40, cpu utilization from 90% to 30% or so.

It looks like you are talking about a different version than is
in the kernel now.
Anyway, the current version allows tuning of these parameters to the
requirements of your printer and CPU speed using the program "tunelp",
without modifying lp.c

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

------------------------------

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: Symmetric Multiprocessing for Linux?
Reply-To: pe1chl@rabo.nl
Date: Fri, 27 May 1994 08:00:42 GMT

In <68328@sdcc12.ucsd.edu> imcclogh@cs.ucsd.edu (Ian McCloghrie) writes:

>ian_vogt@ACM.ORG writes:

>>Are there plans afoot to extend Linux to support symmetric
>>multi-processing (a la Mach?)

>I sincerely doubt it, since as far as I know, Linux only runs on
>386-architecutre PCs and some Amigas (I know virtually nothing about
>the Amiga port).  It's difficult to find these systems with the
>necessary hardware for SMP (like having more than one processor).

Apparently you have not looked at the PC market and/or the announcements
recently.

Anyway, the issue of SMP is clearly becoming a FAQ :-)

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

------------------------------

From: cullip@radonc.unc.edu (Timothy Cullip)
Subject: Re: Symmetric Multiprocessing for Linux?
Date: 27 May 1994 12:06:28 GMT

In article <68328@sdcc12.ucsd.edu> ian@ucsd.edu writes:
>ian_vogt@ACM.ORG writes:
>
>>Are there plans afoot to extend Linux to support symmetric
>>multi-processing (a la Mach?)
>
>I sincerely doubt it, since as far as I know, Linux only runs on
>386-architecutre PCs and some Amigas (I know virtually nothing about
>the Amiga port).  It's difficult to find these systems with the
>necessary hardware for SMP (like having more than one processor).
>

Have you taken a look in any decent PC mag lately? They are here now
and more are right around the corner.

Computer Shopper May and June:
        Royal Computer: twin 90 MHz Pentium, nicely equipped $7777

Byte June:
        ALR: 1-4 processor 90 (or 100) MHz Pentium, $6500 - $22000

Forgot which magazine: 
Dell planning to release twin 90 MHz pentium in 3rd quarter < $5000


I'm completely convinced that 1995 will be the year of the commodity
multiprocessor machine. NT is here (for what it's worth),
OS/2 SMP is right around the corner, so is Solaris SMP for x86.
Intel is strongly pushing their specification for SMP. With the
advent of the P54C and it's onboard APIC, it is now possible to
design SMP ready motherboards with the only additional cost being
the second cpu socket. It will be as easy as the current crop of
"overdrive socket ready" motherboards.

I would love to have an SMP Linux.



-- 

   Tim Cullip
   cullip@radonc.unc.edu


------------------------------

From: tdunbar@vtaix.cc.vt.edu (Thomas Dunbar)
Subject: Re: Symmetric Multiprocessing for Linux?
Date: 27 May 1994 12:14:16 GMT


imcclogh@cs.ucsd.edu (Ian McCloghrie)

writes:
>ian_vogt@ACM.ORG writes:
>
>>Are there plans afoot to extend Linux to support symmetric
>>multi-processing (a la Mach?)
>
>I sincerely doubt it, since as far as I know, Linux only runs on
>386-architecutre PCs and some Amigas (I know virtually nothing about
>the Amiga port).  It's difficult to find these systems with the
>necessary hardware for SMP (like having more than one processor).


no, it's not difficult at all to find them..for example, in many of
the pc mags, ALR has been running an ad about it's 4-100mhz pentiums
box ($22,000) being cheaper than Compaqs (>$30000). and there are
several other SMP intel (386/486/pentium) boxes available.

the problem is the cost is beyond Linux developers' budgets.  ...i
venture a guess that if ALR, Compaq, etc. were to donate a SMP box to
Linus, there would be a Linux-SMP before long.

------------------------------

From: kirk@speech.braille.uwo.ca (Kirk Reiser)
Subject: Re: 8k nfs performance
Date: 27 May 1994 12:55:23 GMT

A question I have is, is there benefit to be gained by using larger
transfer blocks on linux to linux boxes?

Running /usr as a nfs mounted drive is considerably slower than a
standard mount fs.

  Kirk
--

KirkReiser                              The Computer Braille Facility
e-mail: kirk@braille.uwo.ca             University of Western Ontario
phone: (519) 661-3061

------------------------------

From: shl0@ihd117e.CC.Lehigh.EDU (Samson H. Lee)
Subject: Kudos -- CPU speed and load
Date: Fri, 27 May 1994 12:37:19 GMT

I just wanted to let whoever was responsible for the code for
adjusting CPU speed in response to load know that it has made a big
difference on my laptop.  It's really great.  I recently read
somewhere about this and decided to update my kernel from 1.0.8
(Slackware 1.2).  So I got the 1.1.13 kernel and applied patch14,
recompiled and tried it out.  What a difference in the amount of heat
generated by the CPU!!!  I used to have problems with the lower right
portion of the screen fading because of the excessive heat put off by
the CPU.  Now the heat is minimal.

Great job!  Thanks.
Sam.
=====
shl0@lehigh.edu
Tell him that Dr. Fleischman is the kind of enterprising, young
professional who's chosen to stake his claim right here on the 
banks of the Alaskan Riviera.
   Tell him I'm being held against my will.
                                Maurice and Joel to businessmen (1.4)
                                Northern Exposure

------------------------------

From: mmnuk@risc.uni-linz.ac.at (Michael MNUK)
Crossposted-To: comp.os.linux.help
Subject: Why is my Emacs binary so big (2.2M)
Date: 27 May 1994 13:29:53 GMT

I compiled the Emacs 19.24 using the standard distribution (no extra packages
dumped). The resulting binary is about 2.2M big which is about twice as much
as the binary I got with the Slackware distribution. I only changed the
compilation flag from "-g" to "-O2".

I observed the same with e.g. fvwm. The ratio there is even more dramatic.
E.g. FvwmBanner is now about 250K whereas the old (Slackware distrib.) was
about 30K.

Am I linking statically (-static option never specified!) or is
something else wrong?
--
Michal Mnuk                                  Phone: +7236 3231 75             
Research Institute for Symbolic Computation  Fax  : +7236 3231 30             
A-4040 Linz, Austria                         E-mail: mmnuk@risc.uni-linz.ac.at


------------------------------

From: hm@seneca.ix.de (Harald Milz)
Subject: Re: 1.1.15 breaks SCSI
Date: Fri, 27 May 1994 07:17:40 GMT
Reply-To: hm@seneca.ix.de

Rene COUGNENC (rene@renux.frmug.fr.net) wrote:

: > The kernel 1.1.15 does not work at all with my Adaptec 1540B.
: > I get "Unable to reset SCSI host 0, probably a SCSI bus hang."

Ummm... I have 1.1.15 (now with Tytso's patches to get SLIP working again, 
thanks!) with a 1542B, no probs whatsoever. 

: > And I can't boot.

Are there any boot/error messages from the driver?

-- 
Harald Milz                             office: hm@ix.de
iX Multiuser Multitasking Magazine      home:   hm@seneca.ix.de
Opinions are mine, not my employer's -- the answer is Forty-two


------------------------------

From: mlord@bnr.ca (Mark Lord)
Subject: Re: PROBLEM: bad serial I/O
Date: 27 May 1994 13:45:33 GMT

In article <1994May27.012422.1427@escape.widomaker.com> shendrix@escape.widomaker.com writes:
>
>I have been having a small problem since upgrading to 1.1.11.  Today I
>went to 1.1.15, same problem.
>
>Basically, serial I/O is really bad now.  Transfering files I get lot's
>of CRC errors and when using software online I get scrambled screens,
>etc.

Does your system have an IDE drive installed?
If so, then get the IDE performance package (ide20.patch.gz) to fix things.
-- 
mlord@bnr.ca    Mark Lord       BNR Ottawa,Canada       613-763-7482

------------------------------

From: lilo@slip-13-11 (lilo (SpRiNg 94 GpA 3.64))
Subject: Re: Skinny Dip
Date: 26 May 1994 17:09:22 GMT

On 25 May 1994 17:12:06 GMT, Eric Zager (eric@marge.phys.washington.edu) wrote:

> I tried to run DIP-Skinny-3.3.7 on my system, but it doesn't seem to
> work.  Also, I've noticed that my free memory has been shrinking.  Has
> anyone had any success?

Try running DIP-Skinny-3.3.7-lilo-3.2 .... it doesn't take care of that
problem, but it comes in six designer colors, and makes your thighs shrink. 
:)


lilo

------------------------------

From: lilo@slip-13-11 (lilo (SpRiNg 94 GpA 3.64))
Subject: Re: SIGHUP - Where do we go from here?
Date: 26 May 1994 17:15:07 GMT

On Wed, 25 May 1994 13:57:13 GMT, Sean Puckett (nate@loreli.ftl.fl.us) wrote:
> So here's what we've learned.

>   1.  Posix says SIGHUP should be sent only to session leaders.
>   2.  Linux' kernel follows Posix as exactly as possible.
>   3.  Many applications do not follow the Posix standards in the fine
>       details of orphaning and signal handling.
>   4.  Some people believe 100% Posix compliance is a Good Thing.  Period.
>   5.  Some people believe that Posix compliance is a Good Thing
>       unless it causes problems for real world scenarios.

That sounds about right.

> Because of these facts:

>   1.  The kernel baseline will not change.  (The people who believe in
>       100% Posix compliance are the people who control the baseline).

I resent the implication that I have any control over mainline kernel
policy! :) :) :)  (I don't, BTW. :)

>   2.  People will continue to have problems with non-compliant
>       applications.

Most *nix applications that require them have configuration options which
can be varied to compile them for the specific operating systems they run
on.  If you're planning on running your application on Linux and some other,
non-Posix-compliant operating system, you should probably have a way of
distinguishing between them for configuration purposes.  The tidiest way
I've seen is to have a number of config options, and sample files which will
work for specific, common operating systems (SUNOS, Linux, BSD, etc)....

> And therefore:

>   1.  Sooner or later an ugly solution will come forward to deal with
>       non-compliant applications.

See above? :)

> This is about as apolitical as I can make the current tussle sound.

Actually, I think you did pretty well.  :)


lilo

------------------------------

From: diamom@fi.gs.com (Mitchell Diamond)
Subject: Svgalib with ati vga wonder XL24
Reply-To: diamom@fi.gs.com
Date: Fri, 27 May 1994 13:12:17 GMT


HI. does anyone know if svgalib works at 1024x768 on an ati vga wonder xl24 video card.

if so can some one send me some docs on setting it up.

thanks

THE MITCH MAN

diamom@fw.gs.com


------------------------------


** 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
******************************
