|Home • Why 56k=v.Unreliable • 3Com Engineer Confirms Problem|
"3Com Engineer Responds"
I posted the following message to the USR-TC mailing list:-----Original Message----- From: Allen Marsalis <email@example.com> To: firstname.lastname@example.org <email@example.com> Date: Thursday, March 05, 1998 10:15 PM Subject: Re: (usr-tc) Breaking v.90 / 3Com news >Dunno what you think of Jack Rickard but you might want to take a look >at this related article on 56K issues also.... I just loved the >empirical results of his 56K dialup tests.. x2 was a good 10kbps >faster on average than kflex across 89 national isps.. Can only imagine >what MZ thinks of Jack and his methods.. > >http://www.boardwatch.com/mag/98/mar/bwm24.html> >I also heard MPIP for HiPer is shipping in the next release scheduled for >mid to late March. Can't hardly wait.. > >allen I found the article to be very interesting. Also think his dialup tests were severely flawed. I've put a link to the article and added why the tests are worthless on my page at http://pages.prodigy.net/bbhi/r-rnut-x2.htm Thanks for the info. Aloha, Richard
This is the reply of John Powell, 3Com Engineer:From: "John Powell"<John_Powell@mw.3com.com> To: firstname.lastname@example.org Cc: email@example.com Date: Mon, 9 Mar 1998 03:00:49 -0600 Subject: Re: (usr-tc) Breaking v.90 / 3Com news Aloha Richard, I checked out your web page, and it sure looks like you have had a bad time with x2 (and even more with K56). For the x2 problems, I apologize. I can say with a great deal of certainty, this issue you are encountering is a pad issue. The ability to get x2 on LD calls and not on local (with the definition of "local" and "LD" being a judgement call by the telco) is a tell-tale sign. I can also say with a great deal of confidence that you are REALLY going to like our implementation of V.90! The pad problems are quite rare, as we got most of them covered, but there were certainly enough people having problems to justify an overhaul of the pad detection scheme. I think you hit the issue on the head in your comments on the pad issue and telco configurations. There is no way that the telcos will be able to put only pads on the network that 3Com/USR, Rockwell, Lucent or whoever wants to be in the path. We came to that conclusion quite some time ago. We could have tried to put a patch in for every possible digital pad we have found over the last year (and various combinations of digital impairments), but that would have been an endless process, would have taken up huge chunks of memory and would have caused incredible havoc for ISPs and client customers trying to figure out what revs of code are on either end and what pad or RBS pattern was causing the problem, in addition to sucking up development and test resources that were best put on the "total kill solution". The only way to do this right was to kill them all at once, on the fly, automatically. This took a fairly signiificant amount of research and development and had to be implemented carefully. The Boardwatch article pretty much covers the topic, see the section on "DIL" (or "Digitial Impairment Learning"). The way the "DIL" was implemented in 3Com V.90 modems will solve exactly the logistical problems you describe. It is designed (and tested) to detect the digital impairments during training, and build a custom constellation on the fly designed to overcome or circumvent whatever digital impairments it encounters in the path. This works on a call-by-call basis to handle different routing paths and for use on different lines served by different COs and/or PBXs with different settings. It even works through A-law to mu-law conversions. It is very automatic and requires no configuration, it just works. When you get the V.90 upgrade for your Courier, and connect to a V.90 server, you will hear a new "bong-bong" sound at the end of the training sequence, that is the DIL sequence. This concept has been in field testing since way back in October, works great and is very refined now. As far as your points that the Boardwatch testing was flawed due to the testing being mostly toll calls. You are right to a degree, but not totally. You would be surprised how many ISPs use creative, innovative techniques pioneered by the CLECs to provide local dialup numbers to super POPs concentrated in cities far away. These calls are backhauled over digital lines back to the real POP, often over multiple AMI links that add additional Robbed Bits with digital padding applied that is consistent with an LD call. Boardwatch's tests showed mostly 1-3 Robbed bits in the path, which is pretty typical of a CLEC networked Super-POP "local" call. Also note that the "throughput tests" done to verify connect message to throughput consistency were done to local Denver ISPs, not over LD calls. They also "favored" local POPs in their wardialer program (both for the reasons you mention, plus the obvious cost factor). On the similar note you made on 3Com's testing procedures. The description of the testing in the article was just a "gloss-over". The concept of ensuring a duplication of the "typical local call" was not lost in the test design and site choices. There were 11 POPs in 10 countries, with 2 POPs in the US. One on the "left coast", and one in the middle (Skokie). The vast bulk (roughly 70%) of the testers were local to the test POPs, and the remainder were long distance. This provided a very wide variety of pad, robbed bit and Round trip delay values and covered the "network model" very, very well. We also made special efforts to test on local calls in areas known to cause trouble to x2. Raleigh/Durham, NC. and Korea are two that come to mind. I wish I had known their were problems in Hawaii a few months ago, that would have been a real nice field trip in December ;-) Anyway, I did not want to barrage you with data and facts, but the conclusions you made were based on some partially false assumptions and begged for clarification. I truly regret the trouble you have encountered, but know that there are many, many people at 3Com that totally "give a hoot", do know what some of our customers are experiencing and are dedicated to resolving the problems once and for all. I am confident you will be totally blown away by the improvements we have put in this code. Our goal is to achieve 92% network coverage. 5% are taken off the top due to additional A/D conversions, and another 3% that have so much noise or other analog impairments that it is just not possible. We believe we have reached, or are very close to, that goal with our V.90 release. We will probably not be perfect, but this is the result of two years of solid R&D and should please many a user. I hope this clears the air a bit, and gives you something to look forward to. I know you are pessimistic, and for good reason, but I know you will be pleased when you get a chance to make a V.90 call with your Courier. Remember, these improvements in digital impairment detection require V.90 code at the server end also, otherwise you are in x2 backwards compatibility mode with the same restrictions (which will be fine for most, but you really need the V.90 fixes for your environment). Regards, John Powell 3Com Carrier Systems Division x2/V.90 Engineering Team
send a message to mailto:firstname.lastname@example.org with this text in the body:
subscribe usr-tc (if you subscribe, you will receive all messages, primarily dealing with USR Total Control equipment used by ISPs)