kmcvay@oneb.UUCP (Ken McVay) (02/06/90)
I installed our first Trailblazer Plus late last month, and have been so far unable to get the throughput up to where it should be....here's a sample of the status-quo.. van-bc!paster M (2/5-12:34:58) (C,829,1) [tty1A] -> 785 / 1.150 secs, 682 bytes/sec van-bc!news M (2/5-12:35:25) (C,829,7) [tty1A] <- 6769 / 15.750 secs, 429 bytes/sec van-bc!news M (2/5-12:36:26) (C,829,9) [tty1A] <- 71897 / 142.800 secs, 503 bytes/sec van-bc!news M (2/5-12:36:43) (C,829,13) [tty1A] <- 6122 / 14.500 secs, 422 bytes/sec van-bc!news M (2/5-12:43:03) (C,829,49) [tty1A] <- 29262 / 57.950 secs, 504 bytes/sec The system is a 386, running at 25MHz under SCO Xenix 2.3.1. The Systems file for van-bc is set for 19200 (tried 38400, but it wouldn't fly), and icgnu is set for 9600. The same Devices listing is used for both. I am using a standard 8250-type UART, with no buffers (a'la 16550's).... would appreciate any suggestions which would assist me in tweaking the system and getting it up to speed....400-600 baud isn't acceptable, and I know that the system is capable of more.....where should I begin? -- 1B Systems Management Ltd. | 4B - 2520 Bowen Road, Nanaimo, B.C. V9T 3L3 Kenneth McVay | Voice: 604-758-7414 | Envoy: ken.mcvay | RCSA: 89:681/1 ------> uunet!van-bc!oneb!kmcvay |
larry@nstar.UUCP (Larry Snyder) (02/06/90)
> I am using a standard 8250-type UART, with no buffers (a'la 16550's).... > would appreciate any suggestions which would assist me in tweaking the system > and getting it up to speed....400-600 baud isn't acceptable, and I know that > the system is capable of more.....where should I begin? Make sure you are using UUCP spoofing in the modem, make sure the modem interface is locked at 19200, make sure you are using hardware flow control (if supported, if not use XON/XOFF but not BOTH), make sure your host is batching large bundles (less overhead than lots of small bundles). Just a few ideas - larry@nstar -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA uucp: larry@nstar -or- ...!iuvax!ndmath!nstar!larry 4 inbound dialup high speed line public access system
root@nebulus.UUCP (Dennis S. Breckenridge) (02/07/90)
In article <1844@oneb.UUCP> kmcvay@oneb.UUCP (Ken McVay) writes: > I installed our first Trailblazer Plus late last month, and have been > > file for van-bc is set for 19200 (tried 38400, but it wouldn't fly), and icgnu > is set for 9600. The same Devices listing is used for both. > I have seen this problem on several TB's including the New TB2500. The modem "skids" that is, when you tell the modem to stop sending data from it to your computer by dropping CTS, the modem sends a few more bytes of data. This is just enough for my ports card to drop the data on the floor. The whole packet is discarded, uucico NAK's the next packet and the retransmission takes place. Drop the speed to 9600 baud to get the 800 or so characters that the TB1000 will do. If you are running this on COM1 or COM2 the same thing is happening for a different reason. Characters are lost at the serial port. I have told Telebit about this in an official capacity but no fix is forthcomming. -- ----------------------------------------------------------------------------- NAME: Dennis S. Breckenridge UUCP: dennis@nebulus EMACS: Eight Megabytes And Constantly Swapping! -----------------------------------------------------------------------------
lmb@vicom.com (Larry Blair) (02/07/90)
In article <511168@nstar.UUCP> larry@nstar.UUCP (Larry Snyder) writes:
=> I am using a standard 8250-type UART, with no buffers (a'la 16550's)....
=> would appreciate any suggestions which would assist me in tweaking the system
=> and getting it up to speed....400-600 baud isn't acceptable, and I know that
=> the system is capable of more.....where should I begin?
=
=Make sure you are using UUCP spoofing in the modem, make sure the modem
=interface is locked at 19200, make sure you are using hardware flow control
=(if supported, if not use XON/XOFF but not BOTH), make sure your host is
=batching large bundles (less overhead than lots of small bundles).
DON'T use XON/XOFF with UUCP spoofing! The UUCP "g" protocol does not
allow for inband signalling. My feeling is that Telebit should automatically
disable inband flow control when spoofing.
--
Larry Blair ames!vsi1!lmb lmb@vicom.combrad@looking.on.ca (Brad Templeton) (02/07/90)
I bet that SCO hates this one. There is a bug in HDB that reports times as double what they are. Time with a stopwatch, ignore the log file, and then note the throughput. It's ok. -- Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473
larry@nstar.UUCP (Larry Snyder) (02/07/90)
> DON'T use XON/XOFF with UUCP spoofing! The UUCP "g" protocol does not > allow for inband signalling. My feeling is that Telebit should automatically > disable inband flow control when spoofing. I thought that the spoofing automatically disabled XON/XOFF. -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA uucp: larry@nstar -or- ...!iuvax!ndmath!nstar!larry 4 inbound dialup high speed line public access system
igb@fulcrum.bt.co.uk (Ian G Batten) (02/07/90)
lmb@vicom.com (Larry Blair) writes: > DON'T use XON/XOFF with UUCP spoofing! The UUCP "g" protocol does not > allow for inband signalling. My feeling is that Telebit should automatically > disable inband flow control when spoofing. I think Peter Honeyman said that it does. I've certainly mistakenly left XON/XOFF turned on whilst running spoofing and it still worked OK. And I think uucico turns it off at the Unix end. ian -- Ian G Batten, BT Fulcrum - igb@fulcrum.bt.co.uk - ...!uunet!ukc!fulcrum!igb
john@compugen.UUCP (John Beaudin) (02/07/90)
I was also concerned about slow thruput times. I manually timed a transfer and was suprised to see that sco's stat was wrong. I had a transfer rate of 850+ characters/second with a T1000. Sco's stat stated 350 characters or so. Looks like you can't trust the logfile. -- -- my .signature is awaiting appropriate display technology --
dplatt@coherent.com (Dave Platt) (02/08/90)
In article <1990Feb7.011113.15033@vicom.com> lmb@vicom.com (Larry Blair) writes: > DON'T use XON/XOFF with UUCP spoofing! The UUCP "g" protocol does not > allow for inband signalling. Quite so! My experience is as follows: if your machine's serial ports will support the de-facto-standard RTS/CTS hardware flow control, use it... enable it on your machine, and configure the Telebit modem to use this form of flow control. If your machine does not support RTS/CTS flow-control, do NOT use XON/XOFF flow control during UUCP connections (spoofed or otherwise). Instead, tell the Telebit to use NO flow control whatsoever! This is often a very important step. If you configure the Telebit to use RTS/CTS flow control, and your host doesn't support it, you'll almost certainly lose data during non-spoofed UUCP transfers. If you configure for XON/XOFF flow control, neither spoofed nor non-spoofed UUCP transfers will work correctly, as Larry pointed out. Saying "No flow control, please" is much safer than requesting a flow-control which either does not work or is incompatible with the higher-level protocols. At least, this is my experience with a TrailBlazer Plus. -- Dave Platt VOICE: (415) 493-8805 UUCP: ...!{ames,apple,uunet}!coherent!dplatt DOMAIN: dplatt@coherent.com INTERNET: coherent!dplatt@ames.arpa, ...@uunet.uu.net USNAIL: Coherent Thought Inc. 3350 West Bayshore #205 Palo Alto CA 94303
henry@utzoo.uucp (Henry Spencer) (02/08/90)
In article <511174@nstar.UUCP> larry@nstar.UUCP (Larry Snyder) writes: >> ... My feeling is that Telebit should automatically >> disable inband flow control when spoofing. > >I thought that the spoofing automatically disabled XON/XOFF. According to Peter Honeyman, who wrote the uucp spoofing code for Telebit, it does. There might be room for trouble if flow control got in the way of uucp startup, before spoofing was established, though. -- SVR4: every feature you ever | Henry Spencer at U of Toronto Zoology wanted, and plenty you didn't.| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
wsinpdb@eutws1.win.tue.nl (Paul de Bra) (02/08/90)
In article <91136@looking.on.ca> brad@looking.on.ca (Brad Templeton) writes: >I bet that SCO hates this one. There is a bug in HDB that reports >times as double what they are. Not exactly true I believe. First of all the bug is *not* in HDB. In some versions of Xenix SCO accidentally compiled uucico in an environment with HZ=20 instead of HZ=50. So the real rates are 2.5 times higher (or the time lower) compared to the log file. This has been discussed in comp.unix.xenix some (a long) time ago. SCO has a fix I believe. (dunno, i don't run xenix anymore, and never used their hdb anyway) Paul. (debra@research.att.com)
mikes@NCoast.ORG (Mike Squires) (02/10/90)
In article <91136@looking.on.ca> brad@looking.on.ca (Brad Templeton) writes: >I bet that SCO hates this one. There is a bug in HDB that reports >times as double what they are. > >Time with a stopwatch, ignore the log file, and then note the throughput. >It's ok. One of the patches available from SOS (via anonymous uucp) contains an update to HDB uucp that fixes this problem, at least. I've been running it for a while under 2.3.2 XENIX 386 with no problems.