acton@cs.ubc.ca (Donald Acton) (10/28/90)
One poster to the net recently provided some favourable comments about the new Intel 9600ex modem. Since I am considering purchasing this modem I was wondering if others felt the same way about this product. If you have had any experience using this beast, be it good or bad, I would be interested in hearing about it. Donald Acton acton@cs.ubc.ca
sqh@dhw68k.cts.com (Steve Hubbell) (11/04/90)
I am in the market for a new 9600 and was curious to know what
people felt about the Intel 9600EX?
o Is it reliable?
o Any compatibility problems?
o For the same price, could I get something better?
o Could I get something cheaper (and have similar features)?
o Any recommendations on where I could get one for a GOOD price?
Thanks a lot....reply by mail and I will post a summary.
--
+---------------------------------------------------------------------------+
| Steve Hubbell sqh@dhw68k.cts.com |
+---------------------------------------------------------------------------+gregh@inmet.inmet.com (11/08/90)
About the Intel 9600EX: I am having difficulty finding anyone who has them in stock. Does anyone know someone who will sell me one, for love or for money? Thanks, Greg Herlihy gregh@inmet.inmet.com
news@m2xenix.psg.com (Randy Bush) (11/10/90)
> About the Intel 9600EX: I am having difficulty finding anyone who has them > in stock. Does anyone know someone who will sell me one, for love or for > money? Dunno about love, seems a poor trade for a modem. But no accounting for East Coast habits, I guess. The following is from an Intel support person on another net. The equivalent Internet address is mehdi.attaran@p2.f10.n105.z1.fidonet.org. randy (who does not work for Intel, but uses a 9600ex) - - - - - - - - - - - - - - c u t h e r e - - - - - - - - - - - - - - I'm not sure what specs you need. It's a V32 modem with MNP 4 & 5, and V42 & V42bis capabilities. Throughput of up to 38400 bps are possible. Call Intel BBS for details. The number is (503) 645-6275. They are not part of FidoNet. The modem can be purchased by anyone at PC-Connection for $499. The sysop special price is $399 for up to 2 modems. -- Mehdi -- * Origin: Atarian BBS - (1:105/10.2) -- ..!{uunet,qiclab,intelhf,bucket}!m2xenix!news
schuster@cup.portal.com (Michael Alan Schuster) (11/13/90)
PC Connection today said that their next shipment of 9600EX modems will be held up for a bug fix. Someone on CompuServe who has evaluated several V.32 modems discovered a bug (confirmed by Intel) in the handshake sequence. It seems that if you lock the DTE rate to 38400 and connect with a USRobotics Courier 2400 (or perhaps other non-error-correcting 2400's) there is a problem with the handshake. I don't know, however, if this is the bug Intel was referring to. Today I called the Intel BBS (which presumably has 9600EX's online) in V.32/V.42bis mode using my USR Dual Standard. Reproducably and consistently the modems dropped the connection on the same character on the same screen of the menus. The USR link diagnostics said the connection was dropped because of "extra stepup". This sounded V42-ish to me, so I disabled V.42bis data compression and called again in MNP5 mode. Voila ... no problem. I've used this modem for months and connected with dozens of different brands, etc. with no problem. Does Intel have a V.42bis bug as well?
foxm@boulder.Colorado.EDU (FOX MICHAEL) (01/09/91)
Has anyone heard anything good or bad about this modem? Mike
gregh@inmet.inmet.com (01/11/91)
No one seems to have an Intel 9600EX since they are not currently shipping. "Unforseen production delays" have pushed the shipping date to mid to late this month. Greg Herlihy gregh@inmet.inmet.com
CHARLIE@UMVMA.BITNET (Charlie Turner) (01/19/91)
Given all the discussion about V.32 modems, let me share my initial experiences with my just arrived Intel 9600EX modem. I connected the 9600EX to my PC and ran Procomm-Plus. Literally I took the modem right out of the box and didn't reset any of the configuration parameters from their factory default. The modem automatically followed any interface speed that I set in Procomm. There was no problem setting the interface speed to 38.4kbps and dialing into a 2400 speed MNP5 Multitech modem. The reliable connection was established with no problems. Next I called long distance to a Robotics HST/DualStd. Again I got a 'reliable' connection with no problems. I called long distance to a Hayes Ultra 9600. It took three calls to get the connection established, however once it was established it was completely solid. Perhaps the first two calls took a marginal route. I was somewhat surprised (due to lack of prior experience with dial 9600 speed modems) at how long it takes for these modems to establish connection after the phone answers. The average time was 20-30 seconds. Is this normal? So my initial experience with the 9600EX has been very good. All the talk about V.32bis modems makes me wonder if I jumped the gun and should have waited before buying into V.32 hardware. On the other hand, since I bought this 9600EX thru the BBS sysop's promotion for half price, I feel I got an excellent value. The only minor problem I had was (I think) due to COM port overrun. I run DesqView. That combined with the 38.4kbps interface speed likely means I need to get a 16550 buffered UART. The simptom was Zmodem asking for retransmissions when the modem connection was in fact operating in reliable mode. When I tried using Ymodem-G the download was aborted on my end, making me suspect the problem lies between the modem and my comm program.
tnixon@hayes.uucp (01/24/91)
In article <9101190810.AA02289@ucbvax.Berkeley.EDU>, CHARLIE@UMVMA.BITNET (Charlie Turner) writes: > I was somewhat surprised (due to lack of prior experience with dial > 9600 speed modems) at how long it takes for these modems to establish > connection after the phone answers. The average time was 20-30 seconds. > Is this normal? Yes. Because of the need to measure the propagation delay and train both adaptive equalizers and echo cancellers, it takes V.32 modems anywhere from 10 seconds and up to connect, longer on bad lines. Plus, after the carriers connect, you still have another second or two of protocol negotiation. > The only minor problem I had was (I think) due to COM port overrun. I > run DesqView. That combined with the 38.4kbps interface speed likely > means I need to get a 16550 buffered UART. The simptom was Zmodem asking > for retransmissions when the modem connection was in fact operating in > reliable mode. When I tried using Ymodem-G the download was aborted on > my end, making me suspect the problem lies between the modem and my > comm program. I'd say you definitely need a 16550, with software that knows how to use its FIFOs, if you're going to run under Desqview. Data loss due to interrupt latency is undoubtedly the cause of the problems you saw. -- Toby Nixon, Principal Engineer | Voice +1-404-449-8791 Telex 151243420 Hayes Microcomputer Products Inc. | Fax +1-404-447-0178 CIS 70271,404 P.O. Box 105203 | UUCP uunet!hayes!tnixon AT&T !tnixon Atlanta, Georgia 30348 USA | Internet hayes!tnixon@uunet.uu.net
rbt@tous.uucp (Robert B. Tate) (02/11/91)
In article <4028@gazette.bcm.tmc.edu> sob@tmc.edu (Stan Barber) writes: >I just got a couple of these and am quite impressed with them. > >I tested against Telebit T2500s as well and they will connect to them >fine in V.32 mode. > >Does anyone know if Intel will have V.32bis support as a prom upgrade or >will it be a new product? > >Thanks in advance, > I have a site that calls into my TB+ with an Intel 9600ex at 2400 baud and w/MNP5. It has 'locked' up the TB+ several times so far. What seems to happen is that the connection is made and a 'sz' tranfer to his mach. is started in some dir to get all the files that he doesn't have already. This will work for a while, then it just stops. It doesn't seem to be at any special size/time/file#. I have others (modems w/MNP5, 2400 baud) that call in and don't have any problems. Does anyone have an ideas what to look for? -- rbt@tous.UUCP Robert B. Tate | A little knowledge is a dangerous {ucf-cs,peora,uunet}!tarpit!tous!rbt | thing. Any less can kill you.
luce@aurs01.UUCP (J. Luce) (02/11/91)
In article <4028@gazette.bcm.tmc.edu> sob@tmc.edu (Stan Barber) writes: >I just got a couple of these and am quite impressed with them. > >I tested against Telebit T2500s as well and they will connect to them >fine in V.32 mode. > >Does anyone know if Intel will have V.32bis support as a prom upgrade or >will it be a new product? > >Thanks in advance, > I talked to an Engineer at Intel and as was expected, V32bis will require a whole new data pump (i.e. a new board). Therefore, expect it to be a new product. Probably under a 'new, improved' 9600EX but no simple way to upgrade. May be costly to upgrade, also (almost the price of a new modem). At least, that was the inference. ------------------------------------------------------------------- John Luce | Life is the leading cause of death Alcatel Network Systems | ----------------------------------------- Raleigh, NC | Standard Disclaimer Applies 919-850-6787 | Mail? Here? Try aurs01!aurw46!luce@mcnc.org | or ...!mcnc!aurgate!luce -------------------------------- or John.Luce@f130.n151.z1.fidonet.org
kdg@world.std.com (Keith D Gregory) (02/12/91)
In article <1991Feb11.022713.11146@tous.uucp> rbt@tous.uucp (Robert B. Tate) writes: >I have a site that calls into my TB+ with an Intel 9600ex at 2400 baud >and w/MNP5. It has 'locked' up the TB+ several times so far. What seems >to happen is that the connection is made and a 'sz' tranfer to his mach. >is started in some dir to get all the files that he doesn't have already. >This will work for a while, then it just stops. It doesn't seem to be at >any special size/time/file#. > >I have others (modems w/MNP5, 2400 baud) that call in and don't have any >problems. Does anyone have an ideas what to look for? I have had problems with my 9600EX, calling a Telebit at 9600 with MNP-5. I also had some problems calling the same system with an old Codex using MNP-4. When I disabled MNP, problems went away. My best observation is simply "it happens when there's a lot of data movement, especially when I'm receiving." I'm wondering if there might be a buffering problem somewhere, maybe in the Telebit, maybe not. I only lost connection a few times with the Codex, each time during a big ASCII printout. WIth the 9600EX, it was happening all the time. So, there's my 2c. -kdg
fg041@unocss.unomaha.edu (fg041) (02/12/91)
In article <4028@gazette.bcm.tmc.edu> sob@tmc.edu (Stan Barber) writes: >I just got a couple of these and am quite impressed with them. > >I tested against Telebit T2500s as well and they will connect to them >fine in V.32 mode. I was impressed with mine at first, but now I am rather disappointed. Sure, it works like a champ when talking to the newest and greatest HS modems, but it has failed miserably against the installed user base of older modems. I actually had to take the 9600ex off of the BBS due to user complaints of inability to access it. For some reason, Intel has chosen only to present the Bell 103 answer tone for three seconds. Many modems, including the Racal 3451 here at work, will not respond within that period. Of course, most dumb 300 baud modems will not work either. (Yes, some people actually use them.) I did report it to Intel, and they admitted they knew of the problem but could not/would not say when a fix was due. (Real Soon Now ;-) The guy I spoke to would not speculate on the reason the 103 answer tone is so short. (Any ideas out there in netland ??) >Does anyone know if Intel will have V.32bis support as a prom upgrade or >will it be a new product? Right now I could care less about v.32bis for the thing. I just want it to operate properly with the standard modems that have been around for the past several years. (And no, I don't consider telling the affected users to get newer modems an appropriate solution.) It's too bad that when a product such as the 9600ex came out, it was so thoroughly tested against the Robotics and Telebit macho modems, when it is so glaringly obvious that they failed to verify the performance with the older ones. I could possibly see one or two models having difficulty, but this is with several types of modems from several different vendors. I just hope they get this fixed soon. Good Day! JSW (winslade@zeus.unomaha.edu)
pj@pnet51.orb.mn.org (Paul Jacoby) (02/14/91)
Just to add fuel to this fire, I note that I've had problems with my Practical Periphals 9600SA modem locking up when talking to a T2500 with a LAPM connection. If I drop back to MNP, things work just fine, with the exception of quirk file transfer speeds. It looks like the latest ROM (v1.28) from PP may take care of this problem. The owner of the T2500 has said that previously a few MultiTech users had similar problems, and ROM updates from MT also ended up taking care of the problem.... It almost looks like there is something slightly quirky in the T2500 as well, since few other modems have this LAPM problem. (BTW, I have sent a whole load of info to PP, and they have been VERY helpful. Once my 1.28 ROM arrives, I hope my adventures will be over) .-----------------------------------------------------------------------------. | UUCP: {crash tcnet}!orbit!pnet51!pj | RTFD = Read The Silly Doc! | | INET: pj@pnet51.orb.mn.org | | `-----------------------------------------------------------------------------'
sichermn@beach.csulb.edu (Jeff Sicherman) (02/15/91)
In article <3186@unocss.unomaha.edu> fg041@unocss.UUCP (Jack Winslade) writes: >In article <4028@gazette.bcm.tmc.edu> sob@tmc.edu (Stan Barber) writes: >>I just got a couple of these and am quite impressed with them. >> [ comments & complaints deleted ] > >Right now I could care less about v.32bis for the thing. I just want it to >operate properly with the standard modems that have been around for the past >several years. (And no, I don't consider telling the affected users to get >newer modems an appropriate solution.) > >It's too bad that when a product such as the 9600ex came out, it was so >thoroughly tested against the Robotics and Telebit macho modems, when it >is so glaringly obvious that they failed to verify the performance with >the older ones. I could possibly see one or two models having difficulty, >but this is with several types of modems from several different vendors. > I can't help but think that this is reflective of the fact that the manufacturers and interested parties spend incredible amount of time and effort to develop and standardize the modulation, correction, and other low level characteristics of modems and tend to neglect and otherwise give short shrift to many of the higher level functions as far as their standardization goes - leading to problems such as this. Instead of working from and towards specifications, it's mostly chaos trying to match everybody else on case-by-case bases. Jeff Sicherman
tnixon@hayes.uucp (02/15/91)
In article <3186@unocss.unomaha.edu>, fg041@unocss.unomaha.edu (fg041) writes: > For some reason, Intel has chosen only to present the Bell 103 answer tone > for three seconds. Many modems, including the Racal 3451 here at work, will > not respond within that period. Of course, most dumb 300 baud modems will > not work either. (Yes, some people actually use them.) The 2250/2850 Hz tone (unscrambled binary 1 signal for Bell 103, Bell 212, V.22, and V.22bis) is sent for three seconds because the CCITT studies indicated that this was more than long enough. A _real_ (dumb) Bell 103J modem, as well as all of these others, will respond in 610 milliseconds (plus the round-trip delay of the circuit) from the start of the signal. Extensive testing by all other manufacturers who are members of the CCITT (including Racal-Milgo US and UK!) uncovered no modems that wouldn't respond in under 3 seconds. This time limit is now part of the V.32 and V.32bis standards, so you'll find it in virtually all newly-released V.32 and V.32bis modems (including Hayes Ultra 96). > I did report it to Intel, and they admitted they knew of the problem but > could not/would not say when a fix was due. (Real Soon Now ;-) I sincerely hope that Intel uses extreme caution in "fixing" this problem. It is important that if both the originating and answering modems are V.32/V.32bis AutoMode modems (support lower speeds, which most of them do), that both of them know in advance the duration of this timer. Otherwise, they may inadvertently and unnecessarily connect using V.22bis instead of V.32, if the originating modem is manually-dialed or otherwise connected to the line too far into the answer tone (or even after the answer tone). > Right now I could care less about v.32bis for the thing. I just want it to > operate properly with the standard modems that have been around for the past > several years. (And no, I don't consider telling the affected users to get > newer modems an appropriate solution.) I think you should blame Racal, who were active participants in the development of the Automode Procedure, for not speaking up and saying that one or more of their older products would have a problem with this. Perhaps they just didn't care, and considered other factors to be more important. AT&T was also a very active participant in the work, and surely would have indicated if they had a problem with the original 103 modems. Hayes tested the three-second limit with the dozens of modems we have in our labs (all of our previous products [all versions of them], plus dozens from other manufacturers), and found 3 seconds to be more than sufficient; in fact, no modem we tested required more than 1.7 seconds, but we supported the 3 second limit to allow for double satellite hops and other contingencies. > It's too bad that when a product such as the 9600ex came out, it was so > thoroughly tested against the Robotics and Telebit macho modems, when it > is so glaringly obvious that they failed to verify the performance with > the older ones. I could possibly see one or two models having difficulty, > but this is with several types of modems from several different vendors. First of all, the Intel modem's "bit pump" was not designed by Intel. I believe it is a Rockwell chipset, so you'd have to blame Rockwell for this. Rockwell was ALSO an active participant in the CCITT Study Group XVII deliberations on this topic! Personally, I think Intel has been quite responsible, by following the CCITT Recommendation to the letter. It would be irresponsible of them to arbitrarily select a different value from that specified in the standard, thereby introducing possible interworking problems with other AutoMode modems. It is unfortunate that you've found some obscure modems that fail to connect even though they're presented with FIVE TIMES the amount of USB1 signal required by the applicable standards! I must say that the position of Study Group XVII on this was quite clear -- why should they take extraordinary steps to accomodate modems that do not comply with CCITT standards? I should comment, by the way, on how Hayes has addressed your problem -- we DID take extraordinary steps, even though the CCITT didn't. We implemented a new S-register, S97, which specifies the duration of this USB1 signal sent from the answering modem. The factory default is 3 seconds, as required by the standard, but it can be set in 1/10th second increments from 1.5 seconds to 7 seconds. The documentation clearly warns that making it shorter than 3 seconds can cause problems with connecting with certain older, low-speed modems (such as yours), and that making it longer may introduce problems with late- and manually-connecting Automode modems. Nevertheless, the option is there, so that you can extend the USB1 transmission tome in case you're more concerned about connecting with older non-compliant low-speed modems that your are about manually-dialed V.32 modems. Perhaps you could suggest to Intel that they implement a similar feature. I'd be happy to provide them with the documentation on Hayes' register if they ask for it; it is public and not the subject of any patent. ;-) -- Toby -- Toby Nixon, Principal Engineer | Voice +1-404-449-8791 Telex 151243420 Hayes Microcomputer Products Inc. | Fax +1-404-447-0178 CIS 70271,404 P.O. Box 105203 | UUCP uunet!hayes!tnixon AT&T !tnixon Atlanta, Georgia 30348 USA | Internet hayes!tnixon@uunet.uu.net
riddle@hoss.unl.edu (Michael H. Riddle) (02/15/91)
In <3186@unocss.unomaha.edu> fg041@unocss.unomaha.edu (fg041) writes: >In article <4028@gazette.bcm.tmc.edu> sob@tmc.edu (Stan Barber) writes: >>I just got a couple of these and am quite impressed with them. >> >>I tested against Telebit T2500s as well and they will connect to them >>fine in V.32 mode. >I was impressed with mine at first, but now I am rather disappointed. * * * >For some reason, Intel has chosen only to present the Bell 103 answer tone >for three seconds. It's not just the Bell 103. The entire answering sequence, from RING to NO CARRIER, takes less than 20 seconds. There is at least one BBS using a Courier 2400 (I think it is) that can't connect when initiating a call to my board. (Thank goodness it's local, so I can put a poll in every now and then without running up the phone bill). Unfortunately for me, the Intel is still better than the old beast I had on the line, so I'll leave it for now. But it is frustrating. >I did report it to Intel, and they admitted they knew of the problem but >could not/would not say when a fix was due. (Real Soon Now ;-) The guy >I spoke to would not speculate on the reason the 103 answer tone is so >short. (Any ideas out there in netland ??) I think your supposition below is correct: Intel was concerned about V.32 connectivity but forgot to write a test plan for older protocols that considered the entire user base. >>Does anyone know if Intel will have V.32bis support as a prom upgrade or >>will it be a new product? >Right now I could care less about v.32bis for the thing. I just want it to >operate properly with the standard modems that have been around for the past >several years. (And no, I don't consider telling the affected users to get >newer modems an appropriate solution.) >It's too bad that when a product such as the 9600ex came out, it was so >thoroughly tested against the Robotics and Telebit macho modems, when it >is so glaringly obvious that they failed to verify the performance with >the older ones. I could possibly see one or two models having difficulty, >but this is with several types of modems from several different vendors. > >I just hope they get this fixed soon. > I have asked Intel what their plans for the "automode" function of V.32bis and, as Toby has told us, eventually an option for V.32. So far, no answer. It would seem to me that a ROM upgrade for automode wouldn't be exceptionally difficult. It also seems that voluntary compliance with the industry standard would be a good defense/answer to complaints such as ours. -- <<<< insert standard disclaimer here >>>> riddle@hoss.unl.edu | University of Nebraska postmaster%inns@iugate.unomaha.edu | College of Law mike.riddle@f27.n285.z1.fidonet.org | Lincoln, Nebraska, USA
larry@nstar.rn.com (Larry Snyder) (02/16/91)
fg041@unocss.unomaha.edu (fg041) writes: >Right now I could care less about v.32bis for the thing. I just want it to >operate properly with the standard modems that have been around for the past >several years. (And no, I don't consider telling the affected users to get >newer modems an appropriate solution.) >It's too bad that when a product such as the 9600ex came out, it was so >thoroughly tested against the Robotics and Telebit macho modems, when it I don't see why these vendors need to be compatible with EVERY other modem. If it connects with the USR and Telebits - that should be fine but supporting 300 baud in 1991 seems crazy. If you want to sell your modem, let me know.. -- Larry Snyder, NSTAR Public Access Unix 219-289-0287 (HST/PEP/V.32/v.42bis) regional UUCP mapping coordinator {larry@nstar.rn.com, ..!uunet!nstar.rn.com!larry}
edhall@rand.org (Ed Hall) (02/20/91)
Gee, it can take more than three seconds just to get the handset seated in the acoustic coupler. (Yes, there are still some of THOSE around.) Some folks *insist* on waiting for the answer tone themselves, just in case a real person answers instead. Mustn't be rude, now, mustn't we? :-) -Ed Hall edhall@rand.org
tnixon@hayes.uucp (02/20/91)
In article <1991Feb19.192422.10642@rand.org>, edhall@rand.org (Ed Hall) writes: > Gee, it can take more than three seconds just to get the handset > seated in the acoustic coupler. (Yes, there are still some of THOSE > around.) Some folks *insist* on waiting for the answer tone > themselves, just in case a real person answers instead. Mustn't be > rude, now, mustn't we? But you do NOT have V.22bis, V.22, or Bell 212 acoustic couplers! These modulation schemes simply don't work well, if at all, through acoustic connections. Nevertheless, the Automode specification requires the answering modem to send the full 4 seconds of answer tone -- a human being should be able to get the handset in the cradle, or put a manual dial modem into data mode, or lift and exclusion key, in that amount of time, plus the three seconds of USB1 that are sent. Most acoustically-coupled modems at Bell 103 or V.21, and these modulation schemes are not even tried until about, oh, ten seconds into the connection. -- Toby Nixon, Principal Engineer | Voice +1-404-840-9200 Telex 151243420 Hayes Microcomputer Products Inc. | Fax +1-404-447-0178 CIS 70271,404 P.O. Box 105203 | UUCP uunet!hayes!tnixon AT&T !tnixon Atlanta, Georgia 30348 USA | Internet hayes!tnixon@uunet.uu.net