bill@carpet.WLK.COM (Bill Kennedy) (06/12/88)
If this is the wrong group, excuse, I don't get comp.unix.* and this
seemed like a better place.
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?
--
Bill Kennedy Internet: bill@ssbn.WLK.COM
Usenet: { killer | att-cb | ihnp4!tness7 }!ssbn!billstevo@judy.Jpl.Nasa.Gov (Steve Groom) (06/16/88)
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. This is also why file system dumps can be made to go so much faster than restores. On dumps, you're just reading the data. On restores, you've doing a lot of allocating of disk blocks to do too. -steve /* Steve Groom, MS 168-522, Jet Propulsion Laboratory, Pasadena, CA 91109 * Internet: stevo@elroy.jpl.nasa.gov UUCP: {ames,cit-vax}!elroy!stevo * Disclaimer: (thick German accent) "I know noothingg! Noothingg!" */
lmb@vsi1.UUCP (Larry Blair) (06/16/88)
In article <7040@elroy.Jpl.Nasa.Gov> stevo@jane.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. | |This is also why file system dumps can be made to go so much faster than |restores. On dumps, you're just reading the data. On restores, you've |doing a lot of allocating of disk blocks to do too. Relative I/O speeds not withstanding, the reason for the difference is the way in which uucp generates the SYSLOG data. For received data, it's from the start of the transmission until the CY is sent out. For sent data, it's from the start of the transmission until the last block is sent, not when the CY is received. This disparity becomes even more obvious when a buffering modem, such as the Trailblazer, is used. Now that I've stated that, I'm sure someone will tell me I'm wrong! -- * * O Larry Blair * * O VICOM Systems Inc. sun!pyramid----\ * * O 2520 Junction Ave. uunet!ubvax----->!vsi1!lmb * * O San Jose, CA 95134 ucbvax!tolerant/ * * O +1-408-432-8660
mouse@mcgill-vision.UUCP (der Mouse) (06/26/88)
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