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