Subject: Linux-Development Digest #415
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, 28 Jan 94 05:13:09 EST

Linux-Development Digest #415, Volume #1         Fri, 28 Jan 94 05:13:09 EST

Contents:
  Re: nfs performance (Mark Evans)
  Real Time A/D Processing (Robert W. Cox)
  0.99pl14c  and 0.99pl14w problem. (Bill C. Riemers)
  Non-blocking I/O (Brian Quandt)
  Re: Winders NT on MC68K? (Charles E Meier)
  Syquest 88 meg - parameters?? (George Gerald Gibeau)
  Re: Which is better? 680x0 or 80x86? (Larry Pyeatt)
  ibm4300 (Eddie Daghelian)
  What are the major/minor numbers for /dev/ram? (Doug Nicholson)
  Re: Winders NT on MC68K?  (was Re: Which is better? 680x0 or 80x86?) (Miguel de Icaza)
  Re: Atari port (Richard Hodson)
  Re: AIC-7770 Support (Scott Ferris)
  Re: Winders NT on MC68K?  (was Re: Which is better? 680x0 or 80x86?) (Hamish Macdonald)
  Re: Version control systems... (Peter Mutsaers)
  Re: NIS Server NEED (Matthias Urlichs)

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

From: evansmp@mb48026.aston.ac.uk (Mark Evans)
Subject: Re: nfs performance
Date: Thu, 27 Jan 1994 17:36:18 GMT

Donald J. Becker (becker@super.org) wrote:

: Just running multiple copies of 'nfsd' wouldn't be a performance win in most
: situations.  Something that might speed up the Linux NFS server is making it
: multithreaded within a single address space, or having several processes
: share the database.

Multi process using shared memory IPC is another posibility.
Isn't this how some implimentations do it, considering that you start the nfsd
with something like /usr/etc/nfsd 8 .
In which case the obvious thing to do is to allocate an area of memory use mmap
with a SHARE flag, then fork to give the requested number of processes.

Also possible using sysv shm... operations.

: Both 'biod' and an in-kernel NFS server are implementation details specific
: to Sun's code.  Most commercial NFS implementations do it that way because
: they *license* Sun's implementation, not because it's the only (or best) way
: to do it.  (Compare the user-level Linux NFS server that allows cleanly
: adding features such as pseudo file systems, to the grungy in-kernel hack
: that Sun is stuck with for historical reasons.)

Not that the user-level server does not have problems. 
e.g. it doesn't take notice of mount points. thus you can do 
mount localhost:/ /mnt and create a loop


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

From: rwcox@post.its.mcw.edu (Robert W. Cox)
Subject: Real Time A/D Processing
Date: 27 Jan 1994 10:18:36 -0600

We are planning to do real time Magnetic Resonance Imaging.
The technical needs are an A/D card capable of sampling
at least 12 bits at 250 KHz.  Such cards exist in profusion
for PCs. The trick is that the software they come with is
for DOS.  Has anyone written software (a device driver, I
suppose) for Linux to control such a board -- primarily,
transfer data from its buffer to main memory?

I estimate a 486 DX2/50 box can filter and reconstruct
about 1-2 images per second.  This will be very useful
for our research.  Doing it on a PC box will be the nice
cheap way to go.  Using Linux would be much nicer than
having fun with DOS.

Robert Cox
Biophysics Research Institute
Medical College of Wisconsin
Milwaukee, WI  USA

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

From: bcr@bohr.physics.purdue.edu (Bill C. Riemers)
Subject: 0.99pl14c  and 0.99pl14w problem.
Date: 27 Jan 94 22:57:11 GMT

Hi there,


I seem  to be having trouble with the way the alpha level
kernels are assigning priority to processes under xfree2.0.
It seemes anything that does not currently focused  for 
input is given a much lower priority.  Here are the obvious
examples:
  ncftp tupload  :  Within 15 seconds after moving my focus to another
                    window, the rate drops from 1650 to 650cps.
  oclock : This was swapped out for almost an hour before I noticed the time was
           no-longer being updated.

