dave@arnold.UUCP (Dave Arnold) (09/18/88)
WANTED:
xfer stats for UUCP running over async lines using g.
mean cps for 1200, 2400, 9600 all direct connections.
"" "" "" "" "" "" using modems.
"" "" "" "" "" "" using tb+ in pep.
mean % line utilization.
estimated round trip delay (R) for a g packet, and RR ( I need this
to estimate the packet timeout timer).
This information is going to be used for benchmarking a uucico
implementation for VMS.
I ran some tests using g over a direct 9600 baud line, and was
seeing about 450cps, is something wrong, or is this average?
Thanks.
--
Dave Arnold
dave@arnold.UUCP {cci632|uunet}!ccicpg!arnold!davehenry@utzoo.uucp (Henry Spencer) (09/21/88)
In article <183@arnold.UUCP> dave@arnold.UUCP (Dave Arnold) writes: >I ran some tests using g over a direct 9600 baud line, and was >seeing about 450cps, is something wrong, or is this average? Probably one or both of your machines can't keep up. (I assume you're using sufficiently large files that startup and shutdown overhead are negligible -- they are substantial.) Uucp-g can run a line at circa 90% of line speed quite consistently if the machines are fast enough and the serial interfaces are not so stupid as to be a bottleneck. (This is, historically, sometimes a problem on VAXen.) -- NASA is into artificial | Henry Spencer at U of Toronto Zoology stupidity. - Jerry Pournelle | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
dave@arnold.UUCP (Dave Arnold) (09/22/88)
(Henry Spencer) writes: > In article <183@arnold.UUCP> dave@arnold.UUCP (Dave Arnold) writes: > >I ran some tests using g over a direct 9600 baud line, and was > >seeing about 450cps, is something wrong, or is this average? > > negligible -- they are substantial.) Uucp-g can run a line at circa 90% > of line speed quite consistently if the machines are fast enough and > the serial interfaces are not so stupid as to be a bottleneck. (This > is, historically, sometimes a problem on VAXen.) After some more tests I am consistently seeing around 580 cps on a direct 9600 baud line between a uVax running VMS and a 68000 Unix box. Windows=7 PKTSIZE=64. I have never seen 90% bandwidth utilization. My 3B1 at home running at 1200 baud always gets around 100-120 cps. How are you computing bandwidth utilization? (c * 8) / b where b = baud and c = chars. per second? c taken from xferstats in /usr/spool/uucp/.Log -- Dave Arnold dave@arnold.UUCP {cci632|uunet}!ccicpg!arnold!dave
skl@van-bc.UUCP (Samuel Lam) (09/24/88)
In article <184@arnold.UUCP>, dave@arnold.UUCP (Dave Arnold) wrote: >How are you computing bandwidth utilization? > >(c * 8) / b ^ >where b = baud and c = chars. per second? >c taken from xferstats in /usr/spool/uucp/.Log You probably want to multiply by (at least) 10 instead of just 8 since the 1 start bit and 1 to 2 stop bits count here as well. (This is true when the link between the two computers is an asynchronous serial line.) -- Samuel Lam {alberta,watmath,uw-beaver,ubc-vision}!ubc-cs!van-bc!skl
dave@arnold.UUCP (Dave Arnold) (09/25/88)
In article <1892@van-bc.UUCP>, skl@van-bc.UUCP (Samuel Lam) writes: > In article <184@arnold.UUCP>, dave@arnold.UUCP (Dave Arnold) wrote: > >How are you computing bandwidth utilization? > > > >(c * 8) / b > ^ > >where b = baud and c = chars. per second? > >c taken from xferstats in /usr/spool/uucp/.Log > > You probably want to multiply by (at least) 10 instead of just 8 > since the 1 start bit and 1 to 2 stop bits count here as well. That's what I thought. But somebody told me that you have to multiply by 8 to compute the *TRUE* overhead, including packet headers, retransmits, delays, timeouts, AND async overhead. So, the question is... What do we really want to know: How much of the 9600 baud line are we using? or How much of what is ACTUALLY available on the 9600 baud line are we using? taking into account the async overhead. Thanks for straighting this matter out. -- Dave Arnold dave@arnold.UUCP {cci632|uunet}!ccicpg!arnold!dave
henry@utzoo.uucp (Henry Spencer) (09/25/88)
In article <184@arnold.UUCP> dave@arnold.UUCP (Dave Arnold) writes: >> ... Uucp-g can run a line at circa 90% >> of line speed quite consistently if the machines are fast enough and >> the serial interfaces are not so stupid as to be a bottleneck... > >...I have never seen 90% bandwidth utilization. My 3B1 at home running >at 1200 baud always gets around 100-120 cps. How are you computing >bandwidth utilization? ... (c * 8) / b ? You're forgetting the start and stop bits. It's 10 bits per character, not 8. 90% of 1200 baud is 108 cps. Back when most of our news traffic was at 1200, we saw uucp running at 109 +- 2 or so cps for hours on end, quite consistently, for most sites. At 2400 the loading on the machines starts to matter a bit more, so the variation increased, but the numbers were still pretty consistent. At higher speeds, system loading and various kinds of hardware brain-damage matter a lot more, the rates vary all over the place, and 90% becomes the "guaranteed not to exceed" utilization rather than the average. -- NASA is into artificial | Henry Spencer at U of Toronto Zoology stupidity. - Jerry Pournelle | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
dave@onfcanim.UUCP (Dave Martindale) (09/26/88)
>90% of 1200 baud is 108 cps. Back when most of our news traffic >was at 1200, we saw uucp running at 109 +- 2 or so cps for hours on end, >quite consistently, for most sites. Uucico, unless you've modified it, always uses 64-byte packets. The g-protocol header is 6 bytes, so if there are always characters being transmitted with no "dead" periods, you would expect to see 64/70 = 0.914 of the modem bandwidth being useful data. 1200 bps = 120 cps; the "data" portion of this is 109.7 cps. Any more than this and you have inaccurate timing (i.e. timing a short file when the last buffer has been written but not yet arrived at the far end) or a too-fast UART clock. Any less and the host is probably not keeping up. With modems like the Trailblazer, the limiting factor seems to be hosts that can't handle continuous input and output at 19.2 Kbps more often than the modems.
dennis@rlgvax.UUCP (Dennis.Bednar) (09/26/88)
In article <16257@onfcanim.UUCP>, dave@onfcanim.UUCP (Dave Martindale) writes: > >90% of 1200 baud is 108 cps. Back when most of our news traffic > >was at 1200, we saw uucp running at 109 +- 2 or so cps for hours on end, > >quite consistently, for most sites. > > Uucico, unless you've modified it, always uses 64-byte packets. > The g-protocol header is 6 bytes, so if there are always characters > being transmitted with no "dead" periods, you would expect to see > 64/70 = 0.914 of the modem bandwidth being useful data. > > 1200 bps = 120 cps; the "data" portion of this is 109.7 cps. 2 lines from our /usr/spool/uucp/SYSLOG file: sundc!root S (9/26-8:36:27) (C,11858,9) (0:26:36) <- 18617 / 171 secs [1595:0:0:7:1416:171:273:57] [tty0a,0,0,0,0] Is the 18617/117 = 108.87 cps just the 64 byte data portion, or does it include the 6-byte header on every data packet? -- FullName: Dennis Bednar UUCP: {uunet|sundc}!rlgvax!dennis USMail: CCI; 11490 Commerce Park Dr.; Reston VA 22091 Telephone: +1 703 648 3300
dave@onfcanim.UUCP (Dave Martindale) (09/27/88)
In article <996@rlgvax.UUCP> dennis@rlgvax.UUCP (Dennis.Bednar) writes: > >sundc!root S (9/26-8:36:27) (C,11858,9) (0:26:36) <- 18617 / 171 secs > [1595:0:0:7:1416:171:273:57] [tty0a,0,0,0,0] > >Is the 18617/117 = 108.87 cps just the 64 byte data portion, >or does it include the 6-byte header on every data packet? For any version of uucico I've seen, the byte count is just the useful data transferred, not including the data packets. Also, since the elapsed time is given only to whole seconds, it was probably obtained from the times() system call, so it's only accurate to +- 1 second. So the throughput is between 18617/172 = 108.2 and 18617/170 = 109.5 cps. That's maximum throughput, for all practical purposes.
dave@galaxia.zone1.com (David H. Brierley) (09/27/88)
In article <184@arnold.UUCP> dave@arnold.UUCP (Dave Arnold) writes: >(Henry Spencer) writes: >> In article <183@arnold.UUCP> dave@arnold.UUCP (Dave Arnold) writes: >> >seeing about 450cps, is something wrong, or is this average? >> >> negligible -- they are substantial.) Uucp-g can run a line at circa 90% > >I have never seen 90% bandwidth utilization. My 3B1 at home running >at 1200 baud always gets around 100-120 cps. How are you computing > >(c * 8) / b >where b = baud and c = chars. per second? Dave, I dont want to sound demeaning but is your brain in a holding pattern today? The "baud rate" is not computed by multiplying the cps value by 8. It is true that the baud rate represents the number of bits that flow through the line each second but for every data byte you send there are more than 8 bits. Each data byte is preceeded by (usually) 1 start bit and is then followed by either 1 or 2 stop bits, thus making either 10 or 11 bits of info for each data byte sent. Most people configure their modems for one stop bit and can therefore make the simple approximation of CPS = BAUD / 10. Using that formula you will see that 90% of a 1200 baud line is 108 CPS. If you are getting between 100 and 120 cps then you are doing pretty good. The data rate that you can achieve is very dependent on the machine you are using. For example: I have two machines (VAX 11/78x) that are connected via a dedicated 9600 baud line and I typically see between 400 and 600 cps. I have two other machines that talk to each other through a micom data switch at 9600 baud and I consistently see between 700 and 800 cps. Several of our 9600 baud trailblazer links are capable of hitting 800+ cps if I send them enough data to overcome the startup overhead. -- David H. Brierley Home: dave@galaxia.zone1.com ...!rayssd!galaxia!dave Work: dhb@rayssd.ray.com {sun,decuac,gatech,necntc,ukma}!rayssd!dhb
ostroff@oswego.Oswego.EDU (Boyd Ostroff) (09/28/88)
I've been following this discussion and have a few dumb questions to ask... Since many of the new modems have MNP error checking/correction in hardware/firmware, would it be possible to run UUCP without any packetizing or error checking with MNP in "reliable" mode? I've read there are protocols (F, X ???) which do no error checking. If one of these were used, wouldn't better performance result? Would it be necessary to recompile the source for uucico on *both* ends of the connection to get this to work? In other words, if system #1 has a source license and can re-compile uucico to use F protocol (or whatever), will system #2 use F when it is called? If you don't have uucico source, is there any way to use a protocol other than G? ::::::::::::::::::::::::::::::::::::::::: :: Boyd Ostroff, Technical Director :: System Operator, "The CallBoard" :: Department of Theatre, SUNY Oswego :: - Serving the performing arts - :: Internet: ostroff@oswego.Oswego.EDU :: (315) 947-6414, 300/1200/2400 baud :: Voice: (315) 341-2987 :: UUCP ...sunybcs!oswego!cboard!ostroff :::::::::::::::::::::::::::::::::::::::::
dave@arnold.UUCP (Dave Arnold) (09/28/88)
dennis@rlgvax.UUCP (Dennis.Bednar) writes: > > sundc!root S (9/26-8:36:27) (C,11858,9) (0:26:36) <- 18617 / 171 secs > [1595:0:0:7:1416:171:273:57] [tty0a,0,0,0,0] > > Is the 18617/117 = 108.87 cps just the 64 byte data portion, > or does it include the 6-byte header on every data packet? > Just data. Header not included. uucico starts a timer just before an entire file is about to be tranferred, starts the transfer, counts data bytes in the file as they are transferred, stops the timer when the transfer is complete, and produces the stats. -- Dave Arnold dave@arnold.UUCP {cci632|uunet}!ccicpg!arnold!dave
jbayer@ispi.UUCP (id for use with uunet/usenet) (09/29/88)
In article <944@oswego.Oswego.EDU>, ostroff@oswego.Oswego.EDU (Boyd Ostroff) writes: > I've been following this discussion and have a few dumb questions to ask... > > Since many of the new modems have MNP error checking/correction in > hardware/firmware, would it be possible to run UUCP without any packetizing > or error checking with MNP in "reliable" mode? If you are using a trailblazer + you don't have to bother. The trailblazer strips out the uucp stuff on the sending end, and puts it back in on the receiving end. (You do need a trailblazer on each end). This speeds up the throughput a lot. Jonathan Bayer Intelligent Software Products, Inc.
henry@utzoo.uucp (Henry Spencer) (09/30/88)
In article <944@oswego.Oswego.EDU> ostroff@oswego.oswego.edu.UUCP (Boyd Ostroff) writes: >Since many of the new modems have MNP error checking/correction in >hardware/firmware, would it be possible to run UUCP without any packetizing >or error checking with MNP in "reliable" mode? It's not necessarily a good idea. Remember that you still have connections from modem to host on both ends: those connections are not necessarily 100% error-free, especially when flow control is minimal and characters are pouring in at high speed. >...Would it be >necessary to recompile the source for uucico on *both* ends of the connection >to get this to work? In other words, if system #1 has a source license and >can re-compile uucico to use F protocol (or whatever), will system #2 use >F when it is called? If you don't have uucico source, is there any way to >use a protocol other than G? Not unless your system supplier has supplied a uucico with f protocol in it. The two uucicos negotiate protocol at the beginning of the conversation; both must speak a protocol before either will use it. We're not talking about minor differences in usage here -- the different protocols are completely different languages. -- The meek can have the Earth; | Henry Spencer at U of Toronto Zoology the rest of us have other plans.|uunet!attcan!utzoo!henry henry@zoo.toronto.edu
csg@pyramid.pyramid.com (Carl S. Gutekunst) (09/30/88)
In article <944@oswego.Oswego.EDU> ostroff@oswego.oswego.edu.UUCP (Boyd Ostroff) writes: >Since many of the new modems have MNP error checking/correction in >hardware/firmware, would it be possible to run UUCP without any packetizing >or error checking with MNP in "reliable" mode? > >I've read there are protocols (F, X ???) which do no error checking. Also 't' and 'e'. Of these, only 'f' is suitable over error-correcting modems, since the other three have no provisions for flow control, and no end-to-end error checking. That is, when talking over serial lines, you must have some way for the modem and the computer to occasionally tell each other "Slow down! You're sending too fast for me!" That's flow control, and on RS-232 lines it is usually done with XON-XOFF (CTRL-Q and CTRL-S). (The 'g' protocol uses a more sophisticated technique called a "sliding window.") In addition, you want some kind of protection against overruns and bits that scrambled between the modem and the computer. So you need a protocol that also does some error checking of its own. That said, 'f' works exceptionally well over MNP modems and TrailBlazers; in fact, before Telebit added 'g' protocol support, you could *only* use 'f' over a TrailBlazer. You you still have to use 'f' on the USR 9600HST and most other pseudo-standard high-speed modems. Unfortunately, 'f' has a very high overhead on binary files, much higher than 'g', because it is a 7-bit protocol that was intended for X.29 links. So it works well on plain text, but it gets bad on binary files, and positively stinky on compressed files! To use the alternative protocols like 'g', 'f', et al, they have to be built into the uucico's at both ends of the connection. Without uucp source, you cannot add any new protocols to your uucico. If your uucico does not have at least 'f', you should scream at your vendor. <csg>
brian@ncrcan.Toronto.NCR.COM (Brian Onn) (09/30/88)
In article <1988Sep29.174529.26357@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <944@oswego.Oswego.EDU> ostroff@oswego.oswego.edu.UUCP (Boyd Ostroff) writes: >>Since many of the new modems have MNP error checking/correction in >>hardware/firmware, would it be possible to run UUCP without any packetizing >>or error checking with MNP in "reliable" mode? > >It's not necessarily a good idea. Remember that you still have connections >from modem to host on both ends: those connections are not necessarily >100% error-free, especially when flow control is minimal and characters are >pouring in at high speed. > But in practice, it does work, and work well. We have been using MNP modems and e and f protocols for some time now for shipping news around, and have yet to see a problem. We run the computer<-->modem link at 9600 bps with hardware flow control. A 2400 bps modem<-->modem link can achieve throughputs of up to 500 cps with MNP level 5. Brian -- +-------------------+--------------------------------------------------------+ | Brian Onn | UUCP:..!{uunet!mnetor, watmath!utai}!lsuc!ncrcan!brian | | NCR Canada Ltd. | INTERNET: Brian.Onn@Toronto.NCR.COM | +-------------------+--------------------------------------------------------+
dave@arnold.UUCP (Dave Arnold) (10/03/88)
dave@galaxia.zone1.com (David H. Brierley) writes: > > Each data byte is preceeded by (usually) 1 start bit and is then > followed by either 1 or 2 stop bits, thus making either 10 or 11 > bits of info for each data byte sent. Most people configure their > modems for one stop bit True. But again I say, it all depends on what you are measuring. If you want to compute the *TRUE* line utilization of an async line, then you need to multiply by 8, especially if you are comparing this value against a synchronous line. I am seeing the same 400-600 cps on a direct 9600 baud link between a uVax and something else. Can somebody out there tell me where the bottleneck on the VAX is? P.S. Explain how I can be getting 120 CPS on a 1200 baud line. -- Dave Arnold dave@arnold.UUCP {cci632|uunet}!ccicpg!arnold!dave
egisin@watmath.waterloo.edu (Eric Gisin) (10/03/88)
In article <201@arnold.UUCP>, dave@arnold.UUCP (Dave Arnold) writes: > I am seeing the same 400-600 cps on a direct 9600 baud link between > a uVax and something else. Can somebody out there tell me where the > bottleneck on the VAX is? Lack of CPU power mostly. The BSD tty device drivers passes input characters one-at-a-time to the line drivers through the line switch l_rint (receiver interrupt) function. The expensive calling convention on the VAX makes things worse here. A 785 won't handle trailblazer input either, it only gets 1100-1200 B/s on an idle system. It can easily do output at full speed to a more modern Unix box though.
csch@tmpmbx.UUCP (Clemens Schrimpe) (10/04/88)
We're using a USR Courier HST 9600 with MNP lev. 5 and achieve up to
15027 chars./sec. by using the 'f' protocol.
BUT: Xon/Xoff flow control must be understood by the MODEM, so most modems
will be UNUSABLE for 'g' protocol unless you're willing to turn
flow control on/off vor each connection - and (another problem)
most CALLED sites don't have the chance to turn on/off flow control
depending on the caller :-(
To avoid this you can either use:
- Hardware flowcontrol (RTS/CTS)
(BEWARE: most computers "think" of RTS in a different way, than
most modems do)
- Buy a smart modem, which AUTOMATICALLY turn on/off flow control
depending on whether the current connection is MNP controlled
or not (newer HSTs have the AT&I5 option)
Clemens Schrimpe, netmbx Berlin
--
UUCP: csch@tmpmbx.UUCP {pyramid,unido,altger}!tmpmbx!csch
BITNET: csch@db0tui6.BITNET csch@tub.BITNET
PHONE: +49-30-332 40 15 TELEX: 186672 net d
PSI: PSI%26245300043106::CSCHchris@mimsy.UUCP (Chris Torek) (10/05/88)
>In article <201@arnold.UUCP> dave@arnold.UUCP (Dave Arnold) asks >>where the bottleneck on the VAX is? In article <21254@watmath.waterloo.edu> egisin@watmath.waterloo.edu (Eric Gisin) writes: >Lack of CPU power mostly. And inefficiency: >The BSD tty device drivers passes input characters one-at-a-time >to the line drivers through the line switch l_rint (receiver interrupt) >function. >The expensive calling convention on the VAX makes things worse here. Just as bad, each input character is passed to the reading program one at a time through ureadc(). We have been reluctant to fix either of these mainly for two reasons: The old tty code is both large and fragile; and we would like to replace the line-switch structure with something like Streams (not STREAMS). The latter mandates redoing the code in enough places that fixing the one-at-a-time business will be trivial :-) . -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
dave@arnold.UUCP (Dave Arnold) (10/05/88)
In article <21254@watmath.waterloo.edu>, (Eric Gisin) writes: > I write: > > I am seeing the same 400-600 cps on a direct 9600 baud link between > > a uVax and something else. Can somebody out there tell me where the > > bottleneck on the VAX is? > > The BSD tty device drivers passes input characters one-at-a-time > to the line drivers through the line switch l_rint (receiver interrupt) > function. I forgot to mention, my results are on a VAX running *VMS*. Don't forget, there are other OS's to run on a VAX besides UN*X. We are working on a CICO for VMS. Anybody know if VMS TTDRIVER overhead is higher than UNIX? -- Dave Arnold dave@arnold.UUCP {cci632|uunet}!ccicpg!arnold!dave
wes@obie.UUCP (Barnacle Wes) (10/07/88)
In article <201@arnold.UUCP>, dave@arnold.UUCP (Dave Arnold) writes: > I am seeing the same 400-600 cps on a direct 9600 baud link between > a uVax and something else. Can somebody out there tell me where the > bottleneck on the VAX is? Sure. VMS. No joking - it spends a lot of time making sure that you are to be allowed to read that character, this adds a lot of overhead. > P.S. Explain how I can be getting 120 CPS on a 1200 baud line. Easy. VMS can verify that you are allowed to read that character and still keep up with 1200 baud communications. You'll probably get about 240 cps out of a 2400 baud line, too. I don't think you'll get 480 out of a 4800 baud line, however. If you want more detail, ask terry@wsccs.UUCP - he can tell you more than you ever wanted to know about how much VMS slows character i/o on a MicroVAX II :-). -- {hpda, uwmcsd1}!sp7040!obie!wes "How do you make the boat go when there's no wind?" -- Me --
tboutell@vax1.acs.udel.EDU (Thomas B Boutell) (10/09/88)
>>How are you computing bandwidth utilization? >>(c * 8) / b >>where b = baud and c = chars. per second? >You probably want to multiply by (at least) 10 instead of just 8 >since the 1 start bit and 1 to 2 stop bits count here as well. This is not true under all circumstances, even with asynchronous modems. The Telebit Trailblazer and USR HST 9600, to name two, are capable of eliminating the two stop bits when communicating at their highest speeds; however, your suggestion of multiplying by ten rather than eight under most circumstances is correct. (To be specific, when using a 2400 baud- or- less device, it's definitely correct over an asynchronous link.)
chris@mimsy.UUCP (Chris Torek) (10/10/88)
>>>How are you computing bandwidth utilization? >>>(c * 8) / b >>>where b = baud and c = chars. per second? >>You probably want to multiply by (at least) 10 instead of just 8 >>since the 1 start bit and 1 to 2 stop bits count here as well. In article <2032@udccvax1.acs.udel.EDU> tboutell@vax1.acs.udel.EDU (Thomas B Boutell) writes: >This is not true under all circumstances, even with asynchronous modems. >The Telebit Trailblazer and USR HST 9600, to name two, are capable of >eliminating the two stop bits when communicating at their highest speeds; The problem is that I cannot get the Vax (or Sun or . . .) to use anything less than 10 bits. Remember, the idea is to find the use of the `available' bandwidth, which is no better than the rate at which I can get my Vax hardware to send or receive. (I know: `fixed in 4.0' :-) ) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
henry@utzoo.uucp (Henry Spencer) (10/10/88)
In article <2032@udccvax1.acs.udel.EDU> tboutell@vax1.acs.udel.EDU (Thomas B Boutell) writes: >The Telebit Trailblazer and USR HST 9600, to name two, are capable of >eliminating the two stop bits when communicating at their highest speeds... However, this is academic unless themodem-to-host links are running at a still higher baud rate, since the start and stop bits (there is normally only one stop bit, but the modems take the start bit out too) do have to be there on an asynchronous modem-to-host link. -- The meek can have the Earth; | Henry Spencer at U of Toronto Zoology the rest of us have other plans.|uunet!attcan!utzoo!henry henry@zoo.toronto.edu
terry@wsccs.UUCP (Every system needs one) (10/12/88)
In article <21254@watmath.waterloo.edu>, egisin@watmath.waterloo.edu (Eric Gisin) writes: > In article <201@arnold.UUCP>, dave@arnold.UUCP (Dave Arnold) writes: > > I am seeing the same 400-600 cps on a direct 9600 baud link between > > a uVax and something else. Can somebody out there tell me where the > > bottleneck on the VAX is? > > Lack of CPU power mostly. > The BSD tty device drivers passes input characters one-at-a-time > to the line drivers through the line switch l_rint (receiver interrupt) > function. > The expensive calling convention on the VAX makes things worse here. > > A 785 won't handle trailblazer input either, > it only gets 1100-1200 B/s on an idle system. > It can easily do output at full speed to a more modern Unix box though. The problem, Eric, is most likely the DHV-11 interrupt controller that the uVAX comes with, not any inherent problems with the machine. A DMA controller will ease the problem greatly. The BSD drivers only do this 1) if they are very badly written or 2) if some idiot turns on CBREAK and sets the buffer size to 1 and demands flushing. Now... I'm not saying this is the case, but it seems to me that if you were to block reads with either a timeout or a selectio and read for GPACKSIZ characters, this problem wouldn't happen. The "expensive calling convention" would only come into play if you were dumb enough to use vcc. While I am unsure as to 19200 baud (I have yet to get my grubby hands on a 19200 baud board for the uVAX ;-), I do KNOW that our emulation/transfer software CAN do 9600, so there is no inherent architecture faults. As to inefficiency of interrupt controllers, that's bogus. I have an interrupt driver for an 8Mghz AT that will do 57K under DOS, and have had no problem with 19200 and an ocassional 38.4 on the same machine under Xenix. | Terry Lambert UUCP: ...{ decvax, ihnp4 } ...utah-cs!century!terry | | @ Century Software OR: ...utah-cs!uplherc!sp7040!obie!wsccs!terry | | SLC, Utah | | These opinions are not my companies, but if you find them | | useful, send a $20.00 donation to Brisbane Australia... | | 'I have an eight user poetic liscence' - me |
ronc@fai.UUCP (Ronald O. Christian) (10/18/88)
In article <1210@tmpmbx.UUCP> csch@tmpmbx.UUCP (Clemens Schrimpe) writes: >BUT: Xon/Xoff flow control must be understood by the MODEM, so most modems > will be UNUSABLE for 'g' protocol unless you're willing to turn > flow control on/off for each connection [...] You can do it in the chat script. Ugly, but it works. Or... if your modem has the option of turning xon/xoff on or off in one direction only, you might find that you can, for instance, tell the modem to honor xon/xoff from the host but not to send an xoff character to the host no matter what. This seems to sit happily with the g protocol, and also doesn't interfere with dial-in terminal sessions. Ron -- Ronald O. Christian (Fujitsu America Inc., San Jose, Calif.) {amdahl, pyramid, sun, unisoft, uunet}!fai!ronc -or- ronc@fai.com Calling all Fujitsu Usenet sites! Contact fai!ronc or ronc@fai.com to establish uucp connection.
terry@wsccs.UUCP (Every system needs one) (10/22/88)
In article <13922@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes: > >>You probably want to multiply by (at least) 10 instead of just 8 > >>since the 1 start bit and 1 to 2 stop bits count here as well. > > In article <2032@udccvax1.acs.udel.EDU> tboutell@vax1.acs.udel.EDU > (Thomas B Boutell) writes: > >This is not true under all circumstances, even with asynchronous modems. > >The Telebit Trailblazer and USR HST 9600, to name two, are capable of > >eliminating the two stop bits when communicating at their highest speeds; > > The problem is that I cannot get the Vax (or Sun or . . .) to use anything > less than 10 bits. > > Remember, the idea is to find the use of the `available' bandwidth, > which is no better than the rate at which I can get my Vax hardware > to send or receive. (I know: `fixed in 4.0' :-) ) So seldom does anyone get to correct Chris and get away with it by being 100% correct and therefore untouchable unless he hunts down something stupid you've said somewhere else ;-), that I must take this gloden opportunity: The actual connection on the line is SYNCHRONUS, removing the need for stop-bits. While it is true that you still communicate to the TrailBlazer or the HST asynchronusly, the actual connection is synchronus; Timing is provided by a seperate clock, not the start and stop bits which are needed to prevent framing errors in an asynchronus connection. | Terry Lambert UUCP: ...{ decvax, ihnp4 } ...utah-cs!century!terry | | @ Century Software OR: ...utah-cs!uplherc!sp7040!obie!wsccs!terry | | SLC, Utah | | These opinions are not my companies, but if you find them | | useful, send a $20.00 donation to Brisbane Australia... | | 'I have an eight user poetic liscence' - me |
guy@auspex.UUCP (Guy Harris) (10/28/88)
>> The problem is that I cannot get the Vax (or Sun or . . .) to use anything >> less than 10 bits. >> >> Remember, the idea is to find the use of the `available' bandwidth, >> which is no better than the rate at which I can get my Vax hardware >> to send or receive. (I know: `fixed in 4.0' :-) ) > > The actual connection on the line is SYNCHRONUS, removing the >need for stop-bits. While it is true that you still communicate to the >TrailBlazer or the HST asynchronusly, the actual connection is synchronus; >Timing is provided by a seperate clock, not the start and stop bits which >are needed to prevent framing errors in an asynchronus connection. Umm, I think you missed his point. The point is that you can't stuff data down the modem any faster than the serial port will allow; any extra bandwidth opened up by not using stop bits can't be spent sending data from the host, because the data isn't coming in fast enough. It has to be spent sending error-correcting-code bits or something like that. Another way of looking at it is that if my host talks to the modem at 19.2KB, I can at most send 1,920 octets a second over the modem, even if the modem can send data at 1GB/second. If it can send data faster than 1,920 octets a second, it will spend some time either sending octets that weren't given to it from the 19.2KB connection to the host, or twiddling its thumbs.
terry@wsccs.UUCP (Every system needs one) (11/03/88)
In article <331@auspex.UUCP>, guy@auspex.UUCP (Guy Harris) writes: > I write: > >need for stop-bits. While it is true that you still communicate to the > >TrailBlazer or the HST asynchronusly, the actual connection is synchronus; > >Timing is provided by a seperate clock, not the start and stop bits which > >are needed to prevent framing errors in an asynchronus connection. > > Umm, I think you missed his point. The point is that you can't stuff > data down the modem any faster than the serial port will allow; any > extra bandwidth opened up by not using stop bits can't be spent sending > data from the host, because the data isn't coming in fast enough. It > has to be spent sending error-correcting-code bits or something like > that. But the synchronus connection is what buys you such a high data rate in the first place... the multi-carrier modulation used by Telebit requires it by virtue of their encapsulation method. The compression on the TB buys you exactly what you are saying it can't buy you... putting characters in one modem and pulling them out another at a higher rate than the modulation method used can push bits. By incorporating compression encapsulation into a transfer protocol, and using this protocol to transfer files, you CAN put more bits through the serial port than the machine is capable of. I STANDARDLY do this daily, getting an average of 40% compression at 9600 between my DOS, my Xenix, and the VMS and Ultrix machines I have access to. My effective baud rate is 9600 * 1.4 = 13340. I have GOTTEN 95% on some graphics files. You do the math. | Terry Lambert UUCP: ...{ decvax, uunet } ...utah-cs!century!terry | | @ Century Software OR: ...utah-cs!uplherc!sp7040!obie!wsccs!terry | | SLC, Utah | | These opinions are not my companies, but if you find them | | useful, send a $20.00 donation to Brisbane Australia... | | 'I have an eight user poetic liscence' - me |
guy@auspex.UUCP (Guy Harris) (11/08/88)
>But the synchronus connection is what buys you such a high data rate in the >first place... the multi-carrier modulation used by Telebit requires it by >virtue of their encapsulation method. You're *still* missing the point. The high data rate doesn't buy you anything in terms of raw throughput *unless you can get the bits to the modem that fast*. >The compression on the TB buys you exactly what you are saying it can't buy >you... putting characters in one modem and pulling them out another at a >higher rate than the modulation method used can push bits. Excuse me, but I didn't say it wouldn't buy you that. What I said was that it couldn't get the characters *from end-to-end* - that is, from *host* to *host* - faster than you can get the characters from the host to the modem. >By incorporating compression encapsulation into a transfer protocol, and >using this protocol to transfer files, you CAN put more bits through the >serial port than the machine is capable of. If you do the compression in the modem, it only increases the speed of the modem-to-modem connection - which helps only if you can get stuff into the modem at that speed. If you do the compression in the host, you can think of it as a way to increase the speed that you can pump data into the modem - but this has nothing to do with the speed of the modem. >I STANDARDLY do this daily, getting an average of 40% compression at >9600 between my DOS, my Xenix, and the VMS and Ultrix machines I have >access to. My effective baud rate is 9600 * 1.4 = 13340. That's nice. Try getting that effective baud rate if your modem can't handle data coming into it *from the host* at 9600 baud. Chris's point still stands; if you have modems that, complete with compression and other tricks, can send 1 GB of data over the wire, but the modems can only receive data from the host at 9600 baud, you're going to get an effective baud rate no better than 9600 baud times whatever compression factor you get from host software.