Subject: Linux-Development Digest #793
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:     Sat, 4 Jun 94 15:13:06 EDT

Linux-Development Digest #793, Volume #1          Sat, 4 Jun 94 15:13:06 EDT

Contents:
  Re: ps: SIZE < RSS??? (David Fox)
  Re: Let's rename v1.0.9! [Was: Frustrated with new kernels] (David Fox)
  Re: ps: SIZE < RSS??? (Robert Andrew Ryan)
  Re: ps: SIZE < RSS??? (Michael Lausch)
  Logitech Scanner SAPI-3.1 (Karl Eichwalder)
  Video Blaster, anyone? (Pete Deuel)
  Re: Using 2 ethernet cards with DOSEMU (Rob Janssen)
  Re: Frustrated with new k (Rob Janssen)
  Re: Need: MSDOS & ISO9660 filesystem source (Rob Janssen)
  Linux game development conclusions. (sl4hq@cc.usu.edu)
  Linux ext2fs vs. ufs vs. presto [was Re: Fast File System?] (Case Larsen)
  Re: Linux game development (Was Re: Why [DOS, W (the MOST SIGNIFICANT bit)
  Re: 1.1.16 kernel doesn't want to boot! (Mike Baptiste P275)

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

From: fox@graphics.cs.nyu.edu (David Fox)
Subject: Re: ps: SIZE < RSS???
Date: 03 Jun 1994 20:32:59 GMT

David Fox writes:

] The man page for ps says that 
] 
]        SIZE virtual image size, size of text+data+stack
] 
]        RSS  resident set size, kilobytes of program in memory.
] 
] It would seem that SIZE would always be >= RSS, yet
] 
] USER       PID %CPU %MEM SIZE  RSS TTY STAT START   TIME COMMAND
] root        21  0.0  0.3   12   52  ?  S   Jun  2   0:02 update (bdflush)
] fox      14680  2.2  2.3  197  348 pp4 S    14:11   0:01 make -k
] fox      14787  0.2  1.5  102  228 pp4 S    14:11   0:00 gcc -c text.C -g -DX
] 
] How is this possible?

Oops, I forgot about the heap.  I have cancelled the original
article.
--
David Fox                                               xoF divaD
NYU Media Research Lab                     baL hcraeseR aideM UYN

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

From: fox@graphics.cs.nyu.edu (David Fox)
Subject: Re: Let's rename v1.0.9! [Was: Frustrated with new kernels]
Date: 03 Jun 1994 20:36:36 GMT

In article <2snr8j$8jm@acmex.gatech.edu> gt8134b@prism.gatech.edu (Robert Sanders) writes:

] Honestly, I don't see what everyone's crying about.

I agree, but it is awefully hard to resist the nearly doubled
disk speed that the 1.1 kernels offer.
--
David Fox                                               xoF divaD
NYU Media Research Lab                     baL hcraeseR aideM UYN

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

From: Robert Andrew Ryan <rr2b+@andrew.cmu.edu>
Subject: Re: ps: SIZE < RSS???
Date: Sat,  4 Jun 1994 12:19:45 -0400

I suspect that SIZE < RSS is a common situation when shared libraries
are used.  (between SunOS, AIX 3, and HP-UX) I think shared library
pages are usually counted in the resident segment size, but not in the
process size.

I don't know for a fact that this is what's going on but it fits all the
facts I know.

-Rob

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

From: mla@loki.muc.de (Michael Lausch)
Subject: Re: ps: SIZE < RSS???
Date: 4 Jun 1994 17:46:39 +0200