"renice"ing a command doesn't help.  Someetimes refocusing help, others I
need to suspend and resume the process.

System satistics:

24MB RAM, 16MB swap, 486DX2-66V, ATI Ultra Pro.  
libc.so.4.4.4
gcc 2.5.2
based on Slackware 1.1.1


NOTE: 0.99pl14 worked beutifully.   I just decided to try the alpha patches
before 0.99pl15.  To be honest I haven't the slightest idea what change
in the newer kernel could cause this type of problem.

                                    Bill

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

Crossposted-To: comp.os.linux,comp.os.linux.help,comp.os.linux.misc
From: quandt@cs.umr.edu (Brian Quandt)
Subject: Non-blocking I/O
Date: Fri, 28 Jan 1994 02:05:42 GMT

Does Linux have support for non-blocking i/o routines?

Also, what is the largest amount of virtual memory that can be supported
under Linux? 

Here's what I'm trying to do:
        Create a real-time buffer that is very large.  I'd like to 
        do this as a piped process.

        p1 | p2 | p3

        where

        p1 is a the process running in real time generating or sayu around
        1.5MB/sec

        p2 just reads data from p1 and trys to send it out to p3, if it
        can't (non-blocking writes) it just allocates memory and
        keeps it there until it can then write out to p3.  And since
        Linux supports Vitural memory ... I can effectively create
        a real time cache that is as large as my virtual space (disk drive).

        p3 is just some process that does not run in real time.  Note that
        this assumes that p1 dies before we run out of VM.



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

From: cemeier@magnus.acs.ohio-state.edu (Charles E Meier)
Subject: Re: Winders NT on MC68K?
Date: 27 Jan 1994 18:43:59 GMT

In article <2i8ul5$q13@sol.ctr.columbia.edu>,
>
>All these UNIX systems you're talking about are not 100% source code
>compatible.  You're confusing "being portable" with "having been ported".
>

What is meant by "100% portable?"  NT sits on top of a layer of code that must
be re-written for each specific architecture.

As far as application developers go, I would expect that the portability of 
the operating system is largely irrelevent.  If NT (or any other O/S) has to 
be totally rewritten from scratch in order to run it on another machine, the
app developer shouldn't care as long as the system and library calls wind up
the same from machine to machine.  This is one of the purposes of an O/S - to 
hide the underlying architecture of the machine from the applications 
programmer and ultimate end user of the application.  

This is one of the strengths of UNIX.  It isn't *that* difficult to port an
app from one vendor/version/machine combination to another.

>--
>+-------------------+----------------------------+---------------------------+
>| JERRY J. SHEKHEL  | Molecular Simulations Inc. | Cowboy Junkies, Phish,    |
>| Drummers do it... |     Burlington, MA USA     | Tribe, Guns N' Roses,     |
>|    ... In rhythm! |        jerry@msi.com       | TAMA, Zildjian, Linux...  |
>+-------------------+----------------------------+---------------------------+

--
        Charles E. Meier     <cemeier@magnus.acs.ohio-state.edu>

- "You can learn a lot from listening to people talk.  Why everything I
know today I've learned from listening to myself talk about things that 
I knew absolutely nothing about." - Gracie Allen

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

From: ggibeau@iac.net (George Gerald Gibeau)
Subject: Syquest 88 meg - parameters??
Date: 27 Jan 1994 21:05:05 -0500

Greetings,

I have been playing with Linux, and have a question.  I currently
have it working with a Seagate IDE drive, I also have a SCSI
controller that I use to share an 88 meg Syquest as well as a
Hitachi CD-ROM with my Amiga.  So far I have been unable to
get the Syquest to be recognized properly, there is no problem
with the CD-ROM.

Has anyone out there utilized a Syquest drive with Linux??

Thanks in advance..

George Gibeau

-- 
George Gerald Gibeau, Jr.           ggibeau@iac.net
Picasso II RTG - the only way to see!!!

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

From: pyeatt@CS.ColoState.EDU (Larry Pyeatt)
Subject: Re: Which is better? 680x0 or 80x86?
Date: 27 Jan 94 17:49:36 GMT


