T1: A Survival Guide 91
| T1: A Survival Guide | |
| author | Matthew S. Gast. |
| pages | 263 |
| publisher | O'Reilly and Associates |
| rating | 6 |
| reviewer | ctar |
| ISBN | 0-596-00127-4 |
| summary | A potentially useful but disappointing book; skimps on the details that a book for T1 administrators should be full of. |
What a great age we live in, where you can teach YOURSELF your entire profession! As a self-taught network engineer with a major market data firm, I have great respect for some of today's tech writers who have single handedly taught me TCP/IP, Ethernet, Cisco routers, and Linux! The only aspect of my job for which I have had to rely solely on experience, (and the meager amount of information on the web) is T1s and synchronous circuits/leased lines. As far as I know, the only books which discussed the technical details of T1 and synchronous circuits are general telecommuncations text books. None are written from a contemporary network administrator's point of view. So, you understand my excitement at seeing O'Reilly take a stab at just such a book!
The book starts off at a good pace, talking about the history of the telephone network and its evolution into the digital age (the reason we have T1 available as a data service). It discusses the different terminology related to T1's, and the equipment that connects them to our routers, but makes very few analogies or examples to solidify the relationship of these terms to each other or to the big picture of networking. After discussing the physical and logical layout of T1 and its physical interface with our routers, Gast spends the next 40 pages on the nitty gritty details of T1: Timing, Framing, Coding, and the lights on the CSU/DSU. All the important aspects of T1 are discussed in a logical order. Unfortunately, it's not enough; Gast breezes through the most important and mysterious aspects of T1 without so much as one good analogy or explanation to develop the ideas. The diagrams are equally disappointing. They have a lot of information, but do little to clarify the subject matter. The T1 framing sections, especially did not get enough attention. This is the heart of T1, and really wasn't explained well enough.
After getting what seemed to be an introduction to the subject matter, I expected the rest of the book to go into further detail about the intricacies of T1 framing and coding, and ways to hash out possible problems on T1 circuits. Instead, the next 60 pages give the boring and useless details of the three most common link-layer protocols run over T1s: HDLC, PPP, and Frame Relay. Gast continues to litter the pages with confusing and uninformative diagrams, and then spends time explaining the details of each one step-by-step. Good diagrams don't need step-by-step explanation; they speak for themselves!
The level of detail he goes into for each of these protocols is similar to what you might find in a general Data Networking text. He discusses different principles of data communication as well as the specific frame formats of these protocols, but doesn't explain how these protocols specifically interact with T1. Although he gives the frame formats of these different WAN protocols, he doesn't give enough information or suggestions on using the information in any effective way. The oversimplification of many of the diagrams makes the book less useful than the RFCs which will give you the exact frame formats.
Gast assumes that if you don't work for one of the telcos, the only way you may come across a T1 is as a small business network administrator responsible for maintaining internet access via T1. That is not the case anymore; many large companies manage their own backbone and have access to leased lines, and T1 testers. The only time a T1 tester is mentioned, it's described as 'a handheld device with lots of buttons and blinking lights on it.' The principles behind T1 testing are quickly covered, but the intricacies of testing T1s and using T1 testers are not. This is unfortunate, as many Cisco routers have built in test pattern generation and loopback capabilities! (As do most standalone CSU/DSUs.)
It's obvious, as it is in many poorly written tech books, that the author knows his subject! The problem is, he doesn't consider the fact that we, the reader, may not. The book wasn't a complete waste of time; there is a lot of good information in here. Information on signaling and different types of alarms on T1s is present. The majority of it is just not explained very well, and too much time is spent on the link-layer protocols. I probably wouldn't be so down on this book if it didn't have O'Reilly's name on it.
You can purchase T1: A Survival Guide from bn.com. Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form.
CCO (Score:5, Informative)
Granted you have to dig quite a bit to find what you need, but it is all there. Everything you wanted to know, diagrams, how stuff connects to other devices, etc., all can be found there. I am not a Cisco employee, but I hit that site everyday during the course of my job.
Just curious, if you read this post, what exactly were you looking for? Specifics, not in general, maybe we can help you find what you are looking for.
Re:CCO (Score:1)
I think I have found some gems related to T1's on CCO though. That's usually where I turn if I can't find anything on groups.google or www.google.
CCO isn't meant for the layperson... (Score:1, Insightful)
Re:CCO (here is the link...) (Score:2, Informative)
http://www.cisco.com/warp/public/116/t1_flchrt_mai n.html [cisco.com]
Flowcharts, etc. T1s are hard if you make them hard. Or if you use Bay routers :)
Wow! (Score:2, Funny)
I'm having flashbacks of Tiny Elvis for some reason. "Woah! Look at the size of that icon! That thing is huuuge!!"
Yes, I understand your excitement. Those first three exclamation marks really drove it home.
Re:Wow! (Score:1)
Re:Read the title... (Score:1)
Re:Read the title... (Score:2)
Any company that pays a network engineer based on how many books they've read, how many tests they've past, or how many things they can do (but have never actually done before) deserves what they get.
Unfortunate fact of technical writing (Score:3, Insightful)
It's a well known fact that people who know a lot about a subject, and may be able to answer any question you may have if you ask them, simply can't write a book or teach a class to save their lives. Extensive knowledge does not always lead to ability to teach. I'm sure the book is extremely informative for someone who would like a reference to things related to T1, but for someone who wants to actually learn it (Such as myself), this would probably be a very difficult read at best.
I think I concur with the author in that, if it wasn't an O'reilly title, which has a history of good explanations and good writing, then it wouldn't be such a problem.
Re:Unfortunate fact of technical writing (Score:1)
As for books knowledgable technical people tend to overwrite a subject or think everything is given and underwrite.
Re:Unfortunate fact of technical writing (Score:1)
Writing, Technically (Score:2)
That being said, I've met a lot of people who were good writers but terrible technical communicators. They do a good job of explaining technical concepts, processes, and so on. But when it comes to all the boring little practical details, they just don't have the patience.
There's also issues of ego. Everybody has their own notions of what "everybody knows" or what's the "simplest" explanation. And of course everybody is wrong about these things some of the time. The best writers in the world can screw up in this way. So they need a skilled editor to help them see this issue.
O'Reilly seems to have a particular problem this way. They cover a lot of technologies with a limited audience -- such as T1 -- and they contract leading technical people to do it. Often the very inventors of the technology. It takes a really good technical editor to tell somebody like that, "That's a little unclear" or "You need to organize the material better," without bruising any egos. Not a lot editors that good -- and I don't think any of them work at O'Reilly.
Re:Writing, Technically (Score:2)
Re:Unfortunate fact of technical writing (Score:2)
Yeah, that's why the K&R C book and Stroustrup's C++ book are such poor learning tools. That's also why Donald Knuth is such a poor teacher, he knows his stuff way too well.
Really, the problem is not that people know their stuff too well, it's that they've only mastered half of the process of writing a good technical book: the first half is knowing the material, the second half is knowing how to teach it. On the other hand, many of the really *brilliant* people can do both very well. In fact, there are people out there who can do anything if they put their minds to it. Those are the ones that make the best teachers.
(One brilliant person who was a terrible teacher: Albert Einstein. Apparently he was a terrible lecturer at Princeton. Then again, he never planned on being a teacher, he just did physics because he loved it.)
experience (Score:1)
o'reilly!! really! (Score:2, Insightful)
Teach yourself? (Score:2, Insightful)
Since time immemorial, the principle of being self taught has been prevalent throughout society. Especially in the arts, but also in Sciences, where people read books and all that and became famous without any professional qualification.
The difference with Internet, is that you can learn about it by using it, from anywhere, at the same time as everyone else, and it truly is becoming a universal skill.
But in all, apart from overuse of the exclamation mark, a reasonable review.
Re:Teach yourself? (Score:2)
On the contrary, since time immemorial, the principle of apprenticeship and servitude has been prevelent in all proffesional occupations. If you wanted to learn a skill -- that was different than your father's -- you were sent to a master, to learn what you could and do whatever he told you. If you were lucky, you might eventually surpass his skill, but at the very least, you would have a great deal of experience.
Would you go to a self-taught doctor? How about a self-taught airline pilot? Self-taught lawyer anyone? Claiming the badge "self-taught" in any professional context is not a sign of determination or brilliance, it is a sign of arrogance and hubris.
Unfortunately in our industry there are lots of "self-teachers" these are typically the same people who love their job because it is also their hobby. 90% of these people are missing critical skills to get the job done. These are the same people who whine about poor writing when they find a subject that cannot be learned from a book.
Flip him the T-bird :) (Score:4, Informative)
Some practical information about using a "T-bird" device would have been helpful -- even more helpful would have been something that would suggest a "build your own t-bird tester from spare vacuum cleaner parts and save a bundle"
Whenever we've had serious problems -- rolls, flips, and bad CSU-DSU cards in the demarc, its either through trial and error "lets see is this really the TX pair? and is it polarity right?" -- or we beg, threaten, bully the CLEC test-and-turn up crew to send out a lineman, who invariably shows up with a t-bird box and pin points where the issue is.
Something also seriously lacking is some other non-protocol uses for T1 splitting, such as slicing Channelized T1 for voice, data.
All in all, save your O'reilly bucks for something you really need
Re:Flip him the T-bird :) (Score:1)
Actually, it's T-Berd (Score:3, Insightful)
Re:Actually, it's T-Berd (Score:2)
i've seen something like four different models in the field -- not even sure if any of them were actual "t-berds" proper
thanks for clarifying!
Re:Actually, it's T-Berd (Score:1)
Re:Flip him the T-bird :) (Score:2)
One would expect a survuval guide to spend a fair amount of time on trouble shooting at different levels.
You guys should contact the author and volunteer as reviewers for the second edition or something.
Interresting review... (Score:1)
Re:Interresting review... (Score:2, Informative)
Re:Interresting review... (Score:5, Informative)
Looks like inerresting geek food.
(almost) Everything you Need to Know About T1s
Ancient tech, dating back to the '60s D1 circuits. I believe there was an F1 as well which used frequency-division multiplexing (i.e. what cable does) instead of time-division multiplexing. That's a real pain in the ass because the filters get very complex, and time-division multiplexing is dead-simple these days.
Your line between your house and the CO is very simple. It's a pair of twisted copper wires with some control voltage singalling (-48VDC on-hook, ~-8VDC on-hook, ~90VAC ring). When it hits the CO though it gets filtered (400-4000Hz) and digitized (PCM I believe) at 8 bits/8kHz and stuffed into a channel on a T1 if it's heading out to another CO.
These days you usually have equipment between the FXO and the switch which strips off the high frequency data and gives that to a DSLAM/RedBack/etc. but this is about voice.
A single voice communication channel is referred to as a DS0 and codes at 64kbps (8 bits * 8000 samples/sec). There are 24 DS0s in a DS1 (the data specification of a T1 is a DS1). Every DS1 frame has a framing bit. So 24 * 8 + 1 is 193 bits. Those 193 bits are sent 8000 times a second to give you your raw DS1 speed of 1.544Mbps. The frame is reserved though so you really get a useful bandwidth of 1.536Mbps.
In the olden days T1 circuitry required the frame bit to always be a '1' to maintain sync. These days the endpoint circuitry has no trouble keeping sync and the frame bit is used for "out of band" signalling. You figure 1 free bit 8000 times a second, that's a nice 8kbps of "free" information. This OOB channel is used to talk to the remote end to do things like loopback, QoS checks, etc. since it does not interfere with the data travelling in the 24 individual DS0 (data) channels. Pretty neat trick.
Now the actual electrical signals travelling those distances aren't 0v and 1v; it'd be impossible to get any data across. One of the first methods of electrically transmitting the data was AMI - Alternate Mark Inversion. A 0 (space) would be sent as no pulse, and a 1 (mark) would be sent as a pulse in the opposite direction of the last pulse. This kept the net DC voltage on the line at 0V (important for clock recovery), and simple flip-flip circuitry could be implemented to detect a bipolar violation (two consecutive pulses in the same direction).
Back when T1s were used ONLY for voice, nobody had to worry about long strings of 0s since it was statistically impossible to keep a PCM-coded voice channel at absolute zero, and the forced-1 state of the frame bit kept the framer in sync. Nowdays though T1s can carry data and it is easily possible to have long strings of 1s or 0s. Something had to be done.
With a long string of 1s you get a long string of "+1 -1 +1 -1..." (alternate pulse for each mark, remember) -- no problem. However a zero was coded as the absence of a pulse which meant that a long string of zeros would tend to have the clock sync drift since there were no pulses to sync to. B8ZS was born.
B8ZS (Binary 8 Zero Substitution) used a trick already used in low speed, short-haul communications such as RS232: escapes. A run of 8 zeros is sent as a specific error: "+1 + 1 0 0 -1 -1 0 0." The circuitry on the other side would see two BPVs (Bipolar Violations) in that specific pattern and instead of flagging an error, it would spit out 00000000. DS3s do the same trick with B3ZS. (aside: DS3 = 7 DS2 = 4 DS1, or 672 phone lines on a pair of coax cables)
Let's skip back to voice for a second. Remember how you have 24 voice channels being sent in a T1? Well as described, there is no way to tell if the line is on-hook, off-hook, ringing or busy. The solution was to steal a bit from each channel every so often and use that bit to represent line state. Since you're actually pissing around with the data, it's called in-band signalling, and specifically here, robbed-bit signalling.
What the telcos did was design a new framing system that used 12 DS1 frames as it's frame. Take 12 of those 193 bit frames and ear-mark #1 and #6. Now when Frame #1 comes along you will ignore whatever the LSB was for each DS0 and instead inject an "A" bit. And when #6 comes along you will do the same but inject a "B" bit. This big frame (12 DS1 frames) became known as the Super Frame.
What a normal DS1 frame looks like: (F = frame, A = A bit, B = B bit, 0-7 = PCM-coded voice traffic)
And for DS1 Frame #1:DS1 Frame #6:See how each channel gets an A and B bit?
What they did with the A and B bits was inject line state. 2 bits = 4 states. Now the CO can give you a busy signal or a ringback tone.
The telcos didn't stop there; they went on to give us the Extended Super Frame -- 24 DS1 Frames where every 6th frame has the LSB of the DS0s robbed to give you A, B, C and D bits. Most implementations just have the C and D bits mirror the A and B bits for now, but now you have 16 states to describe each channel in a DS1. This type of in-band signalling is known as robbed-bit signalling and is the reason you're at 56kbps for dialup. The modems actually do try and sync up to the DS1 framing and detect the robbed bit signalling when they trainup but really it's not going to get you much more speed to try and code at 64kbps 5/6th of the time and 56kbps 1/6th of the time. This robbed-bit signalling is only used on POTS; in data it's unnecessary because with ISDN your control info is in a separate D channel and for channelized-T1 it's not necessary.
I always feel like I'm talking about wrestling when I talk about SupaFrames and Extended SupaFrames :-)
Voice is always channelized; there are discrete conversations that have nothing to do with each other jammed together and transmitted as a group. Data T1s can come in channelized and unchannelized varieties. Basically it is used to group voice and data on a single T1, or, like voice, to group unrelated data communications together in an aggregate link for more efficient transmission.
Say you have a T1 between two offices and you want a 128bps link too. Well each DS0 is 64k, right? So they can take two DS0s and "split them off" for data, passing the other 22 for voice calls between the PBXes or KSUs or whatnot. Or if you want two 256k data links to two different areas; it can be done with one physical T1 to the CO, and then two from there to the locations. That's all that channelizing is about; aggregating datastreams into one connection.
Oh yes, ISDN. You'll recall that ISDN BRI is 64kbps. Guess what? An ISDN B channel is just one DS0, with the signalling occupying part of a 4kbps D channel. You can get fancy with something called Non-Facillity Associated Signalling which lets you cluster up to 8 DS1s' worth of D channels into a single B channel; That's right, with the right equipment termination you can combine up to 191 B channel control signalling into a single 64kbps D channel. (I don't think it's called a D channel anymore but I'm not sure on this.) -- dialup ISPs use it to try and regain lines when using PRIs, since a normal ISDN PRI is 23 B channels and a D channel (i.e. you lose a DS0 to signalling).
I briefly mentioned DS2s and DS3s. A DS2 is just an aggregation of 4 DS1s. The data bandwidth is not exactly 4*1.536mbps (frame is stripped out) because there are some slop bits set aside because the individual T1s coming in will not be synchronized and the slop bits take care fo that. It's the same with DS3s, which are made up of 7 DS2s. Not really exciting, because all the work was done at the DS0/DS1 level. :-)
Electrically, a DS1 is usually sent as an HDSL circuit these days; there really aren't any T1s to speak of anymore. DS = Data Specification (IIRC), where a T1 is just a DS1 with the electrical spec glued to it. Normally you have -130VDC on the line (supplied by the CO end) and the remote end (and any repeaters) get their power from the line. Pretty nifty. You can go up to 650 feet without powering the circuit if I remember correctly; unpowered DS1s are usually refered to as DSX1s.
Troubleshooting-wise you don't run into much these days. The CPE and CO ends almost always have serial ports and you snap on a laptop and ask it what's wrong or set up loopbacks and so on. The old days of having one end in a hot location and the other in shade and having that cause temp-related sync issues are long past.
So, there's almost everything you need to know about T1s. No need to buy a book that goes into the same detail. :-)
Re:Interresting review... (Score:3, Informative)
There's actually no(real) limit on how many DS1s are attached to a signalling channel short of logical size. I think it's a byte-wide field.
(I don't think it's called a D channel anymore but I'm not sure on this.)
At that point it's called an H channel, but I've never met someone that called it that.
I briefly mentioned DS2s and DS3s. A DS2 is just an aggregation of 4 DS1s. The data bandwidth is not exactly 4*1.536mbps (frame is stripped out)
A DS2 has it's own framing, although you'd be lucky to find someone in telco that knows how it works.
because there are some slop bits set aside because the individual T1s coming in will not be synchronized and the slop bits take care fo that.
I'm not really sure what you mean by this. Clock is regenerated by the remote end points of a DS3. There is no clock information carried through the circuit at the DS1 level.
It's the same with DS3s, which are made up of 7 DS2s. Not really exciting, because all the work was done at the DS0/DS1 level.
No, a DS3 is a completely different beast, with its own framing,coding, and timing rules.
Electrically, a DS1 is usually sent as an HDSL circuit these days; there really aren't any T1s to speak of anymore. DS = Data Specification (IIRC), where a T1 is just a DS1 with the electrical spec glued to it.
To clarify: T1 is the spec for transmitting a DS1 over copper in the US. HDSL is commonly use to emulate T1.
Normally you have -130VDC on the line (supplied by the CO end)
Um, no. Voltage supplied at the CO is completely determined by how many repeaters are on the line. You should end up with something like 12 volts at the CPE. -130VDc at the CPE would burn up just about anything you put on it, and would definately screw up a sinsitive test set.
So, there's almost everything you need to know about T1s. No need to buy a book that goes into the same detail.
Close. Here's what you _really_ need to know: The guy at the telco almost certainly does NOT know how this stuff _really_ works. I've had to explain alarm codes to more than one "senior engineer". DON'T let him get off the phone. If he doesn't have a test set, hold on the phone until he does. Escalation is your friend.
Re:Interresting review... (Score:3, Informative)
I'm not really sure what you mean by this. Clock is regenerated by the remote end points of a DS3. There is no clock information carried through the circuit at the DS1 level.
You're right, they're re-clocked. I had to review the DS3 aggregation notes from Cisco. It's DS3s which have the slop bits, I don't think DS2s do this (they re-time the DS1s) -- I've never really worked with an actual DS2 so I don't know for absolute sure.
No, a DS3 is a completely different beast, with its own framing,coding, and timing rules.
That's what I was getting at; the DS3s (well the ones which are used to aggregate anyway) have all kinds of funky things going on inside but none of it is really all that interesting (at least not to me).
Um, no. Voltage supplied at the CO is completely determined by how many repeaters are on the line. You should end up with something like 12 volts at the CPE. -130VDc at the CPE would burn up just about anything you put on it, and would definately screw up a sinsitive test set.
This is incorrect. I just measured across the HDSL circuit here. -126VDC, no repeaters that I know of (3km circuit). Circuits in parallel (essentially what we have here) have equal voltage across them. Having to engineer the voltage for every circuit would be a royal pain in the ass. Actually for fun, take your HDSL CPE end, and take a good autotransformer and diode bridge. Connect the diode bridge + and - to T and R (polarity doesn't matter) -- now slowly bring up the autotransformer. The CPE end won't even light up until around 85V or so.
The guy at the telco almost certainly does NOT know how this stuff _really_ works. I've had to explain alarm codes to more than one "senior engineer". DON'T let him get off the phone. If he doesn't have a test set, hold on the phone until he does. Escalation is your friend.
haha, yes you are very correct here. Find someone and find some way to get their pager, cell and office numbers. And hold on to them because a good tech is very hard to find.
Re:Interresting review... (Score:2)
That's odd. Perhaps HDSL runs differently, but the references say that a T1 should run at 2.7-3.3v, from AT&T publication 43801.
Consider that most COs run on -48v. To get 130v, they need to multiply voltage 2.7083 times. To get -3v(avg of 2.6-3.3), divide -48v by 16.
Re:Interresting review... (Score:1)
Re:Interresting review... (Score:4, Informative)
The higher voltages is how it gets through all of the distance.
Incorrect; the voltage is only used to power repeaters and the CPE; the actual data transmission is done with low-voltage signals. If you increase the voltage swing or push more current, you end up increasing crosstalk and that brings you bigger troubles, which is why they use repeaters in the first place. It's the use of repeaters which give you the incredible distances that T1/E1 circuits can span, and the repeaters rely on the static -130VDC on the line.
Fibre-optic transocean lines do the same thing. You don't want to cut through a long-haul fibre line because they have thousands of volts across a couple of their internal metal layers to provide power for the ocean-floor optical repeaters.
While most repeaters take the -130V provided across the T/R and generate their own internal power supplies from it, some types of repeaters will take a -48VDC power source and regenerate the -130VDC for the next 50km or so, just as the CO-end equipment does. The -130VDC is current-limited (you're running on thin wire remember) and as such it just doesn't go all that terribly far. Powered circuits are only there to make life easy in remote locations (you don't need power handy), not to make the signal stronger. That's what regeneration and repeaters are all about.
Re:Interresting review... (Score:2)
That's odd. Perhaps HDSL runs differently, but the references say that a T1 should run at 2.7-3.3v, from AT&T publication 43801.
That sounds like a DSX1 spec; is that publication online? A quick google check find shitloads of references to it. :-(
You have a reply from djweis which says it's the voltage that cuts through the distance; this is untrue. The voltage is only used to power repeaters and the CPE; the actual data transmission is done with low-voltage signals. If you increase the voltage swing or push more current, you end up increasing crosstalk and that brings you bigger troubles, which is why they use repeaters in the first place.
Consider SDSL; not powered, and the range is similar to a standard HDSL2 circuit -- with HDSL(2), you can add repeaters since the line is powered; I can't do that with my SDSL circuits. It's a simple cost/distance tradeoff.
Consider that most COs run on -48v. To get 130v, they need to multiply voltage 2.7083 times. To get -3v(avg of 2.6-3.3), divide -48v by 16.
The electronic specs are not derived by easy to multiply/divide ratios like most things in the computer industry. The -130VDC is generated by the CO equipment using a simple boost regulator, which in turn runs off of the -48VDC float-charged lead-acid batteries you mention. I can create a 3.3V regulator or a 3.45V regulator with any input voltage; the real world is analog, which is why I love analog electronics design. :-)
Re:Interresting review... (Score:2)
I suspect that you are talking about two different things. The voltage you cite is probably the magnitude of the data signals, either peak-to-peak or RMS. The -130V previously cited is a DC voltage superimposed on the line.
130VDC is also used to operate the coin relay on 1A pay phones. I don't know what initially got this voltage into central offices, but it has several roles.
Further Explanations (Score:1)
Re:Further Explanations (Score:1)
As some previous posters mentioned, them most important thing to know about T1 is that telco doesn't usually know what they are talking about, so you have to call them on mistakes they make and inaccuracies they purport. In order to do this, you have to know what you are talking about, and understand the point of view from which telco sees your service. Telco knows NOTHING about WAN protocols, nor should they (unless you subscribe to some higher layer service, such as public frame relay).
Any other resources? (Score:1)
I spent the majority of my day yesterday babysitting a T-BERT. We're having a mysterious problem with a voice T1 that has channels drop off occasionally. All the vendors are pointing fingers at each other.
Anyone happen to know any other good resources for troubleshooting T1's? The Cisco link above looks interesting.
Re:Any other resources? (Score:1, Interesting)
It'll be the Telco in almost all cases, unless you're running you're own T1 net on your own equipment.
In which case YOU misconfigured the channel insert/drop assignments and are responsible for fixing it.
If you're an unfortunate SOB who oversold your technical expertise, you're in for a monumental ass drubbing for not being able to support a technology you claimed to know.
T1 is simple, drop and insert MUX's are simple, the line coding and framing is simple.
It's all consistent to end.
Re:Any other resources? (Score:1)
Surviving the First Terminator? (Score:3, Funny)
Oh, you mean *that* T1.
Re:Surviving the First Terminator? (Score:1)
Of course the book is better written... (Score:1, Flamebait)
Re:Of course the book is better written... (Score:1)
Why people have trouble with T1 (Score:3, Informative)
As for test equipment, what test equipment do you want information for? There are several test boxes just in the T-bird family, and each one has a different setup. It would make the book rediculously large to cover them all, and then people would bitch because it didn't cover digital lightwave test equipment, etc.
Re:Why people have trouble with T1 (Score:1)
Let him know. (Score:1, Insightful)
Re:Let him know. (Score:1)
T1's and testing (Score:2, Informative)
the technology has been around since the 1960's and
that Telco personnel STILL don't know how it works.
It can still take a traditional telco six months to
install a line, and more than a year to get it working correctly.
For testing, I recommend having/using a T-Berd and
a Sage. The T-berd is what the Telco techs use, so
you can test with them, end-to-end, using compatible devices.
They won't acknowledge the validity of any any other device, and blame "your equipment".
The Sage will give you more information about obscure timing glitches, gather stats, and has a wide variety of tests. Running a test with a high
concentration of zeros will show noise glitches
on the line; running lots of ones will stress the repeaters and power supplies. Make sure your test
pattern does not violate the framing rules for your
circuit-you can't run all zeroes on a non-B8ZS circuit, it looks like a dead line!
Make sure you have a jack panel at the circuit end so you have a way of inserting and dropping out of
the circuit. Wire the jack panel so you can plug in
"looking in" both directions. Have a "copper loop" for testing; when the Telco blames your equipment, tell them you HAVE NO equipment, just a T-berd on one end, and a copper loop on the other, so the problem is THEIRS to fix.
I have a very good, proprietary, in-house textbook on T-1s which was originally published internally by New England Telephone (now Verizon). The lady that wrote it was excellent--she was so good at her job, they did the only reasonable thing they could--they FIRED her. I don't know how you can
get a copy, mine is STOLEN--but it has six chapters, labelled "T1 Fundamentals", "Station Equipment", "CO equipment", "Circuit Testing", "ANSI testing", and "Tech Talks". No front cover or publication#. Mine is not for sale.
If you call the Telco for service, and get a knowledgable tech (this is RARE), get him coffee and donuts and pump him for information. It may be
the only way to learn what you need. Be aware that Telco personnel use their own internal jargon
that bears no relationship to anything else in electronics--you will need to listen carefully, then translate the "telco--ese" into english.
Good luck with your T1's, and keep praying for a
better source of broadband than the phone company.
After all, they are the ones who have been PREVENTING communication for over 100 years....
T1 Info (Score:3, Informative)
There's a good bit of info on T1 lines in some of the professional level cisco cert study guides... also, here's an interesting paper on everything you wanted to know about T1, but were afraid to ask [dcbnet.com].
Provisioning is what we need to know (Score:1)
A friend of mine is getting a DSX "presentation" over DSL, and it was sold to him as a T1. This is out and out fraud, but he doesn't know what to do about it.
I know rules and regs and tarriffs vary from state to state, but a book written by a few people could expose the gotchas that have bittin me in the ass in dealing with T1/PRI.
Re:Provisioning is what we need to know (Score:2)
Deal with it, and save the telco bashing for things that really matter.
Re:Provisioning is what we need to know (Score:2, Interesting)
Re:Provisioning is what we need to know (Score:2)
Re:Provisioning is what we need to know (Score:1)
Another thing - if a pair or two go bad on a T1, or someone nicks it with a backhoe, you still have a good change of some throughput, right? Sure, you'll get errors, but you're not necessarily dead in the water. Can you explain how the redundancy of multiple pairs is duplicated by HDSL?
Re:Provisioning is what we need to know (Score:2)
Of course, after I got that all figured out I started with international circuits...
sPh
Re:Provisioning is what we need to know (Score:1)
And a few years ago ISDN was a nightmare in nynex land. I doubt it has improved any.