jparnas@larouch.UUCP (Jacob Parnas) (08/02/89)
I've finally was able to test the Microcom QX/V.32c at 38400 baud. I am very impressed with its performance. All tests were done between two IBM RT/PCs running the latest release of 4.3 BSD and two Microcom QX/V.32c modems with Version 1.5 of the EPROMS. The RTs both had Dickens Data Systems intelligent 8 Port I/O boards. During normal tip session, I got over 3300 cps effective throughput catting a 115000 byte /etc/hosts file. Interactive response was fantastic. There were delays on character echos. Simply amazing throughput. SLIP response was fairly good as well. I'm runing generic 4.3 BSD SLIP. Cating /etc/hosts over slip went at about 2600-2700 cps. ftp of /etc/hosts went at about 2.2 kilobytes/second. Binary files seemed to ftp at between 1.2 and 1.5 kilobytes/second. On the down side, character echos over slip were definately slower than when compression was turned off on the same modems. Hopefully the soon-to-come SLIP with header compression should solve this problem. I believe that a recent posting stating that 38,400 support didn't help throughput much was in error, since some things were much faster when connected at 38400 baud than at 19200 with the same modem. ------------------------------------------------------------------------------ | Jacob M. Parnas | DISCLAIMER: The above message is from | | IBM Thomas J. Watson Research Ctr. | me and is not from my employer. IBM | | Arpanet: jparnas@ibm.com | might completely disagree with me. | | Bitnet: jparnas@yktvmx.bitnet \---------------------------------------| | Home: ..!uunet!bywater!acheron!larouch!jparnas | Phone: (914) 945-1635 | ------------------------------------------------------------------------------
david@ms.uky.edu (David Herron -- One of the vertebrae) (08/03/89)
In article <361@larouch.UUCP> jparnas@larouch.UUCP (Jacob Parnas) writes: >During normal tip session, I got over 3300 cps effective throughput >catting a 115000 byte /etc/hosts file. Interactive response was fantastic. >There were delays on character echos. Simply amazing throughput. That's the kind of experience I'd expect for a V.32 modem -- and about what we were getting in the terminal room at Usenix. That is, what we *would* be getting if all our sessions were to local hosts. My login sessions ran reasonably well -- well enough that I was reading news from there. Others who were less fortunately connected than I were experiencing long delays, especiallly the chap from Scotland. The terminal room was run off a T2500 ... I don't know what baud rate and/or compression was used. >SLIP response was fairly good as well. I'm runing generic 4.3 BSD SLIP. >Cating /etc/hosts over slip went at about 2600-2700 cps. ftp of /etc/hosts >went at about 2.2 kilobytes/second. Binary files seemed to ftp at between >1.2 and 1.5 kilobytes/second. For reference: I've been doing some experimentation recentlly with the SLIP driver that comes with Ultrix. Between a Vs2000 and a uVaxII over a 9600 baud straight serial wire: terminal sessions were bursty. Individual bursts were at the right speed, but there were pauses. an xterm run over that link was even burstier ftp of a largish file (140K /etc/termcap) went at 8kbits/sec or about 90% of line speed. This was over a *quiet* line copying largish files into an NFS mounted file system failed strangely, but I was using the same packet-size parameters as we use over ETHER. Probably I was simply overrunning some buffering somewhere. ping time is 200 ms. You're getting 22,000 bits per sec on a 38,400 line or about 66% of line speed. Yes I know that things don't work as efficiently at higher baud rates. Rather, that it's nowhere near a simple comparison ... Over another link ... this one is again at 9600 baud. But it has two terminal networks in between the two machines. One is a state-wide AT&T ISN network that we call KECNET, the other part is a connection through the campus-wide Ung. Bass broadband network & terminal servers. We lose hardware flow control because the ISN net doesn't do it. One end is the same uVaxII and the other end is an 11/750 in Louisville. Terminal sessions are burstier haven't tried xterm ftp of largish files gets ~3.5 k bits per sec -- <50% line utilization haven't tried NFS for some reason this link has routed traffic going over it and the other doesn't. This link also has the MTU set down to 256 bytes. ping time is 500 ms. -- <- David Herron; an MMDF guy <david@ms.uky.edu> <- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET <- "Amiga software is as good and as bad as PC software. The difference is <- that AmigaDOS waves bye-bye before it dies, while the PC just freezes."
grr@cbmvax.UUCP (George Robbins) (08/03/89)
In article <361@larouch.UUCP> jparnas@larouch.UUCP (Jacob Parnas) writes: > > I believe that a recent posting stating that 38,400 support didn't help > throughput much was in error, since some things were much faster when > connected at 38400 baud than at 19200 with the same modem. I'm not sure that was exactly the claim. If you are sending compressible data, then a bit rate of up to "compresssion factor"*"real channel thruput" is quite handy. It may or may not be practical on your "average" unix system due to the usual character I/O overhead/latency problems. If you have a fast machine, running effectivly single users and/or an "intelligent" I/O card, this may not be a problem. Could you run the compress utility using this host file for input and report what the compression factor there was? -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
jparnas@larouch.uucp (Jacob Parnas) (08/06/89)
In article <7525@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes: > >Could you run the compress utility using this host file for input and >report what the compression factor there was? > uncompressed /etc/hosts is 110025 characters long compressed /etc/hosts is 41724 characters long Also, I turned on flow control and got the following troughputs on the Microcom QX/V.32c (with ftp over SLIP with modems hooked up at 38400 baud between 2 RT PC running 4.3 BSD with Dickens Data Systems 8 Port boards with 1 KByte buffer per port): compressed file: .89 Kbytes/second uncompressed binary: 2 Kbytes/second uncompressed /etc/hosts: 2.6 Kbytes/second Also, I did (cd /usr; tar cf - man ) | rsh valimar "(cd /usr; tar xpf -)" sending 6200 Kbytes of manual pages in about 45 minutes = 2351 bytes/second. I'm very impressed. ------------------------------------------------------------------------------ | Jacob M. Parnas | DISCLAIMER: The above message is from | | IBM Thomas J. Watson Research Ctr. | me and is not from my employer. IBM | | Arpanet: jparnas@ibm.com | might completely disagree with me. | | Bitnet: jparnas@yktvmx.bitnet \---------------------------------------| | Home: ..!uunet!bywater!acheron!larouch!jparnas | Phone: (914) 945-1635 | ------------------------------------------------------------------------------
loverso@Xylogics.COM (John Robert LoVerso) (08/15/89)
As another datapoint, I've had abysmal results with all the Microcom modems I've tested. Back in June, I had a pair of QX/V.32cs. They worked fine inside the building and from home. I brought one with me to the Baltimore USENIX and I couldn't get it to connect to its twin sitting back here in our machine room, at ANY speed. However, an internal 2400 baud modem in a laptop had no problem talking to the QX/V.32c back here, using the same phone line! When I brought the modem back here, it worked fine. At the same time, we had flawless performace from the Telebit T2500s that were being used in the terminal room. > ... > The [Baltimore USENIX] terminal room was run off a T2500 ... I don't > know what baud rate and/or compression was used. > ... Just for the record, both sides were at 9600 and were using Van Jacobson's header compression code, one end on a Sun3 and the other on an Annex. For most of the show, the Sun3 sitting in the terminal room was using a SLIP link at 38400 to the Annex (since there was no Ethernet at all in the room). I recently had a pair of Microcom QX/3296s on evaluation. These do MNP.6, as opposed to the MNP.9 on the QX/V.32c. They do have a "uucp spoofing mode", or so the manual says. It just lists the command to turn it on, but says nothing about what it does. I was interested in trying it, given that the QX/V.32c was beaten by a Trailblazer-Plus in terms of throughput over a UUCP connection. When I first unpacked the QX/3296s, one of them was acting flakey because about 99% of the time it wouldn't pick up the phone line when given a dial command (i.e., it couldn't get a dialtone - I'd hear the relay go off hook, but I'd get nothing on the speaker - plugging in a phone got me a dialtone). All of a sudden [no good reason why - I hadn't changed any switches or configuration], it started working fine. I got the pair to work and was somewhat satisfied with the performance. I put the previously flakey one in my machine room and took the other one home. When I got home, the modem would no longer pass self test. To make a long story shorter - we're buying T2500s. I've never had problems like this with my Trailblazers. -- John Robert LoVerso Xylogics, Inc. 617/272-8140 loverso@Xylogics.COM Annex Terminal Server Development Group encore!xylogics!loverso [formerly of Encore Computer Corp]