In article <1994Jan27.075507.8184@pe1chl.ampr.org>, rob@pe1chl.ampr.org (Rob Janssen) writes:
|> In <1994Jan26.203528.36419@yuma> pyeatt@CS.ColoState.EDU (Larry Pyeatt) writes:
|> >In article <1994Jan25.182321.2996@pe1chl.ampr.org>, rob@pe1chl.ampr.org (Rob Janssen) writes:
|> >   
|> >It is not really the number of registers that matters.  The x86 registers
|> >are not general purpose, which means lots of swapping all the time.  On
|> >the 680x0, there are twice as many registers, but they are more general
|> >purpose and do not get swapped as often.
|> 
|> No.  On a taskswitch you need to swap all registers, or else you would have
|> to ban some of them from being used.

Yes.  
During normal program execution, the x86 registers must be swapped
_by the program_ much more often than the 680x0 registers.  During task
switching, the 680x0 swaps 16 registers compared to 8 on the x86.  The extra
overhead caused by swapping the limited x86 register set _by the program_
cancells out the small number of registers saved during a task switch.
If the source code is assembly language, then the x86 does not suffer too
badly from its poor architecture.  However, it is very difficult to get
optimized code from a high level language on the x86.

|> If you don't do that, the registers would change in a task when a task
|> switch occurs, which is something the task cannot control.  (unless you
|> are talking non-preemptive multitasking)

That is not even close to my point.  The point is that the task itself
has to swap registers much more often on an x86 than on a 680x0.  This
overhead costs as much or more than swapping 8 more registers on a
task switch.  Also, the 680x0 family has a burst memory access mode which
makes saving and restoring context less expensive than a normal memory
access.

|> >I agree.  A 386SX16 falls somewhere betwee a 68010 and a 68020 in
|> >performance and features.
|> 
|> That is complete nonsense.  Maybe in performance but not in features.

Features.  Perhaps you are referring to the non-orthogonal instruction
set.  Maybe you mean the shoddy segmented memory scheme.  Maybe you are
talking about hardware memory protection.  The 020 features a very
impressive coprocessor link.  If you add a 68851 paged memory management
unit to the 020, it blows a 386 out of the water.  You can add up to 
8 coprocessors to the 020.  The 386 MMU facilities are paltry in comparison.
The 020 has 16 general purpose registers in 2 classes.  I call that a 
feature. The 386 has 8 special purpose registers.  I don't call that a
feature.

|> >That's funny.  I would have said that the 68010 and 80286 are comparably
|> >equipped for memory management.  They both have very little.  However,
|> 
|> Please consult some databooks before you say things like that.
|> The 68010/68020 have *no memory management at all*, only support for
|> an external MMU.  (thinks like instruction re-run)
|> The 80286 has an on-chip segmented MMU.

Hahaha!  You call that an MMU?  I call it a mistake!  I have written
system level code for the 68010 and the 80286.  They are pretty well
equivalent.  Intel may call it an MMU, but then intel calls AX, BX, CX,
DX, SS, SI, DS, and CS general purpose registers, which they obviously
are not.

|> >the 68020 pretty well outclasses the 80386, especially if you add a
|> >68888(?) memory management unit to the 68020. 
[deletions]
|> > Running a real operating system, the 68040 
|> >provides marginally better performance overall than an 80486.  Bottom
|> >line is that they are deliver comparable performance, but the 680x0
|> >architecture is "prettier."
|> 
|> Now that is more close to a reason to use the 68k line...  performance
|> has been better for a long time, and it was easier to write assembly
|> for it all the time.
|> The performance problem has vanished with the introduction of faster
|> and faster Intel processors, but that clearly came at a price: the
|> load of backward compatability features that these chips carry makes
|> them much more complex than really needed. (and maybe it is an explanation
|> for the exorbitant power consumption as well?)

Well, we do agree on some things.
-- 
Larry D. Pyeatt                   All standard disclaimers apply.
pyeatt@cs.colostate.edu           Void where prohibited.

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

