|Forums | USR | Modem retransmission problems on certain analog-to-T1 connections||Watch|
|Posted - 10/12/2000 6:19:32 AM |
We are a hardware development house and I am submitting this question on behalf of a client. Our client is developing a product that depends on a V.90 link between various residential sites and a central server. The data being transmitted is of a continuous nature, consisting of digitized voice (live conversational voice transmitted from each end of the connection to the other), plus other data of a general nature. It is my understanding that for the application to work properly, the connection rate needs to be at least 20-odd kbits/sec. The modem being used is a 3COM external V.90 modem.
Our client has installed a beta-site at a location in the United States. The residential sites are equipped with standard analog lines supplied by the telco. The central server uses a RAS (Remote Access Server) to connect to the public telephone network by means of a T1 trunk. All of the residental sites that are participating in the test are located in the immediate geographical vicinity of the server.
The problem is as follows:
Some of the connections between certain residential sites and the central server suffer from multiple retransmission problems that are preventing the product from being able to sustain a (digitized) telephone conversation. The connection speed is satisfactory, being around 40 kbits/s or more. Forcing the modem to connect at a lower speed does not cause more reliable transmission and fewer retransmissions. At other residential sites, using the same modem type, and connected to the same server through the same T1 trunk at the server end, no problem is observed. The connections are consistent from one call to the next -- each residential line either has a problem with data being retransmitted or it does not. Our client has eliminated the possibility of a problem with its own application by connecting a PC and external 3COM modem at the residential sites and trying to send large quantities of data from the central server to the residential site. The result was a rate of approximately 15% retransmitted frames for the problematic connections versus about 1 retransmitted frame per 3000 frames for a good connection. That is, the problem is the same when using a PC connected to the modems. To eliminate the possibility of the problem lying with the server itself, our client made tested connections between each of the residential sites and an ISP, with the connection being made through the same T1 trunk that serves the central server, but redirecting the call through a PBX to the ISP (with the connection between the PBX and the ISP being made via an analog line). The result was repeated, with some lines showing retransmission problems and others not, exactly matching the locations at which the problems were originally reported.
A further test was made by reconnecting the central server (RAS) to the public telephone network using analog lines in place of the T1 lines. This time, the connections were consistently good between all of the residential sites and the central server.
The above results lead us to believe that the problem lies with the T1 trunk equipment, and not with the RAS nor with the modems. However, it is curious that whatever may be the problem with the T1 trunk equipment, it is not affecting all of the modems (which are all of the same 3COM type) in the same way, as described. Some don't have any problem, whereas others are degraded by a high retransmission rate.
I am not well-versed in the various parameters that it might be possible to configure on T1 trunk equipment, and I had considered that the sending level might be too high (causing the modems to suffer from signal saturation problems due the line length being short at the problematic sites) or too low (causing the reverse problem - of the signal arriving at too weak a level due to the line being particularly long at the problematic sites). However, the client tells me that the received signal levels, as measured by the modems, are satisfactory at all of the sites, and all fairly similar.
We would be grateful of any suggestions that might help our client overcome this curious problem.
|Posted - 10/12/2000 9:03:56 AM |
I have a couple of new points to add to my first posting:
1. Forcing the modems to work in V.34 mode does not help.
2. The T1 lines at the central site belong to AT&T and the analog lines belong to Quest.
3. The client has approached AT&T asking how their T1 equipment might be affecting V.90 quality of service. AT&T's response was that the T1 equipment does not guarantee support for V.90, and that BRI (ISDN Basic Rate Interface) should be used instead. AT&T were reluctant to offer any assistance in trying to solve the problem.
Our client feels that their customers will often wish to connect the central server part of their product to T1 lines, and that therefore we need to understand the cause of this problem and find a solution. Even if the T1 equipment used by AT&T does not guarantee support for V.90, that does not seem to explain why the connection from that equipment via the public network to some local analog lines is OK whereas to others it suffers from a high retransmission rate. It also does not seem to explain why even V.34 is badly affected at the problematic locations.
I look forward to hearing suggestions from any of you.
|Posted - 10/14/2000 3:50:27 AM |
I'm not of why exactly such occured, but on connections to my ISP, both V.90 and V.34, I used to get a certain amount of Packet Retranmissions, regardless of what Modem I was, than what one of my friends gets nearby, even with the exact same Connection speed.
I had Verizon run a new line (462FT) from the road to my demarc, which they did for free to shut me up. The workers found that my line was not properly grounded before for one, and it was three inches below the ground. Also, many of the pairs on the old line were strangely non-functional.
After the new drop was run, I got exactly the same speed, but the retransmission errors ceased. I couldn't tell anything about the line that was wrong through diagnostics, but after the drop was run, the problems stopped.
Maybe just my luck.
|Posted - 10/15/2000 9:26:52 PM |
You didn't mention what protocol your clients are using. Even if it is a private network, if you are using TCP/IP you might benefit from some network tuning such as optimizing MaxMTU.
|Posted - 10/28/2000 10:23:56 AM |
It sure sounds like the TELCO has a line-coding mismatch (or similar problem) to these residential lines
I would suggest:
Also, try to determine what type of facilities the problematic residential lines are on: copper, SLC/DLC, distance to CO; type of CO, and how client CO is connected to server CO.
|Posted - 11/1/2000 11:42:38 AM |
It sounds like you've narrowed the problem down to the T1 side of things.
One question I'd have is what kind of equipment is being used to connect the server to the T1 line.
Generally what is done is the individual telco lines are aggregated (up to 24 lines per T1) and run over individual channels on the T1 "local loop" to the far end (the server) where some kind of "channel bank" will split out the individual lines again.
The incoming lines are provisioned by the phone company to connect to a specific T1 channel. You should be able to obtain a list of what channel is assigned to what incoming telephone number.
The testing I would do depends on whether the channel bank is supplied by the phone company, or belongs to the client. If it's the client's, I would re-assign the problem channels to the working channels (exchange them), and see if the problem follows the problem channel to the formerly working hardware, or if it stsys with the channel. That would indicate whether the problem was with the channel bank hardware.
Then if it appears the channel bank is not responsible, you could have the problem lines re-provisioned by the phone company to T1 channels which have been working properly. This would indicate whether the retransmissions are related to the specific T1 channels within AT&T's hardware. You might be able to then use this information to get the phone company to diagnose the problem further, and possibly fix the equipment related to those channels.
If instead of a channel bank, the RAS server end uses something like a 3Com Total Control chassis with HiPer ARC and HiPer DSP cards, be sure that end has been tested (perhaps swap the DSP cards to see if the problem follows the card), because telco is notorious for pointing fingers at "customer equipment" when you complain about vague symptoms like these retrans errors.
Sometimes it's as simple as a reversed Tip and Ring on an individual channel, where you get a connection, but it's loaded with errors. Just getting telco to admit it can be like moving mountains.
BobR @ NetworkTwo
|Posted - 11/15/2000 5:03:34 AM |
This is getting really interesting. I have similar problems here in Australia, and we have even done things like shift our copper circuit from a System 12 exchange to an AXE. I have put a detailed post onto the
A scan though these forums shows case after case of a modem going fine then crashing to very low through put. I think there is a major stability problem here with the design of our current generation of modems which most users fail to recognize, thinking It ha slocked up again, reset and all is fixed. People trying to run full time connections it seems are coming to recognize this problem.
Click Here To Close Thread, Administrators & Moderators Only.
Show All Forums |