Path: utzoo!utgpu!water!watmath!clyde!att!pacbell!ames!pasteur!ucbvax!bloom-beacon!mcgill-vision!mouse
From: mouse@mcgill-vision.UUCP (der Mouse)
Newsgroups: comp.mail.uucp
Subject: Re: Send vs receive times
Message-ID: <1187@mcgill-vision.UUCP>
Date: 26 Jun 88 09:15:26 GMT
References: <92@carpet.WLK.COM> <7040@elroy.Jpl.Nasa.Gov>
Distribution: na
Organization: McGill University, Montreal
Lines: 28

In article <7040@elroy.Jpl.Nasa.Gov>, stevo@judy.Jpl.Nasa.Gov (Steve Groom) writes:
> In article <92@carpet.WLK.COM> bill@carpet.WLK.COM (Bill Kennedy) writes:
>> I have noticed that my systems send much faster than they receive,
>> i.e. 210 bytes/sec sending, 176 bytes/sec receiving from the other
>> site.  Anyone else notice this?  Any thoughts?

> Simple.  Reads on existing files are almost always faster than writes
> to new files.  The reason is that on the reads, you don't have the
> additional file system overhead of allocating disk blocks to write
> to.

Any system on which disk block allocation is a bottleneck at a data
rate of two hundred bytes a second is in sad shape indeed.

More likely, I think, is another effect.  Our system, for example, can
blast characters out at the rate of thousands a second all day, yet on
input if you try to feed it more than one or two hundred characters a
second average, it chokes, regardless of what baud rate they're sent
at.  The cpu simply can't keep up with servicing all the interrupts and
shuffling all the clist structures.  (Raw mode helps, but only some.)

And as someone else pointed out, the way the timing is done skews the
estimates, as do modems like trailblazers which buffer stuff....

					der Mouse

			uucp: mouse@mcgill-vision.uucp
			arpa: mouse@larry.mcrcim.mcgill.edu