From: eddied@ariel.cs.yorku.ca (Eddie Daghelian)
Subject: ibm4300
Date: Thu, 27 Jan 1994 19:59:45 GMT

Hi,

I have a question that has been posed to me.  Does anybody out there know
if APL was used in the development of the IBM 4300 series operating 
system??

If so, can you please email me at eddied@yorku.ca with a reply of yes or no,
and if possible some information about it.

Thanks, I really appreciate it.


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

From: tinamou@hemlock.cray.com (Doug Nicholson)
Subject: What are the major/minor numbers for /dev/ram?
Date: 27 Jan 94 19:02:59 CST

I've been doing some experimenting with the ramdisk but it
wouldn't work!  I did some checking and the kernel source
(ramdisk.c) says the device is major number 1 and minor
number 1.  Rick Miller's Linux Device List says /dev/ram
is major number 1 and minor number 0 (which is the way
/dev/ram is setup on my system).  Would someone clue me
in on what it correct?  Should I send someone a bug report
and where?  Thanks.

Doug Nicholson
tinamou@cray.com

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

From: miguel@roxanne.nuclecu.unam.mx (Miguel de Icaza)
Subject: Re: Winders NT on MC68K?  (was Re: Which is better? 680x0 or 80x86?)
Date: 27 Jan 1994 22:38:21 GMT


> : >
> : >Your comments are misleading.  True, MS indicated no willingness to port
> : >NT to big-endian CPUs.  However, that doesn't mean that NT is as you say
> : >"hard-coded to little-endian processors".  There is no evidence either way
> : >whatsoever.  MS may simply be avoiding binary file incompatibilities and
> : >byte swapping issues.
> :
> : Snigger.. Unix fixed this 15 years ago too. I would think its a bit more
> : serious than a few byte swapping issues somehow. 
> :
> 
> Stop it!  Unix didn't fix squat.  Try writing some integers out to a binary
> file on one machine and then reading them back in on another machine of
> different endian-ness.

Take a look at the htonl and friends functions...

Miguel.

--

Miguel.


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

From: richard@radar.demon.co.uk (Richard Hodson)
Subject: Re: Atari port
Date: Thu, 27 Jan 1994 23:55:45 +0000

Rob Janssen (rob@pe1chl.ampr.org) wrote:
: In <1994Jan24.234259.2931@radar.demon.co.uk> richard@radar.demon.co.uk (Richard Hodson) writes:

: Then maybe you should start to work on it yourself?

I had considered it. So far I have had four replies by mail to this posting
and the impression I get is that if I started with an Amiga kernel I would
just have the rest of the OS to write :-)

: Is there so much difference between an 386/40 and the TT?  I would not
: think it is that spectacular...

In itself, no. Lets face it, the TT is now rather old. Dhrystones show
the TT to be only slightly faster than a 486/25.  The point is, my 386
has 4MB of ram, SCSI, but no FPU. The TT has 8MB of ram, a quick FPU and
built in SCSI. I find on PCs that going from 4MB to 8MB doubles system
speed. In all I would expect around 1.5x to 2.5x overall system performance.

My first thoughts were that all I want is a kernel, ext2fs and a serial
port driver so that I could slip/PPP to the TT. The SCSI chip in the TT
is an NCR 5380 which I believe is used in some PC cards. The UART driver
should be no problem ( I write that kind of stuff at work). The nasty
stuff is the Atari DMA and C libs.

The 386 does OK, but it annoys me that the more powerful machine is not
running my now favourite operating system. At some point I will no doubt
buy a 486 and this will become more academic, but the hacker in me hates
wasting CPU...

: Rob (who considered buying a TT but dropped the idea because Atari
dropped UNIX)

--
Richard Hodson                                |  richard@radar.demon.co.uk
And his amazing fetish for dangly earrings... |  rhodson@cix.compulink.co.uk


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

From: sferris@budapest.math.macalstr.edu (Scott Ferris)
Subject: Re: AIC-7770 Support
Date: 26 Jan 1994 22:19:57 GMT

Matthew Fisher (mfisher@ringer.cs.utsa.edu) wrote:

