Xref: utzoo comp.dcom.modems:1646 comp.sys.att:2897 Path: utzoo!mnetor!uunet!husc6!ukma!david From: david@ms.uky.edu (David Herron -- Resident E-mail Hack) Newsgroups: comp.dcom.modems,comp.sys.att Subject: Re: Reports on Trailblazer modems (especially with 3B2 and IBM PCs) Message-ID: <8740@e.ms.uky.edu> Date: 30 Mar 88 23:06:46 GMT References: <179@beattres.UUCP> Reply-To: david@ms.uky.edu (David Herron -- Resident E-mail Hack) Organization: U of Kentucky, Mathematical Sciences Lines: 150 Keywords: Trailblazer, info, line noise I don't think I ever posted this. It's a longish journal of the testing I did with a couple of trailblazers which I'd had in for testing ... (Various university and political delays have kept us from getting our order out until a couple of weeks ago, sigh) Mon Nov 23 19:46:12 EST 1987 I've been using it for only a few hours (i.e. <10) ... there is some delay for echo, but not "several seconds". More like a half second normally and sometimes not noticeable. Repainting the screen does take one or two or three bursts. But it happens smoothly and quickly. For reference ... the terminal is an Ampex 210 running at 19.2 kbaud. The computer is a uVaxII running through DEC DHU-11's. The machine has 13 megs of memory and we're running MtXinu 4.3+NFS on it. The drives are the 70 meg qd5? drives that DEC likes to sell on a uVaxII. The modem generally claims 15kbaud effective xmit/rcv rates on the phone lines. My roomate feels that the phone service in our area of town is very bad ... we're in the student ghetto and it's not hard to imagine that they'd put less emphasis to that area, plus it's an "historic" neighborhood, with a few buildings that date back to the Civil War days... The point is, it runs well in the slightly adverse conditions to which I've subjected it. I have some more tests in mind, like leaving the extension off the hook and see what happens to the baud rate. etc etc. I'll probably post a fuller report in a couple of weeks. One bad note so far. This morning I transferred some files between my Unix PC and the uVaxII and got some really bad transfer rates. Down around 2kbaud whereas I was getting around 10kbaud transferring files with the uunet machine. I dunno what was wrong there. Possibly just a buggy uucp on my 3b1 or the fact that it can only do 9600 baud out its' serial ports. ---------------------------------------------------------- Wed Nov 25 10:19:44 EST 1987 More testing ... First, last night I was paying attention to delays and such and began to notice that sort of behaviour. But it's not much of an annoyance, possibly after I became accustomed to it ... for instance, right now I'm using vi to edit this file. I'm having 1/2 to 1 1/2 second delays on echo. Normally vi has some delay but not this bad. A minute ago I was positioning the cursor to edit a word, and overshot badly. Probably I have attuned myself to the normal delay, and am unused to the delay that's active now and am missing things as a result. Last night I was experiencing the same thing with editting command lines. (If I remember correctly, the command lines were over on the PR1ME so therefore I use ^H and it doesn't erase as I go ...) Another result. I realized that the modem on this end wasn't going into the UUCP protocol when using uucp to call ukma. That could easily account for the 2kbaud throughput. Rewriting the L.sys entry to enable the uucp mode caused the effective rate to go up to 8300 baud. Not bad considering that it's a Unix PC and can only run its' serial lines at 9600 baud... And finally, a *real*test*. I connected up and ran "rain". (BTW, rain is real fun to watch at ~15kbaud from home! :-)). Anyway, picking up the extension line didn't seem to phase the modem. i.e. rain kept on running w/o problems. So I whistled. Still no pause. Whistling more did cause some problems. Oh, by the way, I also have Alan Parson's _Stereotomy_ playing on the speakers in here. It wouldn't hang up though. This is treatment which would have caused any other modem I've ever seen to freak out and hang up. I pulled out my Casio SK-1 (a toy keyboard which does some limited synthesis and limited sound sampling). A little bit of playing in the piano mode would cause small canniptions in the modem. But it would recover and keep on going eventually. Finally, a LOT of playing did make it freak out and hang up. I don't know if this was absolutely necessary, but when I called back the modem wouldn't work right. So I called up on a different line and killed the getty then called back to the telebit, and it worked fine. Possibly when I called the first time my processes hadn't gotten their hangup and so forth and the modem wasn't all the way reset. Possibly not. Some usage notes. I have the modems on both ends configured to work at a fixed baud rate. If I want to call some 1200 baud place, I have to say "ats50=2" to the modem (i.e. when you call up, answer to the 1200 baud tones). This causes the trailblazer to sync at 1200 baud and continue talking to the serial port at 19200. It handles all the buffering internally. I haven't looked inside to see how much memory it has, and haven't given it a situation where it would possibly run out of buffer. (i.e. I haven't called up the vax at 1200 baud on that trailblazer ... since it's at 19200 ...) The trailblazer on the Vax is set with ats50=0 so that when you call up it will cycle through all the tones. (ats92 and ats90 are both important here also). When I place calls to uunet I have to tell it "ats50=255" so that when the uunet modem answers, they'll sync with the PEP tones. I also have it configured with ats52=2 so that the values of the s register's'll reset themselves after a call, allowing me to muck with values for a UUCP call, but then have it revert to the proper mode for dialup use afterward. The point of the last couple paragraphs is that there are a lot of conveniences in this modem. For instance ... a real big convenience for this playing with it to configure it has been the fact that, while connected and at this modem's command mode, I can have the other modem perform commands with "at%command". NOTE that with some commands you put the remote modem into it's command level and you have to put it BACK into it's online mode before connecting back ... i.e. "at%o" before "ato". And the reference card! That's been a lifesaver in that, now after using this modem since last friday, all I need is a prodding of the memory for which register to set. The real manual was very helpful and good to read, but now I don't need it so badly, and I was about to say I couldn't find it even, but it was under the reference card. There has been one confusing thing so far. That is, how to set flow control. I don't even know if the boards on the uVax can support proper flow control or not. I know that this terminal can possibly support the right kind of flow control, but why bother ... it can also keep up at real 19200 baud. But flow control would be important for later if I wanted to support 1200/2400 baud in and out of the modem. Something which occurs to me but I haven't checked up on. The hardware and firmware in this guy must be very well integrated. I say this because there isn't a second set of chips inside to run the 300/1200/2400 speeds. This isn't very surprising because to be able to control the phone line as they do they'd have to have put in some very exacting amounts of control. (re-write that sentence later). The important thought about this is that, with this exacting control, they could possibly put different firmware into the modem and suddenly be able to do some other protocol in addition to the current ones. For instance, if they aren't able to establish a strong market niche by offering such a neat fancy modem, not very many people will have these modems. Their customers will be stuck holding onto a very expensive paper-wieght. But possibly by just swapping out ROM's their customers will be able to talk whatever protocol becomes the standard for 9600 baud, but also be able to continue talking the old protocols. I would like to know how much CPU bandwidth is left. That 68010 in there must be one busy sucker, he's keeping track of about 100 channels of information flow, retuning each one all the time, doing error correction on each channel, and so forth. He must be real busy... but HOW busy? I would also like to know how much ROM is being used against what can be used. -- <---- David Herron -- The E-Mail guy <---- or: {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET <---- <---- I don't have a Blue bone in my body!