rick@uunet.UU.NET (Rick Adams) (06/01/88)
Recently we have been seeing almost unbelievable throughput to Argentina via Trailblazers. This is as good as or better than we have received with many US sites. This is an excerpt from yesterday's uucp logs: 5/30 17:23 48294 bytes 43.90 secs 8799 bps 5/30 17:24 30301 bytes 26.71 secs 9075 bps 5/30 17:25 8073 bytes 5.72 secs 11290 bps 5/30 17:26 18993 bytes 12.47 secs 12184 bps 5/30 17:27 30008 bytes 19.90 secs 12063 bps 5/30 17:29 42360 bytes 31.79 secs 10659 bps 5/30 17:31 48036 bytes 38.66 secs 9940 bps 5/30 17:32 37823 bytes 26.25 secs 11527 bps 5/30 17:32 32586 bytes 23.56 secs 11064 bps 5/30 17:34 50714 bytes 40.66 secs 9978 bps 5/30 17:35 29146 bytes 19.93 secs 11699 bps 5/30 18:41 34879 bytes 23.25 secs 12001 bps 5/30 18:42 6544 bytes 4.79 secs 10929 bps 5/30 18:42 16005 bytes 10.51 secs 12182 bps 5/30 18:44 41625 bytes 26.47 secs 12580 bps 5/30 18:45 40673 bytes 28.30 secs 11497 bps 5/30 18:46 40524 bytes 27.90 secs 11619 bps 5/30 18:48 42183 bytes 30.18 secs 11181 bps
piet@cwi.nl (Piet Beertema) (06/01/88)
>Recently we have been seeing almost unbelievable throughput to >Argentina via Trailblazers. This is as good as or better than >we have received with many US sites. Maybe Argentina has a better PTT? -- Piet Beertema, CWI, Amsterdam (piet@cwi.nl)
heiby@mcdchg.UUCP (Ron Heiby) (06/04/88)
Rick Adams (rick@uunet.UU.NET) writes: > 5/30 17:23 48294 bytes 43.90 secs 8799 bps > 5/30 17:24 30301 bytes 26.71 secs 9075 bps > 5/30 17:25 8073 bytes 5.72 secs 11290 bps > 5/30 17:26 18993 bytes 12.47 secs 12184 bps > 5/30 17:27 30008 bytes 19.90 secs 12063 bps > 5/30 17:29 42360 bytes 31.79 secs 10659 bps > 5/30 17:31 48036 bytes 38.66 secs 9940 bps > 5/30 17:32 37823 bytes 26.25 secs 11527 bps > 5/30 17:32 32586 bytes 23.56 secs 11064 bps > 5/30 17:34 50714 bytes 40.66 secs 9978 bps > 5/30 17:35 29146 bytes 19.93 secs 11699 bps First, let me say that I find this to be very impressive. Now, it has given me a chance to look at something I've been meaning to for some time. At first glance, it looks like the average throughput for this set of transfers is something like 1000 characters per second. But wait! Look at the wall clock time. I am assuming that this set of 11 transfers took place on a single call. I have added the total bytes and get 376,334 in 12 minutes. This works out to be 522.7 cps, or slightly better than half what it appears to be at first. Now, I know that there is some additional time used to send a short overhead file with uucp, but it really seems to me that there's an awful lot of think time going on between transfers. Although I haven't gone to the trouble of calculating it, watching the lights blink on my Telebit gives me the same impression. Anyone have any thoughts on the matter? It looks to me like with a reliable link, that bigger files are even more of a win with Telebit speeds than with 1200 bps modems. -- Ron Heiby, heiby@mcdchg.UUCP Moderator: comp.newprod & comp.unix "Failure is one of the basic Freedoms!" The Doctor (in Robots of Death)
lyndon@ncc.Nexus.CA (Lyndon Nerenberg) (06/06/88)
In article <10127@mcdchg.UUCP> heiby@mcdchg.UUCP (Ron Heiby) writes: [ Stats on uunet's throughput deleted ] > [ ... ] But wait! Look >at the wall clock time. I am assuming that this set of 11 transfers took >place on a single call. I have added the total bytes and get 376,334 in >12 minutes. This works out to be 522.7 cps, or slightly better than half >what it appears to be at first. Now, I know that there is some additional >time used to send a short overhead file with uucp, but it really seems to >me that there's an awful lot of think time going on between transfers. Indeed, this is the case between us and uunet. Over the course of a month, our throughput stats show incoming data from uunet averages out at about 450CPS, if you include the delays between files. Traffic from us to uunet is a more respectable 750CPS (our TB's talk to a Sun 3/280 at 9600 baud). I too have spent countless hours watching the lights and the log file. It's not hard to tell when uunet is busy :-) I have a nasty suspicion that some faster drives on uunet would make a difference. -- {alberta,utzoo,uunet}!ncc!lyndon lyndon@Nexus.CA
sl@van-bc.UUCP (pri=-10 Stuart Lynne) (06/06/88)
In article <10266@ncc.Nexus.CA> lyndon@ncc.UUCP (Lyndon Nerenberg) writes: >In article <10127@mcdchg.UUCP> heiby@mcdchg.UUCP (Ron Heiby) writes: >> [ ... ] But wait! Look >>me that there's an awful lot of think time going on between transfers. >Indeed, this is the case between us and uunet. Over the course of a >month, our throughput stats show incoming data from uunet averages >out at about 450CPS, if you include the delays between files. Traffic from >us to uunet is a more respectable 750CPS (our TB's talk to a Sun 3/280 >at 9600 baud). >I too have spent countless hours watching the lights and the log file. >It's not hard to tell when uunet is busy :-) I'll say, I see a fairly large variation in the time to send the X. files for mail. Anything from 4 to 11 seconds for less than 100 chars. >I have a nasty suspicion that some faster drives on uunet would make >a difference. Something else which could (should) be done is to get BSMTP implemented at UUNET. Now that the Trailblazers have reduced the file transfer size down to a few seconds for your average mail message the next place to optimize is the inter-message time. BSMTP would eliminate two inter-file gaps and one small file. Ideally you could stuff enough messages into a file to make it about 50k or so and send it over with one X. file. This would reduce costs *MORE* than spending money on faster drives. (Of course money would have to be spent to pay someone at UUNET to implement this, I'm sure they don't work there just for the fun of it, but I think this would provide more bang for the buck!) -- Stuart.Lynne@wimsey.bc.ca {ubc-cs,uunet}!van-bc!sl Vancouver,BC,604-937-7532
rick@seismo.CSS.GOV (Rick Adams) (06/07/88)
Actually, I didn't print any transfers where the file size was less thatn 10k. The transfer times for those files are unreliable because of buffering, etc. --rick
karl@ddsw1.UUCP (Karl Denninger) (06/08/88)
In article <10127@mcdchg.UUCP> heiby@mcdchg.UUCP (Ron Heiby) writes: >Rick Adams (rick@uunet.UU.NET) writes: > >[apparent 1/2 speed transfer on Telebit] > >Now, I know that there is some additional >time used to send a short overhead file with uucp, but it really seems to >me that there's an awful lot of think time going on between transfers. >Although I haven't gone to the trouble of calculating it, watching the >lights blink on my Telebit gives me the same impression. Anyone have >any thoughts on the matter? It looks to me like with a reliable link, >that bigger files are even more of a win with Telebit speeds than with >1200 bps modems. I also find that the actual transfer time, in bytes sent / wall clock seconds is substantially lower than the "sending the file" time. This seems to be due to a couple of things: 1) The modem has a decent-sized buffer. When you're sending a file, the last 10k or so is "free" in that it can be absorbed by the modem at a higher rate than the phone line can transmit it. If your files are short, you get *really* impressive times -- I've hit 16-17kbaud on files < 10k (we run a 19.2K locked line). This also means that you see a pause at the end of a file while the modem "catches up" before you get back the "OK" confirmation from the other end.... 2) The system does do some 'crunching' between files. For a loaded system, this can be very substantial. Our machine is usually lightly loaded, and thus it's not significant here. On calls to heavily-loaded hosts, though, you can wait for a bit..... The big files get you more time between "2"s -- the perceived benefit from small files is really not there, as the timing doesn't take into account the buffering of the data....(unless you use wall-clock time). This also depends on the speeds of the respective ends of the connection as well. If one end is running a 9600-baud interface and the other is at 19.2K the faster end can easily saturate the link and cause the hardware flow control to come into effect.... Compression, if you're sending files which are "agreeable" to it, can make things even better. -- Karl Denninger (ihnp4!ddsw1!karl) Data: (312) 566-8912, Voice: (312) 566-8910 Macro Computer Solutions, Inc. "Quality solutions for work or play"
piquer@inria.UUCP (Miguel Piquer) (06/10/88)
In article <10127@mcdchg.UUCP> heiby@mcdchg.UUCP (Ron Heiby) writes: >Rick Adams (rick@uunet.UU.NET) writes: >> 5/30 17:23 48294 bytes 43.90 secs 8799 bps >> 5/30 17:24 30301 bytes 26.71 secs 9075 bps >> [...] >> 5/30 17:34 50714 bytes 40.66 secs 9978 bps >> 5/30 17:35 29146 bytes 19.93 secs 11699 bps > [...] >at the wall clock time. I am assuming that this set of 11 transfers took >place on a single call. I have added the total bytes and get 376,334 in >12 minutes. This works out to be 522.7 cps, or slightly better than half >what it appears to be at first. > [...] >Anyone have any thoughts on the matter? >It looks to me like with a reliable link, >that bigger files are even more of a win with Telebit speeds than with >1200 bps modems. I agree, I have seen the experiences in Chile (with a much lesser throughput) and the Trailblazer does a better job than the computer, which looses all his time scanning directories and searching for jobs, which normally are many short mail files (with its short commands files). I don't have the data at hand but I do know that the people there are planning a batch system that collects all the mails in a big file doing only one big transfer each time, hoping to get a much better performance. I think that Argentina has the same problem: a super modem, a super PTT (much better than the chilean one...) with a normal computer. Perhaps they can use the same solution (or buy a bigger machine :-)), but we are falling in a new problem: the communications are running faster than the computers :-). >Ron Heiby, heiby@mcdchg.UUCP Moderator: comp.newprod & comp.unix Jo Piquer, piquer@inria.inria.fr "A chilean lost in France"