Subject: Linux-Development Digest #8
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:     Tue, 9 Aug 94 15:13:15 EDT

Linux-Development Digest #8, Volume #2            Tue, 9 Aug 94 15:13:15 EDT

Contents:
  1.1.36 -> 1.1.41 - Something broke ESDI support! (Eric Kimminau)
  Re: FPE signal problem (Help) (Olaf Flebbe)
  top - problems compiling (Robert Gasch)
  Re: iso9660 file system post (Jinwoo Shin)
  Thanks (EHippo)
  Re: Repost: *MATROX* Support ? (Gary Schrock)
  Re: Repost: *MATROX* Support ? (Rene COUGNENC)
  Re: Repost: *MATROX* Support ? (Derek Seabury)
  Re: lint for linux (Jonathan Magid)
  IO ports (Riku Saikkonen)
  1.1.39 and lost modem characters (David Kenneth Slack)
  Re: Repost: *MATROX* Support ? (phil@milo.math.scarolina.edu)
  Proposal to write a SAMBA fs client for the kernel (Matthew Grant)
  Re: SLIP, CSLIP, PPP and modems (Matthew Dillon)
  Re: SLIP, CSLIP, PPP and modems (Matthew Dillon)

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

From: ekimmina@eve180.cpd.ford.com (Eric Kimminau)
Subject: 1.1.36 -> 1.1.41 - Something broke ESDI support!
Date: 9 Aug 1994 12:02:06 GMT

In article <321dmh$dmo@sun.cais.com>, ericy@cais2.cais.com (Eric Youngdale) writes:
|> In article <yeul.776016964@marsh>, Loong Yeu <yeul@cs.curtin.edu.au>  
|>  
|> >Kernel panic : scsi_devices corrupt (sd)
|> >In swapper task - not syncing
|> 
|>      This problem should have been corrected in 1.1.40.  The problem 
|> with out of mailboxes may also have been fixed along with a bunch of 
|> other assorted things.
|> 
|>      Some people have complained about problems with isofs because it
|> would modify the contents of the buffer cache (both filenames and file
|> contents), depending upon the mapping options selected.  Other people have
|> complained about problems with incorrect backlinks and so forth. I believe
|> that all of these problems are also now fixed in 1.1.40.  There were some 
|> fast and furious patches at the last minute and I am not 100% sure that 
|> isofs is completely stable, but if there are problems they should show up 
|> right away and a quick fix would get things back on track.
 
I upgraded from 1.1.36 to 1.1.41 last night. 1.1.36 works perfectly. I have a 
486/33, 16MB Ram and a Western Digital 1007WAH ESDI controller with 16K H/W 
cache onboard. It has worked perfectly since 99.14. After the upgrade to 1.1.41, I 
get failures trying to read SuperBlock for xiafs, EXT, EXT2, and MSDos type file
 systems on hda1 and then a kernel panic. There is also a similar message to the 
one above about the device being corrupt. The machine is locked cold. I can drop 
back to 1.1.36 and everything works wonderfully. I would paste the exact messages 
in, but the primary partition is never mounted so no log files are ever written.

Any help would be greatly appreciated.



---
    Eric Kimminau  ekimmina@eve180.cpd.ford.com  Ford Motor Co.
    (313)845-55361      "I am not an official Ford spokesperson"
 

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

From: flebbe@pluto.tat.physik.uni-tuebingen.de (Olaf Flebbe)
Subject: Re: FPE signal problem (Help)
Date: 9 Aug 94 11:35:15 GMT

s3176015@techst02.technion.ac.il (Studnitzky Boaz ) writes:

>Hi, i am wondering if anyone can tell me why the following code
>produces an FPE exception after the addition ....

>#include <stdio.h>
>#include <signal.h>

>void fp_ex(int sig)
>{
>  printf("FPE\n");
>}

>void init_signals(void)
>{
>  struct sigaction a;
>  a.sa_handler=fp_ex;
>  a.sa_mask=0;
>  a.sa_flags=SA_RESTART;
>  a.sa_restorer=NULL;
>  sigaction(SIGFPE,&a,NULL);
>}

>main()
>{
>  double a,b,c;
>  init_signals();
>  a=1;
>  b=0;
>  printf("1\n");
>  c=a/b;
>  printf("2\n");
>  a=b+1;
>  printf("3\n");
>  printf("a=%f\n",a);
>}

>I would appreciate any comments on the above code, or the behavior.