In article <2sq068$gtc@styx.uwa.edu.au>,
David Luyer <luyer@tartarus.uwa.edu.au> wrote:
>David Fox (fox@graphics.cs.nyu.edu) wrote:
>: David Fox writes:
>
>: ] The man page for ps says that 
>: ] 
>: ]        SIZE virtual image size, size of text+data+stack
>: ] 
>: ]        RSS  resident set size, kilobytes of program in memory.
>: ] 
>: ] It would seem that SIZE would always be >= RSS, yet
>: ] 
>: ] USER       PID %CPU %MEM SIZE  RSS TTY STAT START   TIME COMMAND
>: ] root        21  0.0  0.3   12   52  ?  S   Jun  2   0:02 update (bdflush)
>: ] fox      14680  2.2  2.3  197  348 pp4 S    14:11   0:01 make -k
>: ] fox      14787  0.2  1.5  102  228 pp4 S    14:11   0:00 gcc -c text.C -g -DX
>: ] 
>: ] How is this possible?
>
>: Oops, I forgot about the heap.  I have cancelled the original
>: article.
>: --
>: David Fox                                            xoF divaD
>: NYU Media Research Lab                          baL hcraeseR aideM UYN
>
>Yes, someone please reply to this.  I know that it happens on SunOS
>and ULTRIX too, and it is seems to me totally illogical `,-^>
>--
It is the same thing as under SunOS. The shared library are added to
the RSS but not to the SIZE field.
>........................................................................
>
>"Apples have been a problem ever since Eden."
>
>"Electrons are tiny little particles you can only see if you have been
> drinking."
>
>luyer@lethe.uwa.edu.au
>
>.............................................................David Luyer
>
>>>>>>>>>>>>> This message made from 100% recycled electrons <<<<<<<<<<<<
>
>........................................................................


-- 
---
Magic is real unless declared integer
Michael Lausch                  e-mail: mla@loki.muc.de
Office: +41 089 93001 427       Home: +41 089 361 00 926

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

Crossposted-To: de.comp.os.linux
From: karl@pertron.central.de (Karl Eichwalder)
Subject: Logitech Scanner SAPI-3.1
Reply-To: keichwa@gwdg.de (Karl Eichwalder)
Date: Sat, 4 Jun 1994 09:11:47 GMT

Right now I have received form Logitech Germany the Documention

        Scanner Application Program Interface (SAPI).
                Specification Version 3.1.

and a diskette labeled "SAPI Toolkit Disk. Version 7/16/93".  I think, if you
-- the real "kernel hacker -- write to Logitech, you will get this stuff too
(but it seems not to be allowed just to copy the disk and share it with
others, strange ...).

This doc isn't as helpful as it should be:

        The SAPI defines only the interface between scanner drivers and
        applications.  All other details of scanner driver implementation,
        such as command line parameters, are left to the discretion of the
        scanner manufacturer.

But you also read in this doc:

        While the SAPI is designed for use under DOS ans OS/2, the IOCTL-style
        interface could also be transferred (with some modifications) to UNIX
        and UNIX-like systems.

We probably should write to logitech.com to ask for this "transferration to
UNIX and UNIX-like systems" and for these "modifications".

--
Karl

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

From: deuelpm@craft.camp.clarkson.edu (Pete Deuel)
Subject: Video Blaster, anyone?
Date: Sat, 4 Jun 1994 16:51:06 GMT



--
=====================================
deuelpm@craft.camp.clarkson.edu
=====================================
"*Regret* is a rough sheet to sleep on."  -Herman Brooks

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

Crossposted-To: comp.os.linux.admin
From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: Using 2 ethernet cards with DOSEMU
Reply-To: pe1chl@rabo.nl
Date: Fri, 3 Jun 1994 17:21:51 GMT

In <2slpu4$pkd@blackbird.db.erau.edu> andersoa@news.db.erau.edu (Andrew Anderson) writes:

>I'm trying to configure a linux box to act as a telnet responder for a 
>Novell server.  I'm running Slackware 1.0.8 and DOSEMU 0.50pl1.  I can 
>get one dos session to work just fine, but if I try to run 2 dos sessions,
>I get a security breach on the Novell side, since netx can't handle 2 
>sessions from the same ethernet address.  So I installed another ethernet 
>card, and I'm trying to get DOSEMU to work with a device other than eth0.  

>I already found the references to eth0 in the dosemu source code, but 
>after re-compiling, it still refuses to use anything other than eth0.  
>I know both cards are operational under plain linux, so it has something 
>to do with the way DOSEMU is accessing them.  Can anyone yield some 
>insight into what's happening here?  Or at least give me a few more 
>ideas to try?

The network access was rewritten in the ALPHA release (soon to appear
as a general release, 0.52 I think)
But this still includes support for only one ethernet card.  I am planning
to add access to all networking devices, though.

What would be more interesting (in this case) is to find how one can
have more than one connection to Novell over a single ethernet card.  I
think OS/2 can do it, so it must be possible.  If someone can tell me how
it is done, I can include the support for it in the networking interface
if necessary.

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: Frustrated with new k
Reply-To: pe1chl@rabo.nl
Date: Fri, 3 Jun 1994 17:33:00 GMT

In <2slqgh$6e@charm.magnus.acs.ohio-state.edu> ewalton@magnus.acs.ohio-state.edu (Elaine Walton) writes:

>What I wanted was someone considerate enough to compile a package BEFORE
>gzip'ing it into a package.  I know that these altruistic developers are
>doing this on their own time--and I am truly grateful.  However, if they
>want other developers--like myself, I suggest that a minimum set of
>requirements be met before making it public.  Compilability comes to mind.
>I mean, how am I supposed to test the work if I can't run it.

I don't think anyone ever ships a package which cannot be compiled.
However, there are so many things that can affect the success (e.g.
version of gcc, version of include files, correctness of installation
(symlinks), answers during "make config" etc etc) that it can easily
happen that it won't compile.
When someone just says "it won't compile" or "it bombs", there is very
little that can be done.

>Two messages ago on this thread, I complained in frustration.  The first
>to censure me said something truly helpful: "where's the detail?".  Yes,
>this is very important, but I supplied that detail TWO WEEKS AGO.  Where
>was he then???

Ah, you are my employer?
Don't think anyone can answer all questions and other messages in this
thread, especially not when the same thing comes up over and over again.
One simply has to skip 90% of the messages and answer 10% or less to keep
the time spent down to a reasonable level!

I try to answer questions regularly, but I skip those that:

- say "please answer by email because I don't have time to read this group".
  he who has no time to read a newsgroup should not expect others to use
  their time to answer his questions, especially not as they are usually
  FAQ's.

- don't give enough detail to make reasonable guesses about the problem

- are about a driver or piece of hardware I don't have personal experience
  with.

your problem with a panasonic drive falls into the last category.

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: Need: MSDOS & ISO9660 filesystem source
Reply-To: pe1chl@rabo.nl
Date: Fri, 3 Jun 1994 17:36:04 GMT

In <113287@cup.portal.com> cliffhanger@cup.portal.com (Cliff C Heyer) writes:

>I have linux on many(!) floppy disks and have not
>loaded it yet. I think (?) you can mount MSDOS 
>partitions with it? Can this also be done with
>ISO9660? Is the source code within my disks of
>linux?

yes
yes
yes

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

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

From: sl4hq@cc.usu.edu
Subject: Linux game development conclusions.
Date: 4 Jun 94 11:05:14 MDT

I've been following the Linux Game Devleopment thread, but it seems so
inconclusive.  Can we get a difinitive answer here?  Here's my question:

I want to run Paradise Netrek on my 486/sx over a SLIP connection.  I don't
have enough drive space to install an entire Linux partition.  What do I need
and where is it to do this?

Thanks!

Michael

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

From: clarsen@intruder.lbl.gov (Case Larsen)
Crossposted-To: comp.benchmarks,comp.sys.sun.admin
Subject: Linux ext2fs vs. ufs vs. presto [was Re: Fast File System?]
Date: 3 Jun 1994 19:49:42 GMT


Thanks very much for taking the time to run those tests.  It is also
interesting to see what happens when less data is written out, e.g. do 
1000 or 4000 files instead of 8000.  This shows any advantage gained by 
delaying I/O.  E.g. for 1000 files of 4k (4MB total), you may not see 
any writes during the initial creation, whereas with 8000 4k files (32MB), 
you may see quite a few writes.  The 8000 file numbers would be
a measure of sustained performance (e.g. NetNews hub, fileserving), 
while 1000 or 500 file numbers could be a measure of interactive 
performance, e.g. typing at the keyboard, untar a bunch of files (< a few 
MB worth of files), do a compile (create < a few MB worth of files).

For AdvFS, numbers for 8k and above seem pretty good:
 8k files can be written at about 960k/sec
 1.3MB/sec for 16k
 up to 1.75MB/sec for 64k

I'm interested in seeing numbers for smaller set, i.e. 500 and 1000 
files.  Linux for example, can create 8kb files at 127 files/sec if it
only has to do 500 of them vs. 25 files/sec on the SparcServer 
1000.  The addition of NVRAM on the SparcServer boosts that to 266
files/sec.

I tested two machines with this 'benchmark':

Machine #1:
        OS: Linux
        CPU: 486DX/66 (66MHz) vesa local bus
        Filesystem: Linux ext2fs
        Main memory: 16MB
        Controller: Adaptec 1542
        Disk: ST11200N, 3500KB/sec b/w
        Stats:  10MB/sec main memory bandwidth, 1.7MB/sec (sequential writes)
                to disk through controller.

Machine #2:
        OS: Solaris 2.3
        CPU: SuperSparc SuperCache 50MHz (SparcServer 1000)
        Filesystem: UFS
        Main memory: 128MB
        Controller: Onboard SCSI2-fast
        Disk: ST31200N, 4100KB/sec
        Stats: 40MB/sec main memory bandwidth, 4.1MB/sec (sequential writes)
                to disk through controller
        Configuration #1: no write accelerator
        Configuration #2: 4MB NVSIMM write accelerator (aka. Presto)

All in all, the tests say that Linux ext2fs can outperform stock UFS
on slower hardware by a significant margin (factor of 2 to 8 for 1k to 8k
files) for non trivial numbers (500-4000 files).

                                                        -Case Larsen
                                                        ctlarsen@lbl.gov
----long list of numbers to follow---


For example, on Linux (486DX/66 with a ST11200N disk):
0 byte/files:100 files:602.104959 files/second
0 byte/files:500 files:342.995282 files/second
0 byte/files:1500 files:141.095425 files/second
0 byte/files:2000 files:113.439649 files/second
0 byte/files:4000 files:57.212904 files/second
0 byte/files:8000 files:28.754965 files/second
1024 byte/files:100 files:722.830605 files/second
1024 byte/files:500 files:357.538704 files/second
1024 byte/files:1500 files:142.382291 files/second
1024 byte/files:2000 files:106.508574 files/second
1024 byte/files:4000 files:56.045037 files/second
1024 byte/files:8000 files:28.125228 files/second
2048 byte/files:100 files:465.224471 files/second
2048 byte/files:500 files:294.299767 files/second
2048 byte/files:1500 files:117.473520 files/second
2048 byte/files:2000 files:95.386166 files/second
2048 byte/files:4000 files:51.520444 files/second
2048 byte/files:8000 files:26.732482 files/second
4096 byte/files:100 files:420.636423 files/second
4096 byte/files:500 files:274.271220 files/second
4096 byte/files:1500 files:93.512741 files/second
4096 byte/files:2000 files:81.971355 files/second
4096 byte/files:4000 files:46.101395 files/second
4096 byte/files:8000 files:25.154955 files/second
8192 byte/files:100 files:369.665268 files/second
8192 byte/files:500 files:126.773498 files/second
8192 byte/files:1500 files:71.998705 files/second
8192 byte/files:2000 files:60.053802 files/second
8192 byte/files:4000 files:39.126569 files/second
8192 byte/files:8000 files:23.504405 files/second
16384 byte/files:100 files:224.498134 files/second
16384 byte/files:500 files:57.477098 files/second
16384 byte/files:1500 files:44.398989 files/second
16384 byte/files:2000 files:38.046475 files/second
16384 byte/files:4000 files:27.451643 files/second
65536 byte/files:100 files:19.297163 files/second
65536 byte/files:500 files:15.253890 files/second
65536 byte/files:1500 files:14.030679 files/second
131072 byte/files:100 files:8.389856 files/second
131072 byte/files:500 files:7.600187 files/second


On SparcServer 1000, 128MB memory, no write accelerator, normal UFS,
ST31200N disk,

0 byte/files:100 files:44.312276 files/second
0 byte/files:500 files:43.757529 files/second
0 byte/files:1500 files:40.641805 files/second
0 byte/files:2000 files:39.001449 files/second
0 byte/files:4000 files:32.233209 files/second
0 byte/files:8000 files:25.087129 files/second
1024 byte/files:100 files:44.269825 files/second
1024 byte/files:500 files:43.073898 files/second
1024 byte/files:1500 files:31.713670 files/second
1024 byte/files:2000 files:28.782177 files/second
1024 byte/files:4000 files:23.514462 files/second
1024 byte/files:8000 files:19.517980 files/second
2048 byte/files:100 files:40.950209 files/second
2048 byte/files:500 files:42.776448 files/second
2048 byte/files:1500 files:32.522234 files/second
2048 byte/files:2000 files:28.408258 files/second
2048 byte/files:4000 files:22.568856 files/second
2048 byte/files:8000 files:19.228756 files/second
4096 byte/files:100 files:44.239762 files/second
4096 byte/files:500 files:40.796338 files/second
4096 byte/files:1500 files:29.064245 files/second
4096 byte/files:2000 files:26.350862 files/second
4096 byte/files:4000 files:22.407641 files/second
4096 byte/files:8000 files:19.101444 files/second
8192 byte/files:100 files:44.513807 files/second
8192 byte/files:500 files:35.829555 files/second
8192 byte/files:1500 files:24.617763 files/second
8192 byte/files:2000 files:24.926471 files/second
8192 byte/files:4000 files:20.685662 files/second
8192 byte/files:8000 files:18.204164 files/second
16384 byte/files:100 files:44.724059 files/second
16384 byte/files:500 files:30.803938 files/second
16384 byte/files:1500 files:23.431537 files/second
16384 byte/files:2000 files:22.221013 files/second
16384 byte/files:4000 files:20.179176 files/second
65536 byte/files:100 files:18.743218 files/second
65536 byte/files:500 files:15.353219 files/second
65536 byte/files:1500 files:11.277214 files/second
131072 byte/files:100 files:8.095716 files/second
131072 byte/files:500 files:6.423027 files/second

And on SparcServer 1000, with 4MB NVSIMM write accelerator, I get:
0 byte/files:100 files:454.312103 files/second
0 byte/files:500 files:380.245197 files/second
0 byte/files:1500 files:248.237390 files/second
0 byte/files:2000 files:208.917017 files/second
0 byte/files:4000 files:128.662900 files/second
0 byte/files:8000 files:75.904740 files/second
1024 byte/files:100 files:401.761322 files/second
1024 byte/files:500 files:163.154973 files/second
1024 byte/files:1500 files:152.140973 files/second
1024 byte/files:2000 files:130.117759 files/second
1024 byte/files:4000 files:80.909055 files/second
1024 byte/files:8000 files:50.787231 files/second
2048 byte/files:100 files:403.679946 files/second
2048 byte/files:500 files:328.801787 files/second
2048 byte/files:1500 files:136.374050 files/second
2048 byte/files:2000 files:115.508387 files/second
2048 byte/files:4000 files:77.496927 files/second
2048 byte/files:8000 files:52.562421 files/second
4096 byte/files:100 files:391.308261 files/second
4096 byte/files:500 files:316.301549 files/second
4096 byte/files:1500 files:122.783713 files/second
4096 byte/files:2000 files:109.107908 files/second
4096 byte/files:4000 files:78.231191 files/second
4096 byte/files:8000 files:51.687208 files/second
8192 byte/files:100 files:371.351012 files/second
8192 byte/files:500 files:265.959710 files/second
8192 byte/files:1500 files:99.809603 files/second
8192 byte/files:2000 files:100.119588 files/second
8192 byte/files:4000 files:62.578623 files/second
8192 byte/files:8000 files:45.223094 files/second
16384 byte/files:100 files:220.967617 files/second
16384 byte/files:500 files:219.798190 files/second
16384 byte/files:1500 files:98.374015 files/second
16384 byte/files:2000 files:68.778383 files/second
16384 byte/files:4000 files:49.978416 files/second
65536 byte/files:100 files:99.310191 files/second
65536 byte/files:500 files:62.352552 files/second
65536 byte/files:1500 files:39.066414 files/second
131072 byte/files:100 files:20.424741 files/second
131072 byte/files:500 files:18.012809 files/second


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

From: xmsb@borland.com (the MOST SIGNIFICANT bit)
Subject: Re: Linux game development (Was Re: Why [DOS, W
Date: Fri, 3 Jun 1994 19:49:22 GMT

ac3slh@sunc.sheffield.ac.uk (Stuart Herbert) writes:


>No thanks.  I for one loathe running stuff as root.  I'd rather see developers

    interesting.  You are aware, of course, that under
    Windows, EVERYTHING is running "as root"....

    multi-user, multi-tasking, protected memory (protected
    by the OS, not some overblown TSR/dpmi crud)

    just a few of the things I like about linux/unix.
    of course, it makes a lousy platform for Windows
    development... :)

--
Maurice S. Barnum               ==    I speak for me, not my employer.
xmsb@borland.com                ||    "There is no confusion like the
mosigbit@deeptht.armory.com     ||    confusion of a simple mind."
mbarnum@nyx.cs.du.edu           ==       -- F. Scott Fitzgerald

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

From: heistp@brtph602.bnr.ca (Mike Baptiste P275)
Subject: Re: 1.1.16 kernel doesn't want to boot!
Date: Fri, 3 Jun 1994 13:58:43 GMT
Reply-To: heistp@rpi.edu

After putting the new kernel in your root directory did you remember to
rerun lilo?  That's what lilo says if your kernel changes and you didn't
rerun lilo before rebooting.  Remedy the problem by botting from a floppy,
mounting your HD, and running lilo from it.

In article <2sl62q$pvs@aurora.engr.latech.edu>, ramos@engr.latech.edu (Alex Ramos) writes:
|> Eugene Tyurin (gene@insti.physics.sunysb.edu), quoted out of context, wrote:
|> >            crc error
|> >            System halted
|> 
|> It sounds like a hardware error to me.  I _think_ this is the error
|> message I got on a machine that had a lose (wobbly) SIMM. (it booted
|> DOS fine though).
|> 
|> --
|> Alex Ramos (ramos@engr.latech.edu) * http://info.latech.edu/~ramos/
|> Louisiana Tech University, BSEE/Sr * These opinions are probably mine

-- 
====================================================================
|      Pete Heist of NT Bell Northern Research V.O. Support        |
====================================================================

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


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