dyer@spdcc.COM (Steve Dyer) (09/02/88)
My UUCP sez in its SYSLOG: sent data 9212 bytes 5.00 secs, but the UUCP on the other end sez: received data 9212 bytes 49.93 sec I wondered why things were running so slowly... -- Steve Dyer dyer@harvard.harvard.edu dyer@spdcc.COM aka {harvard,husc6,linus,ima,bbn,m2c,mipseast}!spdcc!dyer
james@bigtex.uucp (James Van Artsdalen) (09/03/88)
In article <1776@spdcc.COM>, dyer@spdcc.UUCP (Steve Dyer) wrote: > My UUCP sez in its SYSLOG: sent data 9212 bytes 5.00 secs, but the > UUCP on the other end sez: received data 9212 bytes 49.93 sec > I wondered why things were running so slowly... This can be a real problem. I feed news to a site with an unbelievably poor PBX: the *largest* instantenious xmit rate I have seen is 5986, and the largest receive rate is 4038. Average is more like 4000 and 2200. They tell me that 2400bps modems cannot connect over the lines. I think it impressive that the TB+s work at all. Unfortunately, it appears that sometimes my uucico gives up waiting for a CY packet. The TB+ buffers so much data that at those transfer rates, it takes a long time for the queued data to get sent. In the meantime my uucico gets impatient and begins retrying, and if the lines are bad enough it appears to eventually give up on the session. -- James R. Van Artsdalen ...!uunet!utastro!bigtex!james "Live Free or Die" Home: 512-346-2444 Work: 328-0282; 110 Wild Basin Rd. Ste #230, Austin TX 78746
dave@onfcanim.UUCP (Dave Martindale) (09/03/88)
In article <1776@spdcc.COM> dyer@spdcc.UUCP (Steve Dyer) writes: >My UUCP sez in its SYSLOG: sent data 9212 bytes 5.00 secs, but the UUCP on the >other end sez: received data 9212 bytes 49.93 sec > >I wondered why things were running so slowly... From a few informal experiments, it seems that a pair of Trailblazers operating in PEP mode are willing to buffer something like 20 Kb of data in the two modems before flow-controlling the source. So, it took just 5 seconds for the originating telebit to eat and acknowledge all 9212 bytes, at which point the originating uucico thinks they've all arrived at the destination (after all, it acknowledged them didn't it?) Meanwhile, on the receiving end, it took 50 seconds to get the bytes from the modem into the host. What bit rate was that port running at anyway? For Trailblazers, only the receiving side gets a true idea of the transmission rate. Even when sending 100 kbyte files, there will be a significant difference in the rates reported by the sending and receiving end.
dave@onfcanim.UUCP (Dave Martindale) (09/03/88)
In article <7437@bigtex.uucp> james@bigtex.UUCP (James Van Artsdalen) writes: > >This can be a real problem. I feed news to a site with an >unbelievably poor PBX: the *largest* instantenious xmit rate I have >seen is 5986, and the largest receive rate is 4038. Average is more >like 4000 and 2200. > >Unfortunately, it appears that sometimes my uucico gives up waiting >for a CY packet. The TB+ buffers so much data that at those transfer >rates, it takes a long time for the queued data to get sent. If you're sure that you aren't going to get decent transmit rates, you could talk to the modem at 4800. You can still get a lot of data buffered if it turns out that the connection is really only 2000 bps, but it should fail less often. It would be nice if the Trailblazer had an S-register to control the local buffer's high-water mark.
james@bigtex.uucp (James Van Artsdalen) (09/04/88)
In article <16029@onfcanim.UUCP>, dave@onfcanim.UUCP (Dave Martindale) wrote: [ problems in talking PEP to sites with very bad lines ] > If you're sure that you aren't going to get decent transmit rates, you > could talk to the modem at 4800. [..] > It would be nice if the Trailblazer had an S-register to control the > local buffer's high-water mark. I considered both of these, but they only work when I call them, not when they call me. With this particular site, they poll me. I can't contort my TB+ settings because lots of people call PEP with acceptible transfer rates. The only solution I can think of is that the TB+ ought to set the high-water mark on a call-by-call basis based on the available transfer bandwidth. Calls with potentially high transfer rates would buffer up to the normal 20K or so, while low transfer rates would buffer considerably. This is the only way to deal with the answer side I can think of. -- James R. Van Artsdalen ...!uunet!utastro!bigtex!james "Live Free or Die" Home: 512-346-2444 Work: 328-0282; 110 Wild Basin Rd. Ste #230, Austin TX 78746