519 lines
23 KiB
Plaintext
519 lines
23 KiB
Plaintext
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: Sun, 4 Sep 94 13:13:05 EDT
|
|
Subject: Linux-Development Digest #118
|
|
|
|
Linux-Development Digest #118, Volume #2 Sun, 4 Sep 94 13:13:05 EDT
|
|
|
|
Contents:
|
|
Re: Not all memory seen on Compaq Deskpro M (EISA) (Rob Janssen)
|
|
Re: DOSEMU 0.53: Developers and testers needed! (Rob Janssen)
|
|
Re: more than 2 COM ports at the same time (Rob Janssen)
|
|
Re: [DOSEMU][SERIAL] Incorrect Parity bits? (Rob Janssen)
|
|
Re: PRIORITY make an undelete command (David Herron)
|
|
Re: XFree & CDROM slow down transfer rate (Rob Coursey)
|
|
Re: Mosaic and other TCP/IP problems (Bart Kindt)
|
|
Re: SOCK_PACKET: Why not reading outgoing packets ? (Alan Cox)
|
|
Re: Linux - my first impressions (Humberto Ortiz Zuazaga)
|
|
Re: DOSEMU 0.53: Developers and testers needed! (Harry C Pulley)
|
|
Re: more than 2 COM ports at the same time (Harry C Pulley)
|
|
polled ports (Harry C Pulley)
|
|
Re: Mosaic and other TCP/IP problems (Stewart Allen)
|
|
|
|
----------------------------------------------------------------------------
|
|
|
|
From: rob@pe1chl.ampr.org (Rob Janssen)
|
|
Subject: Re: Not all memory seen on Compaq Deskpro M (EISA)
|
|
Reply-To: pe1chl@rabo.nl
|
|
Date: Sun, 4 Sep 1994 10:38:22 GMT
|
|
|
|
In <3478e2$m45@Athena.McRCIM.McGill.EDU> panisset@CIM.McGill.CA (Jean-Francois Panisset) writes:
|
|
|
|
>I have a Compaq Deskpro 486/33M, which is an EISA bus machine with the
|
|
>processor on a card. The machine has 20M of RAM, which is happily seen
|
|
>by the power-on test, the EISA diagnostics/setup disk and
|
|
>DOS. Unfortunately, neither the 1.0.8 nor the 1.1.49 kernels see more
|
|
>than 8Mb of this memory. Does anyone have any ideas why this might be?
|
|
>I compiled the kernels with the "limit memory to low 16Mb" option set
|
|
>to no. For reference, the machine also contains a WD80x3 Ethernet
|
|
>board and an ATI GUP video board. Could the fact that the GUP is
|
|
>mapping its frame buffer into the address space be a problem? (but
|
|
>then, it should also be on another machine, a Dell EISA with 32Mb and
|
|
>a GUP: the kernel happily sees all the memory on that machine).
|
|
|
|
The kernel gets the amount of memory by calling INT 15H, function 88H,
|
|
before going into protected mode. This function should return the
|
|
"number of Kbytes of extended memory". Probably the problem is somewhere
|
|
here...
|
|
|
|
In the past, there was an option "mem=xxxx" to override the amount of
|
|
memory, which was necessary for systems with more than 64M. However,
|
|
now that I look in the 1.1.49 sources this is no longer there :-(
|
|
|
|
You can try this with 1.0.8, maybe it did have this option (I'm not sure).
|
|
|
|
No idea why the "number of Kbytes of extended memory" is not working...
|
|
|
|
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: DOSEMU 0.53: Developers and testers needed!
|
|
Reply-To: pe1chl@rabo.nl
|
|
Date: Sun, 4 Sep 1994 10:42:37 GMT
|
|
|
|
In <34amdt$4sn@nermal.cs.uoguelph.ca> hpulley@uoguelph.ca (Harry C Pulley) writes:
|
|
|
|
>The only problem I have has to do with using more than 2 serial ports. I want
|
|
>to run my XT laptop as a terminal off of COM4 but my mouse is on COM2. When I
|
|
>try to use both at the same time nothing works from the terminal and the mouse
|
|
>doesn't respond either. Would it work better if I shared COM3 with my mouse
|
|
>since COM3 is a 16550? I must look at the serial code to see if there is
|
|
>something I can do. It would be nice if someone could run WP6.0 on the console
|
|
>while I run off the terminal *and* the person could use the mouse under DOS.
|
|
|
|
Unless you have modified the hardware, COM2 and COM4 are not going to
|
|
work at the same time. This is not related to DOSEMU, but to PC hardware
|
|
design. They use the same IRQ and cannot share it when they are located
|
|
on different boards. (and when they are on the same board, they can
|
|
only share it when the manufacturer was clever)
|
|
Check the FAQ of comp.sys.ibm.pc.hardware.comm for an explanation.
|
|
|
|
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: more than 2 COM ports at the same time
|
|
Reply-To: pe1chl@rabo.nl
|
|
Date: Sun, 4 Sep 1994 10:50:31 GMT
|
|
|
|
In <34amhe$4sn@nermal.cs.uoguelph.ca> hpulley@uoguelph.ca (Harry C Pulley) writes:
|
|
|
|
>I am trying to run with a mouse on COM2, modem on COM3 and terminal on COM4.
|
|
>Whenever I use both the mouse (COM2) and the terminal (COM4) at the same time I
|
|
>get no response from either. Is there any code around for sharing IRQs? If
|
|
>not, then is there any code for using one of the ports in a polled mode instead
|
|
>of interrupt driven?
|
|
|
|
Please read that FAQ that I pointed to in another thread.
|
|
Sharing IRQs is not a matter of code, it is a HARDWARE problem which you
|
|
are not going to solve in code.
|
|
|
|
You CAN use the ports in polled mode by specifying irq 0 to setserial,
|
|
but you are not going to like the results. Maybe it just works for the
|
|
mouse.
|
|
|
|
>If nothing exists then I will work on it myself. I just want to know what
|
|
>already exists out there.
|
|
|
|
I think the whole world will be thankful to you when you solve this
|
|
problem! It is considered a major limitation in the PC ISA architecture.
|
|
|
|
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: [DOSEMU][SERIAL] Incorrect Parity bits?
|
|
Reply-To: pe1chl@rabo.nl
|
|
Date: Sun, 4 Sep 1994 11:01:51 GMT
|
|
|
|
In <1994Sep3.205002.248@nbi.com> jgeorge@nbi.com (Joe George) writes:
|
|
|
|
|
|
>Hello all,
|
|
|
|
>I'm sending this message to a few different places because while I know what
|
|
>problem I'm having, I'm at a loss to figure out exactly *where* the
|
|
>breakdown is occurring.
|
|
|
|
>I need to run a rather odd communications program that runs under MSDOS and
|
|
>requires(!) 7 bit, mark parity, 1 stop bit settings. I've run this
|
|
>successfully under MSDOS, and it ran successfully under Linux and DOSEMU
|
|
>before the TTY patches were introduced into the kernel (1.1.13?). Now, under
|
|
>DOSEMU (pre53_17 but also others) and Linux (1.1.49 and others as well) I
|
|
>get a lot of dropped characters - actually, let me correct myself. The
|
|
>characters are not dropped but the "mark" parity isn't dealt with properly
|
|
>so I get garbage. I can also duplicate this under Qmodem 4.5 (under DOSEMU)
|
|
>by setting the comm settings to 7-mark-1 and getting the exact same form of
|
|
>character corruption, so it's not specific to my odd comm program.
|
|
|
|
Actually, UNIX/Linux does not support 7M1 directly.
|
|
There is an option "parmrk" in the stty settings, but it means something
|
|
different (it inserts a specicial sequence in the input stream when a
|
|
character was received with parity error).
|
|
|
|
To have 7M1, you will have to set 8N1 to the UNIX port drivers, and
|
|
add/check/remove the mark parity bit yourself in the application
|
|
software, where it appears in the high bit of each character.
|
|
|
|
From your description, it looks like DOSEMU does not support this,
|
|
misreads your intent, and sets 7E1 or 7O1 instead.
|
|
|
|
Can you solve this yourself in DOSEMU? (I am not sure if you are
|
|
a programmer)
|
|
|
|
Rob
|
|
--
|
|
=========================================================================
|
|
| Rob Janssen | AMPRnet: rob@pe1chl.ampr.org |
|
|
| e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU |
|
|
=========================================================================
|
|
|
|
------------------------------
|
|
|
|
From: davidh@crl.com (David Herron)
|
|
Subject: Re: PRIORITY make an undelete command
|
|
Date: 2 Sep 1994 00:23:43 -0700
|
|
|
|
I'm going to toss out an idea that's been floating around my head
|
|
for a few months. Unfortunately it will require a file system
|
|
change in order to implement.
|
|
|
|
When you unlink(2) a file (the last time) one would change the action.
|
|
Rather than free all the blocks and deallocate the inode the inode
|
|
should be placed on a chain of freeable inodes. When the file system
|
|
is "out of space" then enough of these freeable inodes should be free'd
|
|
(blocks freed and inodes deallocated) to create free space. The chain
|
|
of freeable inodes should be a LIFO queue. Somewhere in the chain of
|
|
freeable inodes should be kept a list of the files names, preferably a
|
|
full/partial pathname, but at least the basename. It would only be
|
|
possible to keep the last name it had as knowledge of previous links
|
|
would be lost by that point.
|
|
|
|
Shouldn't be all that hard to implement.
|
|
|
|
Some kernel calls will need to be added to peruse the list of these
|
|
freeable inodes, relink items on the list, and force inodes to be
|
|
freed. df(1) might be changed, as well as the system calls it uses, to
|
|
show freeable blocks/inodes in addition to used/available.
|
|
|
|
From that an undelete command can be written which shows the user
|
|
the list of available files to retrieve, much like "vi -r" shows the
|
|
list of recoverable files or the Mac trashcan folder shows deleted
|
|
files. You can also implement "empty trash", and the system will also
|
|
automatically empty old files after an indeterminate time (as needed).
|
|
|
|
The only downside I can think of is the file system might end up
|
|
more fragmented than it is now.
|
|
|
|
David
|
|
|
|
|
|
|
|
------------------------------
|
|
|
|
From: rcoursey@ring10.cs.utsa.edu (Rob Coursey)
|
|
Subject: Re: XFree & CDROM slow down transfer rate
|
|
Date: 4 Sep 1994 07:36:38 GMT
|
|
|
|
Robert Stockmann (stock@dutsh7.tudelft.nl) wrote:
|
|
: When running XFree and using a cdrom device I notice
|
|
: that the transfer rate of my scsi disk slows down.
|
|
: normally I get 5.6 Mbyte/sec but under X11 when /dev/sr0 is accessed
|
|
: or has been accessed the transfer rate goes down to 500 to 700 kbyte/sec..
|
|
: Is this normal? Is there a fix? (Hardware or Software?)
|
|
------ --------
|
|
: my system:
|
|
: HP 486 EISA 25 MHz
|
|
: 12 Mb RAM, cache on 486 chip, memory burstmode is accessed
|
|
: by external chip on moherboard (HP design)
|
|
: Adaptec 1740 SCSI-II controller (enhanced mode)
|
|
: FUJITSU Fast SCSI-II disk Model: M2624F-512 Rev: 0405
|
|
: TOSHIBA Fast SCSI-II cdrom Model: CD-ROM XM-3401TA Rev: 0283 (external)
|
|
: ESDI controller with Micropolis 150 Mb ESDI disk
|
|
: ATI Graphics Ultra PRO EISA (2Mb VRAM)
|
|
|
|
actually the problem is not w/ the software, it's with the hardware...
|
|
since the CD's run so much slower than the HD's the chatter on the line when
|
|
using both together (installing from CD, or copying from CD to HD) will
|
|
bring the overall performance (noticable on the HD activity since it is so
|
|
much faster) down to the 5-6MB transfer rate. The only solution I've come
|
|
up w/ is to install a second SCSI controller to maintain 'other' devices
|
|
like tapes and CD's while leaving the original controller to work the HD's.
|
|
(it became very noticable when building and maintaining Novell servers for
|
|
large corporations (which is what I do for a living :))
|
|
|
|
------------------------------
|
|
|
|
From: bart@dunedin.es.co.nz (Bart Kindt)
|
|
Subject: Re: Mosaic and other TCP/IP problems
|
|
Date: Mon, 5 Sep 1994 03:00:05 GMT
|
|
|
|
In article <345a7h$1s1@exile.oec.com> stewart@oec.com (Stewart Allen) writes:
|
|
|
|
|
|
> I seem to be encountering difficulties with Linux's TCP/IP implementation.
|
|
|
|
[Stuff deleted}
|
|
|
|
> One other beef... the close() socket protocol is not implemented correctly.
|
|
> Instead of negotiating the close of a socket, Linux just waits 60 secs.
|
|
> and then closes the socket (/usr/src/linux/net/inet/tcp.h). For RPC servers
|
|
> that spawn when called, this is ok; the residual process just hangs
|
|
> around for an extra 60 seconds before going away. This can be seen on an
|
|
> httpd server that is under heavy load. Every access to the httpd server
|
|
> leaves a residual process for 60 secs. after completing the request. For
|
|
> RPC servers that are necessarily single-threaded, however, Linux's hack is
|
|
> not acceptable. The server must wait 1 minute before completing each
|
|
> request and accepting the next. Is there a fix for this in the works?
|
|
|
|
This could be a explanation of problems I am having with SLIPLOGIN.
|
|
The Sliplogin program often 'hangs' after a user has disconnected (e.g. hung
|
|
up his modem). What happens is that the close(0) call does not return. The
|
|
next line is the exit(1) command, which should have killed the Sliplogin
|
|
program, but this line is not reached. The problem is intermittant, and
|
|
especially seems to occur when there is still some SLIP data going over the
|
|
line when the connection is broken. I have been trying to find a solution to
|
|
this problem for months, but no luck.
|
|
|
|
Could this be related? What can be done about it? Can I write a work-arround
|
|
which first flushes the SLIP stuff, before closing?
|
|
|
|
Bart.
|
|
|
|
|
|
> -- - Stewart Allen * stewart@oec.com * 617.562.5826 * FAX 617.562.0038 - --
|
|
> M.I.S. Manager * Open Environment Corporation * 617.562.0900
|
|
> 25 Travis St * Boston, Ma * 02134
|
|
> -- - -- - -- - -- "That's my story and I'm stickin' to it" -- - -- - -- - --
|
|
|
|
=================================================
|
|
Bart Kindt (ZL4FOX/PA2FOX), Dunedin, New Zealand.
|
|
=================================================
|
|
|
|
------------------------------
|
|
|
|
Crossposted-To: comp.os.linux.admin,comp.os.linux.help,comp.os.linux.misc
|
|
From: iialan@iifeak.swan.ac.uk (Alan Cox)
|
|
Subject: Re: SOCK_PACKET: Why not reading outgoing packets ?
|
|
Date: Fri, 2 Sep 1994 10:34:27 GMT
|
|
|
|
In article <5VquJUE2-DB@gurke.allcon.com> morten@gurke.allcon.com (Morten Jammer) writes:
|
|
>Why can the socket typ SOCK_PACKET only read outgoing packets
|
|
>when the interface is in promiscious mode ?
|
|
|
|
It can definitelyt read all incoming packets on all the cards I use
|
|
(barring etherexpress) otherwise tcpdump wouldnt work. Outgoing packet
|
|
viewing is very recent but now works.
|
|
|
|
Alan
|
|
|
|
|
|
--
|
|
..-----------,,----------------------------,,----------------------------,,
|
|
// Alan Cox // iialan@www.linux.org.uk // GW4PTS@GB7SWN.#45.GBR.EU //
|
|
``----------'`----------------------------'`----------------------------''
|
|
|
|
------------------------------
|
|
|
|
From: humberto@annexstein.csm.uc.edu (Humberto Ortiz Zuazaga)
|
|
Subject: Re: Linux - my first impressions
|
|
Date: Sat, 3 Sep 1994 10:29:31 GMT
|
|
|
|
>>>>> "WL" == Warner Losh <imp@boulder.parcplace.com> writes:
|
|
|
|
WL> In article <345inv$mo6@bmerha64.bnr.ca>
|
|
WL> Hamish.Macdonald@bnr.ca (Hamish Macdonald) writes:
|
|
>> Rather than containing code to read partition tables and Linux
|
|
>> partitions, lilo figures out which disk blocks the kernel file
|
|
>> is on, and puts the block number data in a place it can find on
|
|
>> bootup.
|
|
|
|
WL> The lilo way of doing it is a hack. The boot code should know
|
|
WL> enough to know where to find the kernel by name, and not by a
|
|
WL> list of blocks that may change in the future.
|
|
|
|
I'm surprised Warner, you know this was a design decision. The
|
|
problem is _which_ filesystem should lilo understand (minix, ext,
|
|
ext2, xiafs, umsdos, SysV, FFS)? Answer: none, much simpler code,
|
|
lilo will boot off of anything.
|
|
|
|
Now that most people have settled on ext2 as a standard, perhaps it
|
|
would be worthwhile to write a new bootloader that understood it (any
|
|
volunteers?). This was not the case when lilo was developed, there
|
|
were likely four "standard" file system types at the time, and that's
|
|
a lot of code to stuff into a boot loader.
|
|
--
|
|
Humberto Ortiz Zuazaga zuazaga@ucunix.san.uc.edu
|
|
|
|
------------------------------
|
|
|
|
From: hpulley@uoguelph.ca (Harry C Pulley)
|
|
Subject: Re: DOSEMU 0.53: Developers and testers needed!
|
|
Date: 4 Sep 1994 13:00:29 GMT
|
|
|
|
Rob Janssen (rob@pe1chl.ampr.org) wrote:
|
|
: In <34amdt$4sn@nermal.cs.uoguelph.ca> hpulley@uoguelph.ca (Harry C Pulley) writes:
|
|
|
|
: >The only problem I have has to do with using more than 2 serial ports. I want
|
|
: >to run my XT laptop as a terminal off of COM4 but my mouse is on COM2. When I
|
|
: >try to use both at the same time nothing works from the terminal and the mouse
|
|
: >doesn't respond either. Would it work better if I shared COM3 with my mouse
|
|
: >since COM3 is a 16550? I must look at the serial code to see if there is
|
|
: >something I can do. It would be nice if someone could run WP6.0 on the console
|
|
: >while I run off the terminal *and* the person could use the mouse under DOS.
|
|
|
|
: Unless you have modified the hardware, COM2 and COM4 are not going to
|
|
: work at the same time. This is not related to DOSEMU, but to PC hardware
|
|
: design. They use the same IRQ and cannot share it when they are located
|
|
: on different boards. (and when they are on the same board, they can
|
|
: only share it when the manufacturer was clever)
|
|
: Check the FAQ of comp.sys.ibm.pc.hardware.comm for an explanation.
|
|
|
|
Hmmm. Then why can Coherent run half the ports polled and the other half with
|
|
interrupts? My feeling is that if Coherent can do it, then Linux should also
|
|
be able to do so. My old 286 running a 16-bit version of Coherent could handle
|
|
4 COM ports simultaneously at 9600 bps so why can't my 486-33 do it?
|
|
|
|
I say again: I will take a look at it. I believe you can tell a UART not to
|
|
send any interrupts. Then, you can poll the UART at intervals based on the bps
|
|
rate. If your machine is fast enough and you aren't trying to poll at too high
|
|
a bps rate you should be able to handle it OK.
|
|
|
|
Harry
|
|
--
|
|
<:-{} hpulley@uoguelph.ca |This message released|It takes all kinds,
|
|
\ Harry C. Pulley, IV |to the PUBLIC DOMAIN.|and to each his own.
|
|
==================================+=====================|This thought in mind,
|
|
Stay away from the DOS side, Luke!|Un*x don't play that.|I walk alone.
|
|
|
|
------------------------------
|
|
|
|
From: hpulley@uoguelph.ca (Harry C Pulley)
|
|
Subject: Re: more than 2 COM ports at the same time
|
|
Date: 4 Sep 1994 13:03:06 GMT
|
|
|
|
Rob Janssen (rob@pe1chl.ampr.org) wrote:
|
|
: In <34amhe$4sn@nermal.cs.uoguelph.ca> hpulley@uoguelph.ca (Harry C Pulley) writes:
|
|
|
|
: >I am trying to run with a mouse on COM2, modem on COM3 and terminal on COM4.
|
|
: >Whenever I use both the mouse (COM2) and the terminal (COM4) at the same time I
|
|
: >get no response from either. Is there any code around for sharing IRQs? If
|
|
: >not, then is there any code for using one of the ports in a polled mode instead
|
|
: >of interrupt driven?
|
|
|
|
: Please read that FAQ that I pointed to in another thread.
|
|
: Sharing IRQs is not a matter of code, it is a HARDWARE problem which you
|
|
: are not going to solve in code.
|
|
|
|
: You CAN use the ports in polled mode by specifying irq 0 to setserial,
|
|
: but you are not going to like the results. Maybe it just works for the
|
|
: mouse.
|
|
|
|
OK, I didn't see *that* in the docs anywhere. I will try running a polled
|
|
mouse and see how it goes.
|
|
|
|
: >If nothing exists then I will work on it myself. I just want to know what
|
|
: >already exists out there.
|
|
|
|
: I think the whole world will be thankful to you when you solve this
|
|
: problem! It is considered a major limitation in the PC ISA architecture.
|
|
|
|
Well, I meant that polled support could be added.
|
|
|
|
I would like to stay away from wire wrapping and cutting if I can. If I must,
|
|
I must...
|
|
|
|
Thanks,
|
|
Harry
|
|
--
|
|
<:-{} hpulley@uoguelph.ca |This message released|It takes all kinds,
|
|
\ Harry C. Pulley, IV |to the PUBLIC DOMAIN.|and to each his own.
|
|
==================================+=====================|This thought in mind,
|
|
Stay away from the DOS side, Luke!|Un*x don't play that.|I walk alone.
|
|
|
|
------------------------------
|
|
|
|
From: hpulley@uoguelph.ca (Harry C Pulley)
|
|
Subject: polled ports
|
|
Date: 4 Sep 1994 13:25:08 GMT
|
|
|
|
Thanks to people here I can now run with polled ports. But, even with just a
|
|
1200baud mouse connection it doesn't work very well. Under X it is barely
|
|
usable but under dosemu it is totally useless.
|
|
|
|
Are there any known improvements to the polling code? 1200 baud shouldn't be
|
|
too fast...
|
|
|
|
Harry
|
|
--
|
|
<:-{} hpulley@uoguelph.ca |This message released|It takes all kinds,
|
|
\ Harry C. Pulley, IV |to the PUBLIC DOMAIN.|and to each his own.
|
|
==================================+=====================|This thought in mind,
|
|
Stay away from the DOS side, Luke!|Un*x don't play that.|I walk alone.
|
|
|
|
------------------------------
|
|
|
|
From: stewart@oec.com (Stewart Allen)
|
|
Subject: Re: Mosaic and other TCP/IP problems
|
|
Date: 3 Sep 1994 20:25:09 GMT
|
|
|
|
Stewart Allen (stewart@oec.com) wrote:
|
|
|
|
: I seem to be encountering difficulties with Linux's TCP/IP implementation.
|
|
: In Mosaic (running on Linux 1.0.9, 1.0.0, 1.1.0, 1.1.38, etc) I have the
|
|
: problem that image transfers > 5K break at 5632 Bytes always. They blitz
|
|
: up to this point then begin crawling at about 1K every 3 seconds. We have
|
|
: a T1 to the internet and the problem only occurs when moving from a fast
|
|
: transport (10BT Ethernet @ 10Mbits) to a slower medium (T1 or SLIP). When
|
|
: accessing the httpd server over straight ethernet, the problem does not
|
|
: show up. My network cohorts claim that 5632 bytes = 1 machine page +
|
|
: minimum TCP packet + TCP header and that there may be a problem with the
|
|
: VJ conjestion control algorithms. Is this true or is the algorithm not
|
|
: even implemented?
|
|
|
|
I wasn't very clear here. The problem occurs when running the httpd, not
|
|
Mosaic, on Linux. If a Mosaic client running on any platform accesses an
|
|
httpd server running on Linux, then the following problen occurs: file or
|
|
image transfers over 5632 Bytes slow down tremendously at 5632 Bytes to the
|
|
tune of 1K every 3 or 4 seconds. This only occurs under high congestion or
|
|
when moving between different speed networks.
|
|
|
|
--
|
|
|
|
-- - Stewart Allen * stewart@oec.com * 617.562.5826 * FAX 617.562.0038 - --
|
|
M.I.S. Manager * Open Environment Corporation * 617.562.0900
|
|
25 Travis St * Boston, Ma * 02134
|
|
-- - -- - -- - -- "That's my story and I'm stickin' to it" -- - -- - -- - --
|
|
|
|
------------------------------
|
|
|
|
|
|
** 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
|
|
******************************
|