conrad@popvax.harvard.edu (04/20/91)
Hello there:
Ok, it sounds like the new V.32bis modems are pretty slick. I figured it
was time to upgrade and set about collecting information from vendors and manu-
facturers yesterday. Unfortunately I still have some questions. I know that I
can trust this newsgroup for some real answers....
I currently have a USR Courier V.32 and a Telebit T2500 (borrowed). I had
bought the V.32 last year when they first came out, on the promise of a free
upgrade to V.42 and V.42bis when it became available. I finally received the
chips and did the upgrade earlier this fall, many months after I had expected
to. The V.32 upgrade for the T2500 was so late in becoming available that I
received a free V.42 and V.42bis upgrade with it 8-( 8-) !
So finally the pair of modems is relatively happy. (Actually, I was never
able to set up my software with DTE rates of 38,400 bps on both ends. I heard
something about T2500s not supporting DTE rates of higher than 19,200 bps. (I
don't have the manual here -- I might even have read it there...?) Is this at
all true? It is also possibly a software problem....)
I called USR and Telebit to find out about upgrade possibilities. (I have
not had time to keep up with this group recently....) Telebit claims to have
no V.32bis products yet and didn't offer any timetables for modems or upgrades
in the works. USR of course has the new Courier V.32bis. It is a new modem
altogether and can't be created by upgrading a Courier V.32.
What sort of annoyed me was hearing that USR had had a trade-in program,
but that it had ended "last month". What?! I'm not that out of it am I? I
know I have been too preoccupied with a broken accounting system to keep up
with c.d.m, but I have been reading MacWEEK and other such things meanwhile.
And I did turn in my bloody registration card for the thing. And it's not as
though these V.32bis modems have been around for that long. When could I first
have received one? Maybe five weeks ago? Jeez!
So one question I have is about this trade-up program. Did it really ex-
ist? When and for how long and how did it work? I don't mind the rapid pace
of technology, and the tendency of things to become dated quickly, but I hate
screwing up and losing money. Before I drop $1,300 for a pair of these new
Courier V.32bis modems I want to know how to find out about upgrades and things
in an orderly and timely fashion. I don't have the time to read ALL the groups
I would need to watch ALL of the time. Has anyone EVER been notified about an
upgrade by virtue of their having sent in a registration card? I find I always
find out about such things on the net or in the trade rags and then have to be
a real pain in the ass to the manufacturers for a _long_ time. I only hear of
upgrades to things I DON'T own or care to own by mail.... Sigh.
Now the technical questions. First, I was a bit confused about something
I read in MacWEEK 03.19.91 V5N11 in an article about V.32bis modems on pages 45
and 46. There seems to be an implication that one CAN NOT use data compression
with the new 14,400 bps link rate. I haven't seen anything real to explain
this. Is it true? If so why? I HOPE that one can use V.42bis compression on
top of the V.32bis 14,400 bps link rate....
If I am right (and the article is either wrong or VERY poorly written),
what is the highest throughput that could be hoped for? 14,400 X 4 = 57,600.
I know that this would be difficult to sustain on real data, but is it a good
number for a top limit?
If these modems can theoretically reach throughputs of 57,600 bps, what
is the highest DTE rate that they support? I should think 57,600 bps would be
necessary. I ask because I was told two different things. The USR people said
that the highest DTE rate was 38,400 bps. The dealer I talked to told me that
they went "much higher" than 38,400 bps. What is the answer?
The dealer told me that USR ditched the Rockwell data pump for their own
design and that the new modem should be much more reliable. Does anyone have
any thoughts or inside knowledge on how this might affect future upgrades? I
am imagining a fax upgrade, I guess, as a possibility.... I know that chips
with fax capability are becoming more common, and that, among others, Rockwell
has them....
(Another dealer told me yesterday that by virtue of the MC68000 in the
T2500, a V.32bis upgrade would be just a matter of software. I am especially
skeptical of this as I had to pull and replace chips to make the thing talk
V.32 and V.42 and V.42bis.... The truth...?)
I am sorry about the length of this, and I hope that all of this hasn't
been beaten to death here recently. Is this group archived anywhere?
I will try to keep up with this group again for a while, but in case I
can't, could people be so kind as to send copies TO ME of any replies they post
TO THE NET if their news programs can do it easily? I will summarize anything
interesting that gets sent only to me....
I welcome any and all information, including sales pitches from vendors.
(Can anyone beat $649 for a USR Courier V.32bis on an educational discount...?)
On a similar note, does anyone want to make an offer on a USR Courier V.32
with V.42 and V.42bis? (10.0 MHz clock, 08/02/90 Supervisor -- revision 2.2,
05/17/89 IOP -- revision 1.0, and Rockwell R9696 data pump revision 204c.)
Thanks in advance....
+---- C o n r a d C . N o b i l i ----+
| |
| Harvard University | Internet: conrad@popvax.harvard.edu |
| Office for Info. Tech. | conrad@popvax.harvard.edu |
| Information Services | BITNET: CONRAD AT HARVARDA |
| Technical & User Services | CONRAD AT HARVSPHB |
| 1730 Cambridge Street | voice: (617) 495-8554 |
+---- Cambridge, MA 02138 | fax: (617) 495-0715 ----+conrad@popvax.uucp (M20400@c.nobili) (04/20/91)
Oops, I goofed up my addresses earlier.... THIS is correct.... +---- C o n r a d C . N o b i l i ----+ | | | Harvard University | Internet: conrad@harvarda.harvard.edu | | Office for Info. Tech. | conrad@popvax.harvard.edu | | Information Services | BITNET: CONRAD AT HARVARDA | | Technical & User Services | CONRAD AT HARVSPHB | | 1730 Cambridge Street | voice: (617) 495-8554 | +---- Cambridge, MA 02138 | fax: (617) 495-0715 ----+
gandrews@netcom.COM (Greg Andrews) (04/21/91)
In article <6465@husc6.harvard.edu> conrad@popvax.harvard.edu writes: > >The V.32 upgrade for the T2500 was so late in becoming available that I >received a free V.42 and V.42bis upgrade with it 8-( 8-) ! > No such thing as a "V.32 upgrade" for a T2500. Every single version of firmware for the T2500 has supported V.32. The very first version didn't support *synchronous* V.32 operation, but the numbers of modems used for asynchronous links far exceed the numbers used for synchronous links. I suspect you use async connections (revealed by your 19200/38400 bps questions in a later paragraph), so the T2500 had the V.32 support you needed all the time. > > So finally the pair of modems is relatively happy. (Actually, I was never >able to set up my software with DTE rates of 38,400 bps on both ends. I heard >something about T2500s not supporting DTE rates of higher than 19,200 bps. (I >don't have the manual here -- I might even have read it there...?) Is this at >all true? It is also possibly a software problem....) > The T2500 supports RS232 speeds up to 19200 bps. 38400 bps requires a faster processor than the T2500 has. > > Now the technical questions. First, I was a bit confused about something >I read in MacWEEK 03.19.91 V5N11 in an article about V.32bis modems on pages 45 >and 46. There seems to be an implication that one CAN NOT use data compression >with the new 14,400 bps link rate. I haven't seen anything real to explain >this. Is it true? If so why? I HOPE that one can use V.42bis compression on >top of the V.32bis 14,400 bps link rate.... > There's absolutely no reason a modem can't apply an error control protocol like MNP or V.42 to a V.32bis link. Given that, there's absolutely no reason a modem can't apply a data compression algorithm like MNP5 or V.42bis to the data. Provided the RS232 speed is faster than the modulation speed and the data can be compressed by the modem, then you can certainly get throughputs faster than 14400 bps from the V.32bis link. > >If I am right (and the article is either wrong or VERY poorly written), >what is the highest throughput that could be hoped for? 14,400 X 4 = 57,600. >I know that this would be difficult to sustain on real data, but is it a good >number for a top limit? > If these modems can theoretically reach throughputs of 57,600 bps, what >is the highest DTE rate that they support? I should think 57,600 bps would be >necessary. > Why should it be necessary if, as you say, you wouldn't be able to get that much compression out of real data? How many computers can handle a sustained data rate of more than 38400 bps? What kind of processor hardware would be necessary for the modem to handle a 14400 bps (full) duplex modulation AND compression/decompression of the data AND an RS232 interface speed of 57600? Would you really be willing to give up the amount of money and desk space for such a monster? Especially if you know in advance that you won't utilize the speed capabilities beyond 38400 bps more than perhaps 2% of the time? I think the reason most modem manufacturers are creating modems with a max RS232 speed of 38400 are doing it for three reasons: (a) It doesn't require exotic, costly processors, (b) Real life data transfers won't be more than 2.7:1 compressible 98% of the time, and (c) Few computers can handle data rates above 38400 bps. In short, they're designing a modem that will meet your data transfer needs without exceeding your budget needs. > >(Another dealer told me yesterday that by virtue of the 68000 in the T2500, >a V.32bis upgrade would be just a matter of software. I am especially >skeptical of this as I had to pull and replace chips to make the thing talk >V.32 and V.42 and V.42bis.... The truth...?) > How do you think a software upgrade is applied to a modem? The modem functions are in software stored inside chips - that's why it's called FIRMware. You saw the innards of your T2500. Did you notice the little piggyback board? That's a Rockwell module. (I also see that your firmware upgrade was for V.42 and not V.32, as you mentioned earlier) No, I'm afraid adding V.32bis to the T2500 is not a matter of just a firmware upgrade no matter what any salesperson says. Telebit originally intended that the TrailBlazer Plus have the ability to do everything in DSP so new stuff would be merely a firmware upgrade, and advertised the modems that way. Alas, adding V.32 proved to be more than the TB+ modem's processors could do, so getting V.32 fully in DSP required a new platform of faster DSP processor and faster general-purpose processor. The T1600 is the first modem that uses the faster processors, and it does not use a Rockwell module either (take that as a sign of how Telebit engineers feel about the Rockwell module). The T2500 used the Rockwell module in order to provide V.32 capability at a time when Telebit customers needed it. -- .------------------------------------------------------------------------. | Greg Andrews | UUCP: {apple,amdahl,claris}!netcom!gandrews | | | Internet: gandrews@netcom.COM | `------------------------------------------------------------------------'
schuster@cup.portal.com (Michael Alan Schuster) (04/21/91)
>There seems to be an implication that one CAN NOT use data compression >with the new 14,400 bps link rate. I haven't seen anything real to explain >this. Is it true? If so why? I HOPE that one can use V.42bis compression on >top of the V.32bis 14,400 bps link rate.... Untrue. Of COURSE you can use data compression. I have a new USR and have gotten throughputs over 3000 cps on uncompressed text files. >If these modems can theoretically reach throughputs of 57,600 bps, what >is the highest DTE rate that they support? I should think 57,600 bps would be >necessary. I ask because I was told two different things. The USR people sai d >that the highest DTE rate was 38,400 bps. The dealer I talked to told me that >they went "much higher" than 38,400 bps. What is the answer? USR is correct; your dealer is wrong. Are you surprised? >The dealer told me that USR ditched the Rockwell data pump for their own >design and that the new modem should be much more reliable. Does anyone have >any thoughts or inside knowledge on how this might affect future upgrades? I >am imagining a fax upgrade, I guess, as a possibility.... I know that chips >with fax capability are becoming more common, and that, among others, Rockwell >has them.... In my opinion this was an excellent move. The DSP functions are now done by two TMS 32025 chips. Their firmware is OFF BOARD ... on two 27512 eproms. The third piece of firmware is another 27512 which runs the 80188-16 and runs the modem's general operations. These three chips can be swapped out for $15 and can TOTALLY CHANGE THE PERSONALITY OF THE MODEM at will. Thus, future upgrades are bound only by the capacilities of the chipset and what USR is willing to write for them. Mike Schuster | CIS: 70346,1745 NY Public Access UNIX: ...cmcl2!panix!schuster | MCI Mail, GENIE: The Portal (R) System: schuster@cup.portal.com | MSCHUSTER
cs352a41@cs.iastate.edu (Adam Goldberg) (04/21/91)
gandrews@netcom.COM (Greg Andrews) writes: >In article <6465@husc6.harvard.edu> conrad@popvax.harvard.edu writes: >> >>If I am right (and the article is either wrong or VERY poorly written), >>what is the highest throughput that could be hoped for? 14,400 X 4 = 57,600. >>I know that this would be difficult to sustain on real data, but is it a good >>number for a top limit? >> If these modems can theoretically reach throughputs of 57,600 bps, what >>is the highest DTE rate that they support? I should think 57,600 bps would be >>necessary. >> >Why should it be necessary if, as you say, you wouldn't be able to get that >much compression out of real data? How many computers can handle a sustained >data rate of more than 38400 bps? What kind of processor hardware would be >necessary for the modem to handle a 14400 bps (full) duplex modulation AND >compression/decompression of the data AND an RS232 interface speed of 57600? >Would you really be willing to give up the amount of money and desk space for >such a monster? Especially if you know in advance that you won't utilize the >speed capabilities beyond 38400 bps more than perhaps 2% of the time? >I think the reason most modem manufacturers are creating modems with a max >RS232 speed of 38400 are doing it for three reasons: (a) It doesn't require >exotic, costly processors, (b) Real life data transfers won't be more than >2.7:1 compressible 98% of the time, and (c) Few computers can handle data >rates above 38400 bps. In short, they're designing a modem that will meet >your data transfer needs without exceeding your budget needs. I know this is slightly off the subject, BUT: Since it is (theoretically) possible for an effective data transfer rate of 57,600, but it would take 'exotic, costly processors', it struck me: Hmmm, is it possible (or has anyone attempted) to: o Construct such a very, very fast modem. o Design it as an internal card with DMA--ie, it would take a very strange RS232 port to support such high speeds, and the processor would be completely taken over by it, so wouldn't it make sense to have the modem work like a disk drive and deposit data directly to memory? Clearly if a HST modem has a 68k inside of it... Anyone know of such a beast (that is, know of anyone ever considering building such a beast--I'm pretty sure it hasn't ever been commercially available)? Just a thought, -- +-----------------------------------------------------------------------------+ ! Adam Goldberg ! * ! "It's simple! Even a PASCAL ! ! cs352a41@cs.iastate.edu ! * ! programmer could do it!" ! +-----------------------------------------------------------------------------+
dcarr@hobbit.gandalf.ca (Dave Carr) (04/22/91)
In <cs352a41.672247174@zaphod> cs352a41@cs.iastate.edu (Adam Goldberg) writes: >>I think the reason most modem manufacturers are creating modems with a max >>RS232 speed of 38400 are doing it for three reasons: (a) It doesn't require >>exotic, costly processors, (b) Real life data transfers won't be more than >>2.7:1 compressible 98% of the time, and (c) Few computers can handle data >>rates above 38400 bps. In short, they're designing a modem that will meet >>your data transfer needs without exceeding your budget needs. (D) RS-232 has its limits. You wouldn't want to advertise you can do 56 or 64K over RS-232, otherwise the end-user starts screaming at your technical support people that he is getting errors on his "short" 10 foot cable. >Since it is (theoretically) possible for an effective data transfer rate of >57,600, but it would take 'exotic, costly processors', it struck me: Hmmm, >is it possible (or has anyone attempted) to: Exotic, no. Current, Yes. One dedicated 80960CA ($75US), can COMPRESS a 256K bps link using V.42 bis compression. Compressing a 14.4 K bps link is almost archaic. > o Construct such a very, very fast modem. > o Design it as an internal card with DMA--ie, it would take a very strange > RS232 port to support such high speeds, and the processor would be > completely taken over by it, so wouldn't it make sense to have the modem > work like a disk drive and deposit data directly to memory? Clearly if > a HST modem has a 68k inside of it... No need to get this fancy at this speed. Just keep the modem cable short. RS-232 should :-) work at 56K for 2 feet or so. No need for DMA. Just deeper FIFO's on the USART. Put a Z16C30 USC with 32 byte FIFO's, and the service routine would only need to run every 20 milliseconds. CPU overhead lower than most serial ports use at 9600.
ho@hoss.unl.edu (Tiny Bubbles...) (04/22/91)
As I read this thread, and its descriptions of 80188-16's and 68000-series
processors driving modems, I am becoming more and more painfully aware of a
sad fact:
If and when I buy a v.32 modem, it will be smarter than the computer that
"drives" it. (A souped-up XT.)
Not unlike the Commodore computers that had 6502's in their disk drives, I
suspect.
--
... Michael Ho, University of Nebraska
Internet: ho@hoss.unl.edu | Harry was too homely for Sally. (I have proof.)
Disclaimer: Views expressed within are purely personal and should not be
applied to any university agency.bdavis@nic.cerf.net (Barry Davis) (04/24/91)
In article <1991Apr21.032236.21724@netcom.COM>, gandrews@netcom.COM (Greg Andrews) writes: > [deleted] > I think the reason most modem manufacturers are creating modems with a max > RS232 speed of 38400 are doing it for three reasons: (a) It doesn't require > exotic, costly processors, (b) Real life data transfers won't be more than > 2.7:1 compressible 98% of the time, and (c) Few computers can handle data > rates above 38400 bps. In short, they're designing a modem that will meet > your data transfer needs without exceeding your budget needs. I agree wih (a) and (b), but (c) should be qualified to include Terminal Servers. With more and more LANs including terminal servers which CAN do 38.4 kbps on more than one port at a time, like the Emulex Performance Series Server (blatant plug...), having a 38.4 kbps interface and hardware (RTS/CTS) flow control doesn't hurt. Although 19.2 kbps is probably good enough for V.32bis applications with compression, the extra speed is a selling point for MIS people looking to get the most for their money. The issue in terminal servers running above 9600 bps serial port rates is one of load balancing. There are on-going debates as to whether an interrupt driven or polling scheme provides the best throughput. I believe that integrated multi-I/O boards are largely interrupt based (ie ALMs, Systechs, etc.). This is the main reason for terminal servers, offloading the high speed interrupt traffic from the CPU to a dedicated device on the LAN. Terminal servers using interrupt schemes provide quick processing of async data into IP datagrams during interactive sessions to a network host. But, this interrupt scheme causes a sudden degradation of server performance in the presence of bulk data applications such as WAN use. In the implementation of SLIP/CSLIP/PPP on terminal servers, a polling scheme seems to work better. This polling scheme looks at the serial ports at intervals determined by an internal counter/timer. Two lists are used to keep track of idle and active ports, the active ports receiving priority in the polling scheme. While the inherent latency of this polling scheme may cause problems in time critical applications that require a very short round-trip time, it does not cause a problem to interactive sessions since the round-trip time rarely exceeds 100 msec. This polling scheme will also assure that there is an even degradation, load balancing, on all ports of the server. This will happen as async traffic builds, but will take longer to occur than in an interrupt based I/O scheme. I am obviously biased towards a polling scheme due to the fact that I use my server for dial IP applications in which bulk data is the norm. But, once again, the extra speed and hardware flow control come in very handy for this type of application, if the modem can do them reliably. =============================================================================== Cerafin E. Castillo ______ ______ TCP/IP LAN/WAN Connectivity \ / INET: cec@emulex.com EMULEX Corporation ______ \/ ______ 2880 Zanker Rd., Suite 204 /\ UUCP: uunet!emulex!cec San Jose, CA 95131 ______/ \______ (408) 452-4777 E M U L E X "Beauty does what Beauty does best; it's Beautiful!" ================================================================================