> Is there a projected date as to when the Adaptec 7770 SCSI chipset will be 
> supported?  I need to be able to run Linux for some of my CS classes.

  No date has yet been determined.  I'm still just finding the
time now to write the assembler for the microcode.  When something
reaches alpha there will be an announcement.  I wouldn't expecting anything
in the immediate future.  When something is ready also depends
on where the aic-7770 chip you have is. I've got an aha-2742t myself.  
I can't directly test either the 284x series (though I might be able
to get a sample board for testing later) or motherboards with the chip
at this time.  

> Thanks,
> Matthew

--
Scott Ferris,             sferris@math.macalstr.edu
LaserMaster Inc,
Macalester College,
and points in between.


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

From: Hamish.Macdonald@bnr.ca (Hamish Macdonald)
Subject: Re: Winders NT on MC68K?  (was Re: Which is better? 680x0 or 80x86?)
Date: 27 Jan 1994 17:51:09 GMT

>>>>> On 26 Jan 1994 16:33:25 EST,
>>>>> In message <2i6nj5$14q@sol.ctr.columbia.edu>,
>>>>> jerry@msi.com (Jerry Shekhel) wrote:

Jerry> Yep, you're right, I forgot about that.  But is SunOS 4.x.x
Jerry> still a living OS?  I thought it had been superceded by
Jerry> Solaris.

You didn't say anything about a "living OS" when you originally
brought this up Jerry.  What do you mean by "living OS", anyway?  I
bet that there are more Suns running SunOS 4 than Solaris...

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

From: muts@compi.hobby.nl (Peter Mutsaers)
Subject: Re: Version control systems...
Date: Thu, 27 Jan 1994 01:04:32 GMT

>> On 25 Jan 1994 19:06:26 GMT, root@bsd.coe.montana.edu (Superuser)
>> said:

  S> It works quite well and is based on RCS.  However, you do not have the
  S> locking capability you asked for above, but everyone I've introduced to
  S> CVS has found out that it's a non-issue once you used it for a little
  S> while.  (Of course there is some fear and trepidation at first, but it
  S> goes away quickly)

I agree fully. I've yet got to find a commercial tool that equals
CVS's usefulness. Locking is unnecessary. It is quite arbitrary to
lock on a file. When the whole group of files is related, why not lock
on a part of a file, or on a group of files, or on all files? Every
choice is arbitrary, it is better not to lock at all but provide a
good merge mechanism (as CVS does).
-- 
Peter Mutsaers, Bunnik (Ut), the Netherlands.
home: muts@compi.hobby.nl
work: muts@fss.fokker.nl
Disclaimer: This reflects the official opinions of my employer.

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

From: urlichs@smurf.noris.de (Matthias Urlichs)
Crossposted-To: comp.os.linux.help
Subject: Re: NIS Server NEED
Date: 26 Jan 1994 21:59:53 +0100

In comp.os.linux.development, article <2i482l$4n3@celsius.ifm.liu.se>,
  peter@ifm.liu.se (Peter Eriksson) writes:
> mangon@gla.ecoledoc.ibp.fr (Olivier MANGON) writes:
> 
> >I need to find a NIS server for linux (yp*), so if anyone can tell me
> >where i can get one Please Email Directly...
> 
> Why not write one yourself? An YP server is a really really easy piece
> of program. Sigh. Ah well. I just wrote a first stub at one. You can
> FTP it from "ftp.lysator.liu.se" in "pub/NYS" as "ypserv-0.1.tar.gz".

THANK YOU. (I looked; it's version 0.2 now. ;-)

-- 
I do not believe that an increase in intelligence represents real progress for
humanity. It is much more likely that it will only enable us to make a higher
class of mistake.
                                       -- Solomon Short
-- 
Matthias Urlichs        \ XLink-POP N|rnberg  | EMail: urlichs@smurf.noris.de
Schleiermacherstra_e 12  \  Unix+Linux+Mac    | Phone: ...please use email.
90491 N|rnberg (Germany)  \   Consulting+Networking+Programming+etc'ing     42

Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.

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


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