grr@cbmvax.UUCP (George Robbins) (04/04/88)
Well, the one question that comes to mind when people talk about the
Telebit Trailblazer modems is how fast they really are when running
the normal uucp protocols in day to day use. I've been collecting
some statistics here that shed some light on the subject:
Answer: > 10 times as fast as 1200 baud modems
> 5 times as fast as 2400 baud modems
That's what you really wanted to know, right? 8-)
Here are the statistics those numbers were based on. Note that a considerable
amounts of "unqualified" data was thrown away because of the caveats below
or because I talk to a system at both 1200 or 2400 baud.
Unfortunatly, I don't have any Courier HST, Hayes or direct connect lines
to compare these numbers with. It would be interesting to some sythetic
(i.e. transfer 1 Mbyte) tests with different modems/direct connect lines
for contrast.
Caveats:
1) The times are based on "receive" transfers only. The "transmit" times
uucp gives for trailblazers are highly bogus because uucp thinks the
transfer is "done" while the trailblazer still has (allegedly) up to
10K of data buffered internally. This propensity results in considerably
inflated speed estimates even on normal size news batches. For the
sake of consistancy, all "transmit" times are discarded.
2) "transmit" rates, even on low speed modems, are typically 20-50% faster
than "receive" rates. I am not sure where to put the blame for this
and the problem with measuring the "transmit" times for the Trailblazers
makes it impossible to determine whether this is also the case on
higher speed transfers. We'll just have to call lay claim to using
"worst case" values...
3) Transfers lasting only a few seconds have been discarded due to the
timer granularity in the SYSLOG file. Typically these are "control card"
files. The criteria used for the "peak" column are somewhat stricter.
4) cbmvax is a VAX 785 running Ultrix. It is typically fairly lightly
loaded except when news batching or unbatching happens to coincide with
uucp transfers. There are two Trailblazers used for both incoming and
outgoing uucp calls, both in PEP mode and with 1200 and 2400 baud modems.
There are also two USR Courier 2400 baud modems available for uucp usage
when the Trailblazers are busy, but these haven't seen much usage lately.
The innterface rate on the Trailblazers is not "locked".
5) A lot seems to depend on the system the Trailblazer is attached to. I
am not sure whether some of the systems I talk to have their interface
rates set to 9600 bps instead of 19.2K bps. Doing so tends to limit
peak transfer rates to around 7000 bps. Unfortunatly, distance and
wimpyness are somewhat correlated in the systems I talk to, so it's hard
to draw any supportable conclusions.
March 1988: uucp usage report for cbmvax on Sun Apr 3 15:30:36 EDT 1988
1200 baud only
==============
system transfer files fail M-bytes hours speed peak
======= ============ ====== ==== ======== ====== ===== =====
allegra slow receive 40 0 0.067 0:15 730 bps 813 bps
burdvax slow receive 45 0 0.117 0:24 786 bps 857 bps
hutch slow receive 72 0 0.223 0:54 677 bps 785 bps
ihnp4 slow receive 106 0 0.439 1:58 619 bps 796 bps
liberty slow receive 16 0 0.093 0:20 742 bps 759 bps
molly slow receive 21 0 0.099 0:22 733 bps 806 bps
snark slow receive 66 0 0.192 0:44 716 bps 792 bps
swatsun slow receive 54 0 0.089 0:19 750 bps 818 bps
*udel slow receive 31 0 0.061 0:18 554 bps 755 bps
------ ---- -------- ------ -----
451 0 1.380 5:34 689 bps
2400 baud only
==============
system transfer files fail M-bytes hours speed peak
======= ============ ====== ==== ======== ====== ===== =====
amiga slow receive 1058 0 2.997 7:06 1172 bps 1348 bps
bpa slow receive 626 0 8.600 16:42 1429 bps 1523 bps
*osu-cis slow receive 38 0 3.145 8:15 1058 bps 1151 bps
*rutgers slow receive 668 0 20.686 45:45 1255 bps 1594 bps
ulowell slow receive 74 0 0.126 0:17 1177 bps 1455 bps
uunet slow receive 206 0 0.533 1:20 1098 bps 1322 bps
vu-vlsi slow receive 58 0 0.215 0:30 1192 bps 1382 bps
------ ---- -------- ------ -----
2728 0 36.306 79:55 1260 bps
Trailblazer+ uucp
=================
system transfer files fail M-bytes hours speed peak
======= ============ ====== ==== ======== ====== ===== =====
amiga fast receive 64 0 1.414 0:52 4513 bps 7016 bps
bpa fast receive 4037 0 52.648 17:38 8289 bps 12317 bps
pyramid fast receive 15 0 0.059 0:01 6240 bps 7419 bps
rutgers fast receive 451 0 13.980 6:53 5636 bps 7246 bps
uunet fast receive 247 0 1.167 0:34 5611 bps 10173 bps
vu-vlsi fast receive 125 2 0.859 0:20 6876 bps 9117 bps
------ ---- -------- ------ -----
4939 2 70.127 26:18 7407 bps
International X.25
==================
system transfer files fail M-bytes hours speed peak
======= ============ ====== ==== ======== ====== ===== =====
+cbmbsw slow receive 433 0 0.432 8:34 140 bps 169 bps
------ ---- -------- ------ -----
433 0 0.432 8:34 140 bps
* (a terminal server or port switch involved here)
+ (X.25 via tymenet dialout port at 1200 bps)
--
George Robbins - now working for, uucp: {uunet|ihnp4|rutgers}!cbmvax!grr
but no way officially representing arpa: cbmvax!grr@uunet.uu.net
Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)pjh@mccc.UUCP (Peter J. Holsberg) (04/05/88)
In article <3570@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes:
== Well, the one question that comes to mind when people talk about the
== Telebit Trailblazer modems is how fast they really are when running
== the normal uucp protocols in day to day use. I've been collecting
== some statistics here that shed some light on the subject:
==
== March 1988: uucp usage report for cbmvax on Sun Apr 3 15:30:36 EDT 1988
==
== 1200 baud only
== ==============
==
== system transfer files fail M-bytes hours speed peak
== ======= ============ ====== ==== ======== ====== ===== =====
== allegra slow receive 40 0 0.067 0:15 730 bps 813 bps
== burdvax slow receive 45 0 0.117 0:24 786 bps 857 bps
== hutch slow receive 72 0 0.223 0:54 677 bps 785 bps
== ihnp4 slow receive 106 0 0.439 1:58 619 bps 796 bps
== liberty slow receive 16 0 0.093 0:20 742 bps 759 bps
== molly slow receive 21 0 0.099 0:22 733 bps 806 bps
== snark slow receive 66 0 0.192 0:44 716 bps 792 bps
== swatsun slow receive 54 0 0.089 0:19 750 bps 818 bps
== *udel slow receive 31 0 0.061 0:18 554 bps 755 bps
== ------ ---- -------- ------ -----
== 451 0 1.380 5:34 689 bps
==
George, don't you mean "cps" instead of "bps" (bytes/second?)?
I'm not sure what you mean by "1200 baud only". Is one of the systems
using a 1200 bps modem?
I connect to princeton; both of us run TB+s at 9600 bps, and see cps
rates in the order of what you have for bps rates above. Does this make
any sense? Are we set up incorrectly? Thanks.
--
Peter Holsberg UUCP: {rutgers!}princeton!mccc!pjh
Technology Division CompuServe: 70240,334
Mercer College GEnie: PJHOLSBERG
Trenton, NJ 08690 Voice: 1-609-586-4800mem@zinn.MV.COM (Mark E. Mallett) (04/08/88)
In article <3570@cbmvax.UUCP>, grr@cbmvax.UUCP (George Robbins) writes: > ... uucp thinks the > transfer is "done" while the trailblazer still has (allegedly) up to > 10K of data buffered internally. Is this true? Can the host see the transfer as complete when there is still up to 10KB buffered in the modem? 10K could represent a lot of mail or news or control files that would have been deleted: what happens if the phone connection breaks at this point? What is done to ensure that no outgoing files are deleted until the receiver actually records them, given the above statement? -mm- -- Mark E. Mallett PO Box 4188/ Manchester NH/ 03103 Bus. Phone: 603 645 5069 Home: 603 424 8129 uucp: mem@zinn.MV.COM (...decvax!elrond!zinn!mem or ...sii!zinn!mem) BIX: mmallett
honey@umix.cc.umich.edu (Peter Honeyman) (04/10/88)
the timer report mechanism doesn't wait for completion ack (CY). but the uucp "upper layer protocol" doesn't think the transfer is successful until it receives a completion packet (CY). peter
sl@van-bc.UUCP (pri=-10 Stuart Lynne) (04/11/88)
In article <297@zinn.MV.COM> mem@zinn.MV.COM (Mark E. Mallett) writes: >In article <3570@cbmvax.UUCP>, grr@cbmvax.UUCP (George Robbins) writes: >> ... uucp thinks the >> transfer is "done" while the trailblazer still has (allegedly) up to >> 10K of data buffered internally. > >Is this true? Can the host see the transfer as complete when there is >still up to 10KB buffered in the modem? 10K could represent a lot of >mail or news or control files that would have been deleted: what happens >if the phone connection breaks at this point? What is done to ensure >that no outgoing files are deleted until the receiver actually records >them, given the above statement? > It's true, but with qualifications. Uucico on the sending host essentially has a conversation with the uucico in the receiving host. A series of messages are exchanged, something along the following lines: Sender Receiver S filename - sending file SY - OK <data> CY or CN5 The sender sends a message with the name of the file it want's to send. The receiver responds SY if it's willing to receive it. (Or SN2 - not permitted, SN4 - can't make workfile.) If SY, the sender sends the file. When it is finished it stops timing the transfer. It now waits for the CY message. If CN5 is received the sender knows that the file was not transmitted properly. The timings seem to represent the time to transfer or receive the file, not including waiting for the response message. On direct machine to machine transfers this will be almost the same on both sides. With a 10k buffer in the middle it can be out quite a bit! -- {ihnp4!alberta!ubc-vision,uunet}!van-bc!Stuart.Lynne Vancouver,BC,604-937-7532