richard@pegasus.com (Richard Foulk) (06/15/91)
Does anyone have a getty working with ISC Unix and Telebit modems that will change the line baud rate according to the `CONNECT xxxx' message from the modem? I'm hoping to get something like this working on ports that are used bi-directionally via the kernel/driver based locking scheme, not the uugetty approach. Is this even possible? (I don't want to lock the port speed on the Telebits because that breaks some nice features on programs like vi, etc., that adapt their display to the speed of the connection.) Thanks -- Richard Foulk richard@pegasus.com
karln@uunet.uu.net (06/15/91)
In article <1991Jun15.030807.28565@pegasus.com> richard@pegasus.com (Richard Foulk) writes: >Does anyone have a getty working with ISC Unix and Telebit modems >that will change the line baud rate according to the `CONNECT xxxx' >message from the modem? > >I'm hoping to get something like this working on ports that are >used bi-directionally via the kernel/driver based locking scheme, >not the uugetty approach. Is this even possible? > >(I don't want to lock the port speed on the Telebits because that >breaks some nice features on programs like vi, etc., that adapt >their display to the speed of the connection.) > Despite the last comment, I HIGHLY reccomend locking the speed of the modem. I know someone that tried for a week or two trying to get the T2500 to work like the manual shows, but never really got it off the ground. Furthermore I cannot picture were getty is going to get the connect string from, but then again I've always gone the locked speed route. The connect string always seemed to be more for using cu or some such dialout. I'm not even sure that the modem will issue a connect string when someone calls in. There should be a way to query it though. I'll look into it a bit more this weekend, but I have to say .. I would just lock the port. I've seen 9600 baud modems for $179 US. At that, every one should have one .. (excepting of course students :-) -- *********************************************************************** | Karl Nicholas | A million monkeys in a million years | | karln!karln@uunet.uu.net | did write Shakespear, we evolved ... | ***********************************************************************
marc@dumbcat.sf.ca.us (Marco S Hyman) (06/16/91)
In article <1991Jun15.030807.28565@pegasus.com> richard@pegasus.com (Richard Foulk) writes: > Does anyone have a getty working with ISC Unix and Telebit modems > that will change the line baud rate according to the `CONNECT xxxx' > message from the modem? Don't bother. Set up the T2500 to use flow control and then lock the interface at a set speed, perferably 19200. Grab FAS (current version is 2.08) and use it instead of the default ASY driver. Then program the T2500 to use RTS/STS flow control (S58=1) and lock the interface speed (S51=5, S66=1). You can select outgoing dial speeds in your Systems file by doing something like: host Any ACU 19200 ... host96 Any ACU9600 19200 ... host24 Any ACU2400 19200 ... The interface speed will be locked at 19200 but the connect speed is set by the ACUnnn number. The entries in Devices look like: Direct ttyf0 - Any direct \D ACU ttyf0 - 19200 telebit \T ACU9600 ttyf0 - 19200 telebit9600 \T ACU2400 ttyf0 - 19200 telebit2400 \T ACU1200 ttyf0 - 19200 telebit1200 \T The Dialers entris that support these rates will be something like: # The direct entry supports direct access to the modem. It is used by the # Direct devices entry. direct =,-, "" \M\pAT\r\c OK\r ATQ0V1\r\c OK\r \c telebit =,-, "" \M\pAT\r\c OK\r ATQ0V1S50=255\r\c OK\r ATDT\T\r\m\c CONNECT # The following dialers are used to force an outgoing connection at a # certain rate while still keeping the interface speed locked at another # rate. This has been testing with a telebit T2500 telebit9600 =,-, "" \M\pAT\r\c OK\r ATQ0V1S50=6\r\c OK\r ATDT\T\r\m\c CONNECT telebit2400 =,-, "" \M\pAT\r\c OK\r ATQ0V1S50=3\r\c OK\r ATDT\T\r\m\c CONNECT telebit1200 =,-, "" \M\pAT\r\c OK\r ATQ0V1S50=2\r\c OK\r ATDT\T\r\m\c CONNECT Good luck. // marc -- // home: marc@dumbcat.sf.ca.us pacbell!dumbcat!marc // work: marc@ascend.com uunet!aria!marc
davidg%aegis.or.jp@kyoto-u.ac.jp (Dave McLane) (06/16/91)
karln@uunet.uu.net writes: > In article <1991Jun15.030807.28565@pegasus.com> richard@pegasus.com (Richard > >Does anyone have a getty working with ISC Unix and Telebit modems > >that will change the line baud rate according to the `CONNECT xxxx' > >message from the modem? > > > >I'm hoping to get something like this working on ports that are > >used bi-directionally via the kernel/driver based locking scheme, > >not the uugetty approach. Is this even possible? > > > >(I don't want to lock the port speed on the Telebits because that > >breaks some nice features on programs like vi, etc., that adapt > >their display to the speed of the connection.) > > > Despite the last comment, I HIGHLY reccomend locking > the speed of the modem. I know someone that tried for a week > or two trying to get the T2500 to work like the manual shows, > but never really got it off the ground. Furthermore I cannot > picture were getty is going to get the connect string from, > but then again I've always gone the locked speed route. The I have Paul Sutcliff's getty 2.0 running Telebit 2500/1600s and it works well for changing the baud rate on dialin but not for dialout. First off, getty 2.0 allows you to send an init string to the modem which isn't really needed for Telebits as they are very configureable but allows you to run older/cheaper modems (that you may already have) which don't. Second, if you configure the modem as it would be for a BBS it returns a CONNECT (speed)/(link)/(compression) which shows just about everything you need to set the speed. I modified the orignal getty 2.0 to only lock the speed on a CONNECT with error checking but otherwise let it run free as locking the speed with non-error checking connects really screws up their ability to stop/start scrolling without hideous amounts of overrun (with all modems, but particularly with those like the Telebit which have huge buffers). However, if you think about it (and I didn't, but found out after I had the thing running), there isn't any convenient way of hanging getty 2.0 on the line and have it (perhaps init the modem and then) wait for a CONNECT string and let cu or something else sneak in their and dialout. Maybe I'm missing something here because getty 2.0 can look for a lock on the port and won't try and init the modem if it's already in use, but if getty 2.0 has the port and is waiting for the CONNECT and you go and run cu or something that dials out, getty starts interpreting things to the confusion of all. Perhaps there is a way around this but I have 4 lines and decided to hang a regular uugetty on one and share it with a fax (the line also has a switch on it that let's incoming calls select either the fax or the modem) and run getty 2.0 on the rest. So I have UUCP, locked-uugetty line and 3 running getty 2.0 which interpret the CONNECT string. A further feature of is that there is no need for users to hit RETURN so magic number of times; getty 2.0 picks up the CONNECT string and will generate a configureable signon banner. Mine is Aegis - 06/16/91 06:19:16 - ttyF04 9600 BPS - 4 user(s) online login: Hope that helps, Dave -- Dave McLane <davidg%aegis.or.jp> JUNET <davidg%aegis.or.kyoto-u.ac.jp> INTERNET <davidg%aegis.or.jp@jpnkyoto.kyoto-u.ac.jp> BITNET <davidg%aegis.or.jp%kyoto-u.ac.jp@uunet.uu.net> UUNET ==== The Aegis Society ============================================= Minami Hirao 1-6, Imazato The content and process of Nagaokakyo-shi, Kyoto-fu, 617 Japan international/cultural Tel: +81-75-951-1168 Fax: +81-75-957-1087 communication. ====================================================================
john@jwt.UUCP (John Temples) (06/16/91)
In article <1991Jun15.154304.25987@uunet.uu.net> karln!karln@uunet.uu.net (Karl Nicholas) writes: >I HIGHLY reccomend locking >the speed of the modem. I know someone that tried for a week >or two trying to get the T2500 to work like the manual shows, >but never really got it off the ground. I had my TB+ running unlocked for many months without any problems. I had it set up that way because some older slow modems (Everex 2400 bps) would drop characters when receiving from the TB. UUCP and interactive use were both impossible with the interface speed locked. Does anyone know what causes this? >Furthermore I cannot >picture were getty is going to get the connect string from, I mentioned the same thing to Richard in mail. I've played with one of those so-called auto-bauding gettys. The problem was that the modem issued the CONNECT message before asserting DCD, so the getty never saw it, since it was blocked in open() waiting for DCD. I guess these gettys can only be used if you use a non-blocking open() device on the serial port? But then you can't use the device for dialout. Would it be possible for FAS to optionally save incoming characters when no device has the port open, and hand them to the next process to open the device? -- John W. Temples -- john@jwt.UUCP (uunet!jwt!john)
karln@uunet.uu.net (06/17/91)
In article <qaJN42w164w@aegis.or.jp> davidg%aegis.or.jp@kyoto-u.ac.jp (Dave McLane) writes: >about everything you need to set the speed. I modified the orignal >getty 2.0 to only lock the speed on a CONNECT with error checking >but otherwise let it run free as locking the speed with non-error >checking connects really screws up their ability to stop/start >scrolling without hideous amounts of overrun (with all modems, but >particularly with those like the Telebit which have huge buffers). That point about over-run has only been a problem, in my experience, when the serial driver/modem is NOT using CTS/RTS hardware flow control. For this I was told to get FAS 2.08 as the stock ISC asy drivers did not handle it. > >their and dialout. Maybe I'm missing something here because getty >2.0 can look for a lock on the port and won't try and init the >modem if it's already in use, but if getty 2.0 has the port and is >waiting for the CONNECT and you go and run cu or something that >dials out, getty starts interpreting things to the confusion of all. In ISC and or FAS, I thought the trick about that one was that there are two different /dev/tty?? devices to use. In ISC there are even three if I remeber right. 1: tty00 for terminals ? 2: ttyd0 for getty waiting for dialin .. 3: acu00 for cu looking to dialout while getty has ttyd0. in FAS ... ummm .. 1: ttyf0 for dialin 2: ttym0 for dailout (Probably wrong, but its something) So have you tried that? I've seen it work real nice. I think it is an easy point to miss if you are used to the uugetty fashion. > >locked-uugetty line and 3 running getty 2.0 which interpret the >CONNECT string. A further feature of is that there is no need for >users to hit RETURN so magic number of times; getty 2.0 picks up >the CONNECT string and will generate a configureable signon banner. I'm a gonna havta look into this getty 2.0 thing. -- *********************************************************************** | Karl Nicholas | A million monkeys in a million years | | karln!karln@uunet.uu.net | did write Shakespear, we evolved ... | ***********************************************************************
steve@nuchat.sccsi.com (Steve Nuchia) (06/18/91)
In article <1991Jun16.021808.1704@jwt.UUCP> john@jwt.UUCP (John Temples) writes: >had it set up that way because some older slow modems (Everex 2400 bps) >would drop characters when receiving from the TB. UUCP and interactive >use were both impossible with the interface speed locked. Does anyone >know what causes this? As explained to me by Telebit tech support: There is a provision in the relevant standards that says, essentially, that the modem-to-modem data stream is allowed to skip a stop bit time slot every eight characters if the host-to-modem link is faster than the modem-to-modem link. Apparently telebit decided to take advantage of this. Unfortunately, if the *other* modem-to-host link is not faster than the modem-to-modem link, and the stream is continuous, there is no time to catch up and the buffers (if any!) overflow. The 3b1 internal 1200 bps modem was where I first encountered this particular problem. There have been others. I worked around the problem by setting up dialer scripts that set the host-to-modem interface to match the desired transmission speed. I use those entries only for connections that require them. Uucp neighbors that have this problem are outdial-only, since I leave speed locked for indial (and most outdial). -- Steve Nuchia South Coast Computing Services (713) 964-2462 "Innocence is a splendid thing, only it has the misfortune not to keep very well and to be easily misled." --- Immanuel Kant, Groundwork of the Metaphysic of Morals
davidg%aegis.or.jp@kyoto-u.ac.jp (Dave McLane) (06/18/91)
karln@uunet.uu.net writes: > In article davidg%aegis.or.jp@kyoto-u.ac.jp (Dave McLane) writes: > > >about everything you need to set the speed. I modified the orignal > >getty 2.0 to only lock the speed on a CONNECT with error checking > >but otherwise let it run free as locking the speed with non-error > >checking connects really screws up their ability to stop/start > >scrolling without hideous amounts of overrun (with all modems, but > >particularly with those like the Telebit which have huge buffers). > > That point about over-run has only been a problem, in my experience, > when the serial driver/modem is NOT using CTS/RTS hardware flow > control. For this I was told to get FAS 2.08 as the stock ISC > asy drivers did not handle it. Ummm, I think you're thinking about another kind of overrun. What I'm talkng about is when somebody connects at, say, 2400 BPS non-MNP (which means there is no CTS/RTS involved between their machine to their modem to my modem) and asks for some long article to be sent without any paging. If the Telebit on my system is locked at, say, 19,200, it throws stuff at the Telebit at that speed while the Telebit is sending it out over the line at only 2400 BPS. Since the Telebit has a buffer of something like 10K the buffer fills up as the speed between my machine is so much faster than the speed between the Telebit and the other modem-machine. So then the person on the other end sends ^S to stop the flow and my system stops sending to the Telebit ... but the flow doesn't stop at the other end until the buffer in the Telebit empties. People with MNP also get this but have been willing to live with it as they get a much higher speed; people without MNP moaned and complained so much that I changed the logic of the way my system handles connects so that it only locks the port on MNP/LAPM/etc. error correction. Thus under non-error correction there is no overrun when they send ^S as there is nothing in the buffer. > >their and dialout. Maybe I'm missing something here because getty > >2.0 can look for a lock on the port and won't try and init the > >modem if it's already in use, but if getty 2.0 has the port and is > >waiting for the CONNECT and you go and run cu or something that > >dials out, getty starts interpreting things to the confusion of all. > > In ISC and or FAS, I thought the trick about that one was that > there are two different /dev/tty?? devices to use. In ISC > there are even three if I remeber right. Yes, this is so, but it doesn't take into consideration what happens when you start sending init strings to the modem (as the normal getty/uugetty pretends that the modem is just a terminal whose CD signal goes on and off). Once getty 2.0 has sent the init string sent and is waiting for a CONNECT string of some kind, things go very strangely if another process jumps in there and sends yet another init/dialout string! I would imagine there might be some way to kill off the first getty 2.0 that's sitting there waiting for a call/CONNECT so a second one could re-init/dial out but I didn't try it. > >locked-uugetty line and 3 running getty 2.0 which interpret the > >CONNECT string. A further feature of is that there is no need for > >users to hit RETURN so magic number of times; getty 2.0 picks up > >the CONNECT string and will generate a configureable signon banner. > > I'm a gonna havta look into this getty 2.0 thing. I found this is a big improvement over "hit RETURN the number of times between the highest speed on the modem that you happen to hit on the rotary and the speed at which you want to connect", which is what users have to do with the regular getty/gettydefs. Sheesh! I thought computer were supposed to do the work... Dave -- Dave McLane <davidg%aegis.or.jp@kyoto-u.ac.jp>
karln@uunet.uu.net (06/19/91)
In article <aJJs41w164w@aegis.or.jp> davidg%aegis.or.jp@kyoto-u.ac.jp (Dave McLane) writes: >> > >What I'm talkng about is when somebody connects at, say, 2400 BPS >non-MNP (which means there is no CTS/RTS involved between their > [...] >complained so much that I changed the logic of the way my system >handles connects so that it only locks the port on MNP/LAPM/etc. Oh, well. I can see I'm gonna hafta get some real ISC experience before I'ma gonna be of any real help here. TTYL :-) >sends yet another init/dialout string! I would imagine there might >be some way to kill off the first getty 2.0 that's sitting there >waiting for a call/CONNECT so a second one could re-init/dial out >but I didn't try it. See above. > >> >> I'm a gonna havta look into this getty 2.0 thing. > >I found this is a big improvement over "hit RETURN the number of >times between the highest speed on the modem that you happen to >hit on the rotary and the speed at which you want to connect", >which is what users have to do with the regular getty/gettydefs. > >Sheesh! I thought computer were supposed to do the work... > Close: It is supposed that computers are a lot of work ... -- *********************************************************************** | Karl Nicholas | A million monkeys in a million years | | karln!karln@uunet.uu.net | did write Shakespear, we evolved ... | ***********************************************************************
rhealey@digir4.digibd.com (Rob Healey) (06/20/91)
In article <1991Jun15.154304.25987@uunet.uu.net> karln!karln@uunet.uu.net (Karl Nicholas) writes: >I've seen 9600 baud modems for $179 US. At that, every one >should have one .. (excepting of course students :-) > Just a point of clearification: Those $179.00 modems are REALLY 2400 baud modems with V.42bis which can, if the wind is blowing in the right direction and you have a file of 0's, get you 9600 baud THROUGHPUT but not 9600 baud. The lowest price V.32 modem I've seen is about $480.00. Personally, I think tose companys who advertise this should be hauled in for false advertising. -Rob -- Rob Healey rhealey@digibd.com Digi International (DigiBoard) Eden Prairie, MN (612) 943-9020
davidg%aegis.or.jp@kyoto-u.ac.jp (Dave McLane) (06/20/91)
karln@uunet.uu.net writes: > >Sheesh! I thought computer were supposed to do the work... > > > Close: > It is supposed that computers are a lot of work ... Ahh! Right! Thinking that computers are supposed to do the work is pure supposition :-) Dave -- Dave McLane <davidg%aegis.or.jp@kyoto-u.ac.jp>
wtm@uhura.neoucom.EDU (Bill Mayhew) (06/20/91)
<< whether or not to lock the interface speed of Telebit modem >> Locking the interface speed is pretty handy. I typically run my port getty at 19200 and let the modem, in my case a Trailblazer +, handle the speed translation. There are some things you have to watch out for. Namely with speed translation going on in the modem, there is inevitable need for flow control. In normal dial-up the default xon/xoff flow control works quite well. However, the flow control will zap uucp connections by adding extra characters to the data stream. At 1200 and 2400 bps, the modem will insert flow control often enough that the window of 3 packets is sure to get zapped with the result being a deadlock of infinite retries. The easy way to get around the flow control problem is for your site to dail out to outher sites with the modem set at a speed appropriate to the connection type. You could still get flow problems if you are running the interface at 4800 bps with the assumption of getting an MNP-4 2400 bps connection. In such cases, I disable MNP compression (limit to level 3). The Trailblzer, and most v.32 modems, have the ability to use the RTS/CTS leads for flow control. This has the advantage of keeping the flow out of the character data stream. Also advantageous is the fact that the flow control latency is reduced because the flow message is not queued in input buffers, etc; it can go straight to the driver. I believe the stock ISC/ATT asy port driver does not have RTS/CTS flow capabilities; I don't recall off hand, but the fas port driver available at your friendly ftp connection may have it. Auto bauding getty certainly is possible, though I have not seen it available for for ISC. I am using a TB+ on our HP-9000 with HP's uugetty. Their uugetty looks for carriage returns initially to set the speed. It usually one takes one return to recognize 9600 or 19200 but may take up to 5 to recognize 1200 bps. Obviously, here I let the modem match the speed of the connection; no problems with flow control. No need to read the CONNECT message from the modem, vi even gets the right window size. In this case, I use Q3 for the verbosity setting (no messages, ever). I've tried the Q6 and have occasionally had troubles with the modem getting confused about what modality it is in, resulting getting getty babble. I use the fist entry in the dialer chat script to switch back to Q0 to allow progress monitoring. There is one last thing. I've heard some complaints about people that use TB modems with locked interface speeds of a phenomenon called bit-shaving. Apparently TB modems might have slight speed mismatches when doing speed translation. From my understanding, newer modems aren't bothered, but older modems have problems staying in sync. I've also been told that the newer firmware for TB modems mitigates the bit-shaving problem. Hope this is of some help, Bill -- Bill Mayhew NEOUCOM Computer Services Department Rootstown, OH 44272-9995 USA phone: 216-325-2511 wtm@uhura.neoucom.edu ....!uunet!aablue!neoucom!wtm via internet: (140.220.001.001)
karln@uunet.uu.net (06/20/91)
In article <1991Jun19.213521.21982@digibd.com> rhealey@digir4.digibd.com (Rob Healey) writes: >In article <1991Jun15.154304.25987@uunet.uu.net> karln!karln@uunet.uu.net (Karl Nicholas) writes: >>I've seen 9600 baud modems for $179 US. At that, every one >>should have one .. (excepting of course students :-) >> > Just a point of clearification: > > Those $179.00 modems are REALLY 2400 baud modems with V.42bis > which can, if the wind is blowing in the right direction and > you have a file of 0's, get you 9600 baud THROUGHPUT but not > 9600 baud. Oh, well, make a sucker outta me ... > > The lowest price V.32 modem I've seen is about $480.00. > > Personally, I think tose companys who advertise this should > be hauled in for false advertising. Not to mention charging too high a price -- *********************************************************************** | Karl Nicholas | A million monkeys in a million years | | karln!karln@uunet.uu.net | did write Shakespear, we evolved ... | ***********************************************************************
mcr@Sandelman.OCUnix.on.ca (Michael Richardson) (06/21/91)
In article <aJJs41w164w@aegis.or.jp> davidg%aegis.or.jp@kyoto-u.ac.jp (Dave McLane) writes: >> That point about over-run has only been a problem, in my experience, >> when the serial driver/modem is NOT using CTS/RTS hardware flow >> control. For this I was told to get FAS 2.08 as the stock ISC >> asy drivers did not handle it. >Ummm, I think you're thinking about another kind of overrun. > >What I'm talkng about is when somebody connects at, say, 2400 BPS >non-MNP (which means there is no CTS/RTS involved between their >machine to their modem to my modem) and asks for some long article >to be sent without any paging. If the Telebit on my system is ^^^^^^^^^^^^^^^^^^ Hmm. This is a problem in my opinion. Users should be taught to use more or pg. What really annoys me is when I type: % l /etc | more l expands to '/bin/ls -lg !* | more', and the first more sometimes manages to not turn itself into cat when stdout isn't a terminal... >People with MNP also get this but have been willing to live with it >as they get a much higher speed; people without MNP moaned and >complained so much that I changed the logic of the way my system >handles connects so that it only locks the port on MNP/LAPM/etc. >error correction. Thus under non-error correction there is no >overrun when they send ^S as there is nothing in the buffer. I've given some thought as to how to pick up the CONNECT messages. I may eventually do some hacking on fas, but since I still haven't convinced my boss that fas is usefull :-) (various comments about sticking with the vendor's stuff, so we know it works and can solve clients problems...) What I'd like to do is to write a getty that does just one extra ioctl. What I understand about streams, however tells me that this won't work. (Are ttys streams under ISC? I can't remember right now. I think not.) Have getty open(file,O_NDELAY), and then ioctl(fd,I_PUSH,"Telebit"). The "Telebit" streams module knows how to do things with Telebits on the other end of the line. (you could probably get away with a generic 'Hayes' module, I don't know yet) The trick is to convince the underlying driver to return characters to this streams module even when DCD is down, AS LONG AS /dev/acuBLAH isn't open. The streams module hangs around, and waits for 'RING' and sends a friendly 'ATA' back. No more answering the phone when the computer has locked up without dropping DTR. Among important things that this module would do would be to parse the CONNECT xxxx message and remember that number. The interface speed wouldn't actually change (unless, I guess, you really wanted it to in order to support ^S). However, any ioctl(...TCGETS...) calls would have their speed entry patch to reflect the actual connect speed. vi and friends can do their low speed optimizations. Even better, would be to have this nice little module do dial out too. If it receives RING while setting up the modem, it returns "BUSY" and gives the getty a kick. This would require modifying uucico and cu though, and would make the module much bigger. I can't think of a good way to implement this kind of stuff in user mode, and still support the dial in and dial out ports. I saw most of this stuff in Fidonet mailers, and implemented parts of it for Welmat (an Amiga mailer). >whose CD signal goes on and off). Once getty 2.0 has sent the init >string sent and is waiting for a CONNECT string of some kind, >things go very strangely if another process jumps in there and >sends yet another init/dialout string! I would imagine there might >be some way to kill off the first getty 2.0 that's sitting there >waiting for a call/CONNECT so a second one could re-init/dial out >but I didn't try it. The /dev/tty0d and /dev/acu0 are the best thing since sliced bread. I have tried repeatedly on many different OSs and many different machines to get uugetty to do its stuff, and I have always failed, or I've never been satified with how it is doing its thing. >> I'm a gonna havta look into this getty 2.0 thing. > >I found this is a big improvement over "hit RETURN the number of >times between the highest speed on the modem that you happen to >hit on the rotary and the speed at which you want to connect", Which is why I like locked interface speeds. Concerning ^S/^Q --- can the Telebit be configured to respond to them from the remote system? Hmm. I want an emacs info document on my Telebit inaddition of that inch thick book. -- :!mcr!: | The postmaster never | So much mail, Michael Richardson | resolves twice. | so little time. HOME: mcr@sandelman.ocunix.on.ca Bell: (613) 237-5629 Small Ottawa nodes contact me about joining ocunix.on.ca!
wtm@uhura.neoucom.EDU (Bill Mayhew) (06/21/91)
A rather inexpensive, if not the least expensive, v.32 modem of credible qualtiy is made by GVC. I purchased mine in single quanity for $405. Price for ten or more is $395. GVC is based on the ubiquitous Rockwell v.32 chipset engine and includes MNP level and v.42 / v.42bis lap-m error correction and compression provided by a Z-80 running Softart's MNP/v.42 firmware. The command processor is an 8031 with 32K of its own firmware. The maximum interface speed is 38400, so you can get full benefit of v.42bis on a clean link. The manual is relatively well written, but the v.42 commands are covered in a supplement that could be misplaced. Fortunately, AT&H is an on-line manual that lists all of the many commands. There is EEPROM (not battery backed CMOS!) that can store two configurations; the contents may be viewed with AT&V. GVC was rated #2 in the PC Week v.32 modem poll just behind Digicomm. I don't currently have a line impairment test set, but subjectively GVC performs on par with Digicomm and Hayes for noise rejection and sensitivity. I have a trunk circuit that I can dial up that has a sync slip problem that renders non MNP 1200 baud and 2400 modems unusable. I was able to hold a connection between the GVC and Digicomm on that line at 9600 with the test light on the GVC blinking regularly (confirming the sync slip) showing the error correction. Thoughput was better than 800 char / sec. I work in a computer support center and have a chance to tear apart the GVC modem and scrutiize it. It is very well made from decent materials. I do not recommend the internal GVC 9600 (for IBM ISA bus) for Unix users becuase the UART is only an 80C450. This means that you can't take advantage of interrupt overhead reduction by employing the fas 2.08 driver and Nat. Semi. 16550 Uart chip. The 80C450 on the GVC internal modem is a surface mount 40 pin chip which makes its replacement with 16550 rather impractical. To stay non-commercial, anybody that wants to know the vendor should contact me via email. I have no connection with GVC other than as a user (who is now $405 less rich than before!) PS: speaking of Digicomm, they now have a new firmware release that supports v.42 lap-m, but not v.42bis. The upgrade is free from Digicomm technical support (ask for Dave). Bill -- Bill Mayhew NEOUCOM Computer Services Department Rootstown, OH 44272-9995 USA phone: 216-325-2511 wtm@uhura.neoucom.edu ....!uunet!aablue!neoucom!wtm via internet: (140.220.001.001)
davidg%aegis.or.jp@kyoto-u.ac.jp (Dave McLane) (06/21/91)
mcr@Sandelman.OCUnix.on.ca (Michael Richardson) writes: > Hmm. This is a problem in my opinion. Users should be taught to use > more or pg. What really annoys me is when I type: > % l /etc | more Perhaps you aren't aware of how what telco charges are in Japan. Aegis is in Kyoto where local dial (standard all over Japan) is only 3.3 yen/min (US$0.24/min) but many people call in from other nearby places like Osaka and Kobe where it starts running something like 50 yen/min (US$.35). Not many people read online after the first month and the phone bill comes in.... Dave -- Dave McLane <davidg%aegis.or.jp@kyoto-u.ac.jp>
cmf851@anu.oz.au (Albert Langer) (06/22/91)
In article <1991Jun20.171902.23267@Sandelman.OCUnix.on.ca> mcr@Sandelman.OCUnix.on.ca (Michael Richardson) writes: >The "Telebit" streams module knows how to do things with Telebits on >the other end of the line. (you could probably get away with a generic >'Hayes' module, I don't know yet) Go for it. I'm not sure whether it should be viewed as a streams module or as a sort of Media Access component of the data link layer but it's about time everything to do with handling modems was put in once place (with configuration files for the particular hardware etc) so that higher layers of software just tell it what phone number they want to connect to or accept a connection from it. -- Opinions disclaimed (Authoritative answer from opinion server) Header reply address wrong. Use cmf851@csc2.anu.edu.au
root@zswamp.uucp (Geoffrey Welsh) (06/22/91)
In a letter to All, Rob Healey (rhealey@digir4.digibd.com ) wrote: >In article <1991Jun15.154304.25987@uunet.uu.net> >karln!karln@uunet.uu.net (Karl Nicholas) writes: >I've seen 9600 baud modems for $179 US. At that, every one >should have one .. (excepting of course students :-) > > Just a point of clearification: > Those $179.00 modems are REALLY 2400 baud modems > with V.42bis which can, if the wind is blowing in > the right direction and you have a file of 0's, > get you 9600 baud THROUGHPUT but not 9600 baud. ... unless you're talking about the CompuCom SpeedModem, which really is a 9600 bps modem... which isn't 9600 bps compatible with anything but other CompuCom SpeedModems. Fortunately (for those who bought one), there is a growing pool of support for these things. > Personally, I think tose companys who advertise this > should be hauled in for false advertising. You mean those who advertise 2400 bps modems with data compression as "9600 bps" modems; I agree. Most, however, advertise "throughput UP TO 9600 bps" (emphasis mine), which is legally acceptable. -- Geoffrey Welsh - Operator, Izot's Swamp BBS (FidoNet 1:221/171) root@zswamp.uucp or ..uunet!watmath!xenitec!zswamp!root 602-66 Mooregate Crescent, Kitchener, ON, N2M 5E6 Canada (519)741-9553 "He who claims to know everything can't possibly know much" -me