1) Floating point exceptions are raised for the *next* floating point
operation after a illegal operation was made. This is due to the
design of the i387.

2) Therefore you cannot trap the exceptions, like you want to.

3) Try the libieee.a library to trap all exceptions and enabling
  a IEEE 765 conformant behaviour.

olaf



-- 
  Olaf Flebbe,  Theoretische Astrophysik Tuebingen
  Internet:     flebbe@tat.physik.uni-tuebingen.de
  http://aorta.tat.physik.uni-tuebingen.de/~flebbe

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

From: rgasch@nl.oracle.com (Robert Gasch)
Subject: top - problems compiling
Date: Tue, 9 Aug 1994 07:07:10 GMT


Hi,

I want to compile top as I want to see if I can use some of it's code 
for a graphical utility. I've gotten the sources (top.c, ps.h, psdata.h)
of the /slacksrc of the second infomagic CDROM. There are a few error 
where task.c  and some macros it uses refer to a structure mm within 
struct task (mm doesn't exist) but these are easy to clean up. I'm stuped 
by this one though:
        tcp.c:610 invalid type argument of `->'
Looking at the code I see 
        dev_to_tty (TASK_TTY(task))
which expands to
        ((task)->tty ? (task)->tty->device : -1)

struct task is defined in sched.h and contains the following entry for tty:
        int tty;        /* -1 if no tty, so it must be signed */

Struct task does not contain an entry for device and tty is not a pointer, 
so my question is, where what should TASK_TTY expand to so that it works 
correctly with the above definitions? BTW, this is kernel 1.0.9.

Thanks a lot
--> robert
rgasch@nl.oracle.com

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

From: jwshin@nitride.EECS.Berkeley.EDU (Jinwoo Shin)
Subject: Re: iso9660 file system post
Date: 9 Aug 94 12:17:43 GMT

riku.saikkonen@compart.fi (Riku Saikkonen) writes:

>>Has anyone else noticed that the iso9660 filesystem is hosed in
>>v1.1.41 (I compiled this version of the kernel and it hangs trying to
>>mount my cdrom).  My cd is a Sony cdu31a - it worked up to patch level
>>36 - I haven't tried the levels between this and 41.  Is there some
>>explanation for this??

Though I don't have sony, my mitsumi works fine with 1.1.41.
-- 
Jinwoo Shin                             jwshin@eecs.berkeley.edu
System Administrator                    
Berkeley Sensor and Actuator Center

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

From: ehippo@aol.com (EHippo)
Subject: Thanks
Date: 9 Aug 1994 08:56:02 -0400

Thanks to one and all.  Sometimes, when you look over a program so hard it
is
hard to see the forest for the trees!  I had caught the memset args
problem but
forgot to update the program in the note.  MS-DOS BCC did compile with the
double * and run.  No wonder windows programs CRASH and BURN!!

Sorry for the post in this newsgroup.  'Development' can mean many things!
 I'll
post things like this to comp.lang.c as one poster commented.

Thanks again.

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

From: schrock@student.msu.edu (Gary Schrock)
Subject: Re: Repost: *MATROX* Support ?
Date: 9 Aug 1994 13:04:36 GMT

In article <IiFj63i00iV6086_4u@andrew.cmu.edu>, Michael Teper <mt3q+@andrew.cmu.edu> writes:
|> I would like to know what is the status of Matrox support under linux:
|> planned, in works, or implimented ?

I've been talking to the people at Matrox for the last several days, trying
to find out some information about things like availability of programming
information for the Matrox cards (note, said card will never be on a machine
running linux, so I'm not going to be developing Linux drivers for it).
Unfortunately, it's looking very strongly like they will not release information
without the signing of a nondisclosure agreement.  If this turns out to be
true, that could quite possibly explain why drivers don't seem to be under
development.

(Just idle speculation)

Gary Schrock
schrock@student.msu.edu

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

From: rene@renux.frmug.fr.net (Rene COUGNENC)
Subject: Re: Repost: *MATROX* Support ?
Date: 9 Aug 1994 04:49:35 GMT
Reply-To: cougnenc@hsc.fr.net (Rene COUGNENC)

Ce brave Michael Teper ecrit:

> I posted a question regarding support for Matrox MGA based video cards
> under Linux and have not received any sort of a response.  I find it

This is because you asked your question in the wrong group.
As far as XFree86 is concerned, the newsgroup where the XFree86 team
can be reached is comp.windows.x.i386unix; they don't read the
Linux groups: XFree86 is not Linux-specific.

BTW, I may be wrong but I think that Matrox is not supported, because
Matrox does'nt want to (sort of :-)). You'll get more details in
the right newsgroup I hope.

--
 linux linux linux linux -[ cougnenc@renux.frmug.fr.net ]- linux linux linux 

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

From: sseabury@zebra.cs.jhu.edu (Derek Seabury)
Subject: Re: Repost: *MATROX* Support ?
Date: 9 Aug 1994 14:33:13 GMT

In article <32802h$5c7@redwood.cs.scarolina.edu> phil@milo.math.scarolina.edu writes:
>     Dirk Hohndel wrote in article <Cu9839.EnM@aib.com> :
>>
>>Michael Teper (mt3q+@andrew.cmu.edu) wrote:
>>: I posted a question regarding support for Matrox MGA based video cards
>>: under Linux and have not received any sort of a response.  I find it
>>: hard to believe that NOONE has both a Matrox card and a system running
>>: Linux (especially considering that Matrox makes some of the fastest
>>: video accelerators on the market).
>>
>>Might be a reason that this question has been asked (and answered) so
>>many times, that no one bothered to answer again?
>>
>>: I would like to know what is the status of Matrox support under linux:
>>: planned, in works, or implimented ?
>>
>>: Any sort of a reply would be appreciated.
>>
>>: I am also curious how one would contact the XFree development team with
>>: a video card support request.
>>
>>The contact address would be XFree86@XFree86.Org, but I can give you the
>>answer right away: No, we don't support Matrox and most likely we never
>>will, as Matrox is not giving away the programming information without a
>>non disclosure agreement, which is a no-go for a FreeWare project like
>>XFree86.
>>
>>      Dirk
>>

Metrolink sells a set of XServers that run on most of the PC Unix systems.
They do support Matrox MGA (as well as Viper and other Linux nono cards) but
I don't think the Servers are all ported to Linux yet (they told me 2 months
about a month ago).  So til then, my Pentium/PCI MGA are the dedicated 
Autocad machine in my lab...

But oooh just wait!

Derek

(It will be fun to compare it to the Mach 64 I've got coming!)


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

From: jem@bittyblue.oit.unc.edu (Jonathan Magid)
Subject: Re: lint for linux
Date: 9 Aug 1994 15:00:13 GMT


There is a free lint on the 'Net called "LCLint", by David Evans
(evs@larch.lcs.mit.edu).  There are a few people working on a port 
to linux (I was going to be one of them but work and then vacation
caught up to me).  You can find the source on 
ftp://larch.lcs.mit.edu/pub/Larch/lclint1.3.src.tar.Z.  There was a first
stab at a linux port and it can be found in 
ftp://larch.lcs.mit.edu/pub/evs/linux-port.tar.Z.

jem.

-- 

<a href="http://sunsite.unc.edu/jem">A sig.</a>

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

Subject: IO ports
From: riku.saikkonen@compart.fi (Riku Saikkonen)
Date: Tue,  9 Aug 94 17:14:00 +0200

I have this problem in IO port programming under Linux:

I wrote the following program and tried to compile it:
***
#include <unistd.h>
#include <stdio.h>
#include <asm/io.h>

int main()
{
  if (!ioperm(0x378,3,1)) perror("ioperm");
  outb(0x37a,0);
  printf("%d\n",inb(0x379));
  exit(0);
}
***

gcc (gcc 2.4.5, libc 4.4.4, kernel 1.1.41) reported:
Undefined symbol ___outb referenced from text segment
Undefined symbol ___inb referenced from text segment

So, what am I doing wrong? It seems to me that the IO port routines are
defined (not just declared, defined inline) in asm/io.h. But gcc doesn't
seem to find them. And gcc -E leaves the port access routines as
__inb(0x379); and __outb((0x37a),(0));.

As to why I should be accessing the parallel port directly, I have a
measurement application that uses the control and status signals of the
parallel port extensively. I need to be able to access them all. The lp
driver in the kernel doesn't provide functions for direct access of the
signals, and I wouldn't want to modify the kernel if I can avoid it
(besides, it would likely be slower).

And that brings me to another question: What is the easiest way to wait
very short times in Linux? Doesn't need to be very exact, just short (1
or 2 microseconds or somewhere near that). Under MS-DOS, I poll the
retrace bit of the display adapter (since the measurement program works
only under EGA/VGA anyway). That might work in Linux too, but I'd rather
use a more reliable method (the retrace time changes quite a bit with
different displays and modes (e.g. in X)).

I could perhaps use the uclock timers but I would think that the
time-reading routine itself takes more than 1 us (a DOS routine that I
got took ~200 us!). Would setting up a signal handler work? Are there
other ways (I'd rather not go to the trouble of signal handlers just for
a wait...)? The wait is used in many parts of the same module.

-=- Rjs -=- riku.saikkonen@compart.fi - IRC: Rjs
GCS/L/M/TW/S -d+ H+ s:- !g !p !au a17 w+ v+(---) C++ UL++++() P+ L++ 3
E>++ N+++ K- W+(++) M- !V po Y+ t/Tolkien+++ !5 !j R G' tv-() b++ D++
B? e>+++ u+++@ h--! f+ !r>++ n+ !y+(*)

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

From: dks8475@u.cc.utah.edu (David Kenneth Slack)
Subject: 1.1.39 and lost modem characters
Date: 9 Aug 1994 08:50:11 -0600

        I'm running 1.1.39 (not 1.1.41 like I think the subject says)
with a 14.4 modem used for dial-in.  I am losing characters in a
strange way when I call in through the modem.  It seems that after a
certain number of characters are printed (a little over a screenfull)
I loose the rest.  For instance, if I do an ls -l /etc, I only get a
screenfull before I get the prompt back.  I have more than 25 files in
/etc.  It's as if the rest of the characters were just discarded.
        I have CTS/RTS enabled on both the modem and Linux (I checked
with stty -a, it says crtscts)
        Also, I seem to get spurts of line noise occasionally when I
call in through the modem...
        I have the modem on irq 9 port 0x2e8, which is (as far as I
know) unused by anything else.  Is this a problem?  Any other ideas?


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

From: phil@milo.math.scarolina.edu
Subject: Re: Repost: *MATROX* Support ?
Date: 9 Aug 1994 13:24:33 GMT

     Dirk Hohndel wrote in article <Cu9839.EnM@aib.com> :
>
>Michael Teper (mt3q+@andrew.cmu.edu) wrote:
>: I posted a question regarding support for Matrox MGA based video cards
>: under Linux and have not received any sort of a response.  I find it
>: hard to believe that NOONE has both a Matrox card and a system running
>: Linux (especially considering that Matrox makes some of the fastest
>: video accelerators on the market).
>
>Might be a reason that this question has been asked (and answered) so
>many times, that no one bothered to answer again?
>
>: I would like to know what is the status of Matrox support under linux:
>: planned, in works, or implimented ?
>
>: Any sort of a reply would be appreciated.
>
>: I am also curious how one would contact the XFree development team with
>: a video card support request.
>
>The contact address would be XFree86@XFree86.Org, but I can give you the
>answer right away: No, we don't support Matrox and most likely we never
>will, as Matrox is not giving away the programming information without a
>non disclosure agreement, which is a no-go for a FreeWare project like
>XFree86.
>
>       Dirk
>-- 
> _____ _         __  _____            ___  __    ___          _        _   
>|_   _| |_  ___  \ \/ / __| _ ___ ___( _ )/ /TM | _ \_ _ ___ (_)___ __| |_ 
>  | | | ' \/ -_)  >  <| _| '_/ -_) -_) _ \ '_ \ |  _/ '_/ _ \| / -_) _|  _|
>  |_| |_||_\___| /_/\_\_||_| \___\___\___/\___/ |_| |_| \___// \___\__|\__|
>

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

From: grantma@ritz.equinox.gen.nz (Matthew Grant)
Subject: Proposal to write a SAMBA fs client for the kernel
Date: Tue, 9 Aug 1994 10:31:18 GMT

Hi There!

As you all know, the SAMBA server and ftp like amba client are available for
Linux, and they do work.  In the view of the insecurity of NFS mounts in
Unversity set ups, the mounting of the users file system by a whole lot of
Linux bixes is greatly discouraged.  A SAMBA fs client in the kernel would 
offer a way out for us all.  With the upcoming release of 1.2.0, I propose
to port/write this for the kernel based on the 1.2.x source for patching
into 1.3.x or for use with the 1.2.0 kernel.  

Does anyone have any ideas on what the best architecture for this would be
as I would like to be able to pump 1 MB/s through it, as I have seen how
slow nfs is at present.  Will I have to tie it tightly into the buffer
cache? etc.  Any info would be appreciated.  I have an idea that read-only
file systems could be made quite fast in the area of multiple mounts with
client buffering, but how do you make file system write very fast?  I am
asking because I want to get the design right.  I also guess aggod book on
networking and file system architecture would come in handy.

Cheers,

Matthew Grant.


-- 
    _/  _/   __/   _/_/_/ _/_/_/ _/  _/  _/_/  _/  _/     Matthew A. Grant
   _/_/_/  _/  _/   _/     _/   _/_ _/  _/_   _/  _/    1 Domain Tce, Chch. NZ.
  _/  _/  _/_/_/   _/     _/   _/_/_/  _/    _/_/_/   (03) 338-4287
 _/  _/  _/  _/   _/     _/   _/  _/  _/_/  _/  _/  grantma@ritz.equinox.gen.nz      

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

From: dillon@apollo.west.oic.com (Matthew Dillon)
Subject: Re: SLIP, CSLIP, PPP and modems
Date: 8 Aug 1994 21:26:13 -0700

:In article <324m8e$5c3@smurf.noris.de> urlichs@smurf.noris.de (Matthias Urlichs) writes:
:>In comp.os.linux.development, article <Cu4rDn.F4w@cs690-3.erie.ge.com>,
:>  teffta@csp195.erie.ge.com (Andrew R. Tefft) writes:
:>> 
:>> If you watch while you're doing an ftp transfer over ppp, a lot of
:>> acks go from the receiver to the sender. If you watch an interactive
:>> ...
:>> 
:>This should not be a problem, though; TCP should be able to use almost the
:>full bandwidth regardless of delayed ACKs.
:>
:>What's confusing to TCP (warning: SWAG follows) is the high variance in the
:>ACK timings, i.e. sometimes an ACK arrives almost immediately but sometimes
:>it has to wait behind several TCP packets from the other transfer.
:>
:>My guess: If SLIP had several queues and would enqueue TCP ACKs ahead of
:>"interactive" packets ahead of "normal" packets, transfer times would
:>improve considerably.
:...

    The problem is two fold:

    (1) The TCP window size is much too large for a SLIP connection, even
        an internet SLIP connection.  Try recompilng your kernel with 
        2048 byte receive and transmission windows.  Under the most recent 
        test kernels you can specify the receive window in the routing 
        tables (but not the transmit window).

    (2) Linux does not prioritize the transmission of ACKs in its packet
        queue.  This means that if you do a download and an upload at the
        same time, or if you do multiple downloads or uploads
        simultaniously, packets will not be interleaved and ACK variance
        will become ridiculously bad, causing retransmissions and delays.

    (3) Delayed acks are not an issue.  Really, the problem has nothing to
        do with delayed acks.

    Reducing the transmit and receiver TCP window size helps.  Unfortunately
    the problem scales so there is no way to get rid of it until the
    packet buffering is fixed.

                                                    -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: dillon@apollo.west.oic.com (Matthew Dillon)
Subject: Re: SLIP, CSLIP, PPP and modems
Date: 8 Aug 1994 21:52:50 -0700

:In article <bart.82.0009445F@dunedin.es.co.nz> bart@dunedin.es.co.nz (Bart Kindt) writes:
:>In article <1994Aug5.221334.16623@brtph560.bnr.ca> denebeim@bnr.ca (Jay Denebeim P025) writes:
:>>From: denebeim@bnr.ca (Jay Denebeim P025)
:>>Subject: Re: SLIP, CSLIP, PPP and modems
:>>-- 
:>>Jay Denebeim     Address: UUCP:     duke!wolves!deepthot!jay
:>
:>Hmmm. FTP is a protocol which is designed to cooperate with other TCP/IP 
:>traffic on the same line.  The 'retry' of packets which somehow got damaged 
:>will slow the transfer down really heavy.  While I don't know the exact 

    This is not correct.  FTP *uses* TCP/IP, but it is most decidedly NOT
    designed to cooperate with other traffic on the same line...  i.e. FTP
    does not do any bandwidth limiting in of itself, though some ftp servers
    will try to. (that is not part of the protocol though).

:figures, it goes something like this:  Packet send; no reply? try again after 
:1 second; still no reply? Wait for *double* the last period: 2 seconds; Then 
:*double* again: 4 seconds.  Etc...  This is not completey correct, but you get 
:the picture.  What does this mean in practice?  If you have even a little bit 
:of problems on the line, and this includes things like Overruns due to bad 
:handshaking, the FTP (and any TCP/IP) will slow down badly.  I have done some 
:tests by disabling / enabling the Error Protection of the modem; In my case, 
:without error protection the system slowed down to a crawl. Why? Not because 
:the line was *that* bad, but because even a few lost packets will cause this.

    This is true.  There are two prevalient problems with people's modem/line
    configurations:

    (1) You are not running with hardware handshaking

    (2) You are going to fast for your modem chips.  A PC with 16450 serial
        chips CANNOT GO FASTER THEN 19200 WITHOUT LOOSING CHARACTERS IN A
        [C]SLIP CONNECTION.  For example, if you run at 38400, you will most
        likely get a receiver overrun every 50 or so packets on a DX2/66.
        With a 16550 you can go much faster.
        

:Also, make sure you do *NOT* have XON/XOFF enabled in your modems!! SLIP does 
:NOT like to find these allien characters in its packets!  You *must* use 
:hardware handshaking.

     Heh.  Correct.  It must be hardware handshaking.  Neither can you simply
     turn handshaking off... that really screws things up.

:Still, I have also seen the 'slow' throughput over my SLIP connection. 
:I would like somebody to try the following: 
:Download a ZIPed file with FTP and check the speed.  Now open a *second* FTP 
:session, and download the same file *twice* at the same time.  It would not 
:surprise me if the total throughput would be a lot higher, because the FTP 
:transfers would make use of the *pauses* of the other one; This is ofcourse 
:how TCP/IP works.  

     This really has nothing to do with FTP, it is a natural consequence
     of packet queueing.  However, if your TCP receiver window is too
     large, too many packets can backup on the router side of the SLIP line
     causing it to drop some of them.

     Here is it with 1, 2, and 3 simultanious downloads via CSLIP to my local
     internent provider, using a receiver window size of 2048 and 8192

=========== receiver window of 2048 ==========
ncftp>get 11-newpk.ps
11-newpk.ps: 47621 bytes received in 13.00 seconds, 3.58 K/s. (x1 = 3.58 K/s)
news.greatbasin.net:/info
ncftp>get 11-newpk.ps
11-newpk.ps: 47621 bytes received in 19.71 seconds, 2.36 K/s. (x2 = 4.72 K/s)
news.greatbasin.net:/info
ncftp>get 11-newpk.ps
11-newpk.ps: 47621 bytes received in 28.61 seconds, 1.63 K/s. (x3 = 4.89 K/s)
news.greatbasin.net:/info
ncftp>

=========== receiver window of 8192 ==========
ncftp>get 11-newpk.ps
11-newpk.ps: 47621 bytes received in 10.94 seconds, 4.25 K/s. (x1 = 4.25 K/s)
news.greatbasin.net:/info
ncftp>get 11-newpk.ps
11-newpk.ps: 47621 bytes received in 18.74 seconds, 2.48 K/s. (x2 = 4.96 K/s)
news.greatbasin.net:/info
ncftp>get 11-newpk.ps
11-newpk.ps: 47621 bytes received in 26.62 seconds, 1.75 K/s. (x3 = 5.25 K/s)
news.greatbasin.net:/info
ncftp>

    There you have it.  However, take a look at this:  A download and
    an upload at the same time with a 4096 byte window for transmit and 
    an 2048 byte window for receive.

============ 4K transmit window, 2K receiver window ==========
ncftp>get 11-newpk.ps
11-newpk.ps: 47621 bytes received in 17.90 seconds, 2.60 K/s.
news.greatbasin.net:/info
ncftp>

ncftp>put delete_me_test3
delete_me_test3: 47621 bytes sent in 20.05 seconds, 2.32 K/s.
news.greatbasin.net:/incoming
ncftp>

    Now with a 4096 byte transmit window and an 8192 byte receiver window

============ 4K transmit window, 8K receiver window ==========
ncftp>get 11-newpk.ps
11-newpk.ps: 47621 bytes received in 12.36 seconds, 3.76 K/s.
news.greatbasin.net:/info

ncftp>put delete_me_test2
delete_me_test2: 47621 bytes sent in 18.88 seconds, 2.46 K/s.
news.greatbasin.net:/incoming
ncftp>

    As you can see, the transfer rate is no where near as efficient
    when going in both directions at the same time.  The problem is
    mainly due to varience of ACK buffering.  It becomes obvious with
    a 2048 byte window.  One would expect that an 8K window would solve
    the problem but even 8K doesn't help.

    BTW the MTU for the connection is 576 (512 bytes of data per packet).


                                        -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!]


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


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