Re: DS3 bandwidth issues [7:65790]
At 8:30 AM + 3/20/03, Nate wrote: thanks guys. I knew I could count on such bright and light-hearted people. Just for completeness, the Microsoft solution is to increase the speed of darkness. Nortel's is complex. There were times I thought the approach was to increase entropy, but one must remember that I was seeing it from the perspective of the corporate research lab. I think the real approach was to increase the density of management until the passage, at any speed, of useful information was impossible and thus transfer rates unaffected by subsequent changes in the environment. - Original Message - From: Priscilla Oppenheimer To: Sent: Wednesday, March 19, 2003 6:19 PM Subject: Re: DS3 bandwidth issues [7:65790] Or he could do the file transfer to a server that is sitting on the edge of a Black Hole! :-) Darrell Newcomb wrote: Increase the speed of light. By increasing the speed of light you will increase the speed of your file transfer. Ask management to fund advanced research into light accelerators, then wait to do your transfers after light has been speed up by a few orders of magnitude. (This works best for non-technical folks) or Use the turbo switch on the back of the router labeled - / oor... Pull fiber directly from A to B Help out the economy and network staff. Buy a backhoe, some explosives, and a fiber splice hit. Start at location A, use gps to plot a direct path to B(as the crow flys), point the tractor in the precise direction and do not deviate. Remove any buildings, reroute roads, destroy gardens, but keep driving in a straight line. Don't bother with regen, just stay the course. (Works good for technical staff who don't yet get it) ..OR.. Nate wrote in message news:[EMAIL PROTECTED] We've run a bandwidth test on our DS3 with nothing connected to it but a workstation (and obviously a router/pix). We went to testmyspeed.com as well as dslreports.com. We both got very good bandwidth tests (upward 6m/s) however in transferring a 200m file to/from a workstation behind the connection, we got over 30 minutes while our existing T1 got 26 minutes. Anyone mind explaining this phenomenon? Just a side note, we have no encryption between GRE tunnels. Thanks in advanced. -Nate .. Tune your tcp stack on the send side. http://www.psc.edu/networking/perf_tune.html http://www-iepm.slac.stanford.edu/monitoring/bulk/fast/ Or maybe you have a real life problem or capacity shortage somewhere. Good Luck, Darrell Always looking for the next big project... As in increasing the speed of light? :-) Priscilla darrell (at) hayaitacos net Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=65909t=65790 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: DS3 bandwidth issues [7:65790]
Wow Thank you sooo much. This is the best explanation of T-carrier Vs. Dx-Carrier I've ever read. I work in the IT field for some time, but not to much in the telco side and I could never really find what the difference was. THANKS A TON Steve Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=65922t=65790 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: DS3 bandwidth issues [7:65790]
Darrell, I guess you're right about the T1. Assuming that only about 1 mbps of true throughput is achieved, 26 minutes is easily within the realm of possibility. I just downloaded a 4MB file over a T1 (and it's shared by quite a number of folks). It took 31 seconds. Extrapolating, 200MB / 4MB = 50 x 31 sec = 1550 sec / 60 = ~26 min. Huh! Checking that math, 200MB = 208,715,200 bytes = 1,677,721,600 bits / 1 mbps = ~1678 seconds / 60 = ~28 minutes. Huh! Tuning the TCP stack is always a good idea. However, assuming your example of 80ms RTT, here's where you should start having problems: throughput = window size / RTT throughput = ?? standard Microsoft window size = 65,536 bytes or 524,288 bits RTT = 80ms or .08 sec 524,288 / .08 = 6,553,600 So up to ~6.5 mbps (w/ 80ms RTT), TCP flow control probably isn't an issue. I think that's what you were saying. But, as we all agree, that sucks for a T3. Further indication that there's a bottleneck somewhere beyond the immediate connectivity... Darrell Newcomb wrote: Priscilla Oppenheimer wrote in message news:[EMAIL PROTECTED] s vermill wrote: Nate wrote: We've run a bandwidth test on our DS3 with nothing connected to it but a workstation (and obviously a router/pix). We went to testmyspeed.com as well as dslreports.com. We both got very good bandwidth tests (upward 6m/s) however in transferring a 200m file to/from a workstation behind the connection, we got over 30 minutes while our existing T1 got 26 minutes. Anyone mind explaining this phenomenon? Just a side note, we have no encryption between GRE tunnels. Thanks in advanced. Since he said he tested with those other tools and got 6m/sec (I guess he meant 6 megabits per second which is OK, thought not great), the file The above is what I key'ed in on as the last test transfer he had done over the new path. Which is why I had originally suggested to tune tcp(the URL's below the jokes were seen weren't they?) since a single tcp session at 6Mbps crossing the continent(country) could be within expectations. In most stock tcp's and a 80ms RTT he would need a packet loss rate near .02%(.0002) to get 6Mbps. Nothing unrealistic about those numbers and it seemed to me someone just wanted to see 40+ Mbps numbers. But I overlooked the part about 30minutes over the DS3. Regarding the concerns about the 26 minute T1 transer. Maybe I'm a little too sleep deprived from doing datacenter moves, but I don't see the issue with 26minutes for a 200MB(bytes) file is roughly 1Mbps, don't forget overhead too. That's completely within norm for a single TCP session between two reasonably distant endpoints bandlimited by a T1. Back to the DS3 being slower for this one. As everyone has been saying break down the problem. My guess would be you've got some major performance inhibiting thing like a duplex mismatch somewhere and by being able to ramp up transmit speeds quicker the session is smacked back down due to the loss(from duplex mismatch). What might be the simpliest suggestion for testing is to start up the file transfer and while it's running do a traceroute(large packet size if you could) from one end-host to the far end and see if you notice a place of particularly high loss to go look at. My appologies for overlooking the note about 30minute 200MB transfer over DS3(not T1), Darrell Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=65935t=65790 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: DS3 bandwidth issues [7:65790]
wow thanks for all the responses everyone! I learn something new everyday on this board. scott [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Being in the CLEC business I can tell you that we typically refer to T3 when discussing Transport only type ciruits of 45Mbps from point to point. When we refer to putting services on it, such as Frame Relay, ATM, PPP, voice (PRI, Trunks, etc) then we usually refer to them as DS3. However, they are certainly used interchangibly by most. A T1 or T3 is a Carrier as explained below: To see the relationship between T-carrier, E-carrier, and DS0 multiples, see digital signal X. The T-carrier system, introduced by the Bell System in the U.S. in the 1960s, was the first successful system that supported digitized voice transmission. The original transmission rate (1.544 Mbps) in the T-1 line is in common use today in Internet service provider (ISP) connections to the Internet. Another level, the T-3 line, providing 44.736 Mbps, is also commonly used by Internet service providers. Another commonly installed service is a fractional T-1, which is the rental of some portion of the 24 channels in a T-1 line, with the other channels going unused. The T-carrier system is entirely digital, using pulse code modulation and time-division multiplexing. The system uses four wires and provides duplex capability (two wires for receiving and two for sending at the same time). The T-1 digital stream consists of 24 64-Kbps channels that are multiplexed. (The standardized 64 Kbps channel is based on the bandwidth required for a voice conversation.) The four wires were originally a pair of twisted pair copper wires, but can now also include coaxial cable, optical fiber, digital microwave, and other media. A number of variations on the number and use of channels are possible. In the T-1 system, voice signals are sampled 8,000 times a second and each sample is digitized into an 8-bit word. With 24 channels being digitized at the same time, a 192-bit frame (24 channels each with an 8-bit word) is thus being transmitted 8,000 times a second. Each frame is separated from the next by a single bit, making a 193-bit block. The 192 bit frame multiplied by 8,000 and the additional 8,000 framing bits make up the T-1's 1.544 Mbps data rate. The signaling bits are the least significant bits in each frame. A DS0/1/3 is a Digital signal carried by the T carrier as explained below: Digital signal X is a term for the series of standard digital transmission rates or levels based on DS0, a transmission rate of 64 Kbps, the bandwidth normally used for one telephone voice channel. Both the North American T-carrier system system and the European E-carrier systems of transmission operate using the DS series as a base multiple. The digital signal is what is carried inside the carrier system. DS0 is the base for the digital signal X series. DS1, used as the signal in the T-1 carrier, is 24 DS0 (64 Kbps) signals transmitted using pulse-code modulation (PCM) and time-division multiplexing (TDM). DS2 is four DS1 signals multiplexed together to produce a rate of 6.312 Mbps. DS3, the signal in the T-3 carrier, carries a multiple of 28 DS1 signals or 672 DS0s or 44.736 Mbps. Digital signal X is based on the ANSI T1.107 guidelines. The ITU-TS guidelines differ somewhat. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of MADMAN Sent: Thursday, March 20, 2003 4:32 PM To: [EMAIL PROTECTED] Subject: Re: DS3 bandwidth issues [7:65790] six of one half dozen of the other, they both describe the same thing. I think T is a Bellcore name and DS is a some standards body name. Dave Scott Roberts wrote: why do people refer to a DS3 as a DS3 and not a T3? is there something I'm missing? scott Nate wrote in message news:[EMAIL PROTECTED] We've run a bandwidth test on our DS3 with nothing connected to it but a workstation (and obviously a router/pix). We went to testmyspeed.com as well as dslreports.com. We both got very good bandwidth tests (upward 6m/s) however in transferring a 200m file to/from a workstation behind the connection, we got over 30 minutes while our existing T1 got 26 minutes. Anyone mind explaining this phenomenon? Just a side note, we have no encryption between GRE tunnels. Thanks in advanced. -Nate -- David Madland CCIE# 2016 Sr. Network Engineer Qwest Communications 612-664-3367 I would rather have a German division in front of me than a French one behind me. --- General George S. Patton Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=65941t=65790 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: DS3 bandwidth issues [7:65790]
thanks guys. I knew I could count on such bright and light-hearted people. - Original Message - From: Priscilla Oppenheimer To: Sent: Wednesday, March 19, 2003 6:19 PM Subject: Re: DS3 bandwidth issues [7:65790] Or he could do the file transfer to a server that is sitting on the edge of a Black Hole! :-) Darrell Newcomb wrote: Increase the speed of light. By increasing the speed of light you will increase the speed of your file transfer. Ask management to fund advanced research into light accelerators, then wait to do your transfers after light has been speed up by a few orders of magnitude. (This works best for non-technical folks) or Use the turbo switch on the back of the router labeled - / oor... Pull fiber directly from A to B Help out the economy and network staff. Buy a backhoe, some explosives, and a fiber splice hit. Start at location A, use gps to plot a direct path to B(as the crow flys), point the tractor in the precise direction and do not deviate. Remove any buildings, reroute roads, destroy gardens, but keep driving in a straight line. Don't bother with regen, just stay the course. (Works good for technical staff who don't yet get it) ..OR.. Nate wrote in message news:[EMAIL PROTECTED] We've run a bandwidth test on our DS3 with nothing connected to it but a workstation (and obviously a router/pix). We went to testmyspeed.com as well as dslreports.com. We both got very good bandwidth tests (upward 6m/s) however in transferring a 200m file to/from a workstation behind the connection, we got over 30 minutes while our existing T1 got 26 minutes. Anyone mind explaining this phenomenon? Just a side note, we have no encryption between GRE tunnels. Thanks in advanced. -Nate .. Tune your tcp stack on the send side. http://www.psc.edu/networking/perf_tune.html http://www-iepm.slac.stanford.edu/monitoring/bulk/fast/ Or maybe you have a real life problem or capacity shortage somewhere. Good Luck, Darrell Always looking for the next big project... As in increasing the speed of light? :-) Priscilla darrell (at) hayaitacos net Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=65814t=65790 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: DS3 bandwidth issues [7:65790]
Who is the T1 provider? Who is the DS3 provider? Is it a full DS3 or frac? What router do you have? Could it be configuration? Could it be that you bought a DS3 from a provider with either a lousy network? Or maybe just bad peering/transit with the place you are attempting to download from? A DS3 is not a DS3! Consider if your provider of the DS3 only has an OC3 network for you to use and has it oversubscribed 4:1? Would that work well? What do GRE tunnels have to do with anything? Describe the network. Give more details and a better explaination may come. Tom -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Darrell Newcomb Sent: Wednesday, March 19, 2003 8:31 PM To: [EMAIL PROTECTED] Subject: Re: DS3 bandwidth issues [7:65790] Increase the speed of light. By increasing the speed of light you will increase the speed of your file transfer. Ask management to fund advanced research into light accelerators, then wait to do your transfers after light has been speed up by a few orders of magnitude. (This works best for non-technical folks) or Use the turbo switch on the back of the router labeled - / oor... Pull fiber directly from A to B Help out the economy and network staff. Buy a backhoe, some explosives, and a fiber splice hit. Start at location A, use gps to plot a direct path to B(as the crow flys), point the tractor in the precise direction and do not deviate. Remove any buildings, reroute roads, destroy gardens, but keep driving in a straight line. Don't bother with regen, just stay the course. (Works good for technical staff who don't yet get it) .OR.. Nate wrote in message news:[EMAIL PROTECTED] We've run a bandwidth test on our DS3 with nothing connected to it but a workstation (and obviously a router/pix). We went to testmyspeed.com as well as dslreports.com. We both got very good bandwidth tests (upward 6m/s) however in transferring a 200m file to/from a workstation behind the connection, we got over 30 minutes while our existing T1 got 26 minutes. Anyone mind explaining this phenomenon? Just a side note, we have no encryption between GRE tunnels. Thanks in advanced. -Nate . Tune your tcp stack on the send side. http://www.psc.edu/networking/perf_tune.html http://www-iepm.slac.stanford.edu/monitoring/bulk/fast/ Or maybe you have a real life problem or capacity shortage somewhere. Good Luck, Darrell Always looking for the next big project... darrell (at) hayaitacos net Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=65804t=65790 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: DS3 bandwidth issues [7:65790]
why do people refer to a DS3 as a DS3 and not a T3? is there something I'm missing? scott Nate wrote in message news:[EMAIL PROTECTED] We've run a bandwidth test on our DS3 with nothing connected to it but a workstation (and obviously a router/pix). We went to testmyspeed.com as well as dslreports.com. We both got very good bandwidth tests (upward 6m/s) however in transferring a 200m file to/from a workstation behind the connection, we got over 30 minutes while our existing T1 got 26 minutes. Anyone mind explaining this phenomenon? Just a side note, we have no encryption between GRE tunnels. Thanks in advanced. -Nate Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=65864t=65790 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: DS3 bandwidth issues [7:65790]
Nate wrote: We've run a bandwidth test on our DS3 with nothing connected to it but a workstation (and obviously a router/pix). We went to testmyspeed.com as well as dslreports.com. We both got very good bandwidth tests (upward 6m/s) however in transferring a 200m file to/from a workstation behind the connection, we got over 30 minutes while our existing T1 got 26 minutes. Anyone mind explaining this phenomenon? Just a side note, we have no encryption between GRE tunnels. Thanks in advanced. -Nate Nate, A few rambling thoughts in addition to those already offered: Where is this 200MB file? On a lightning-fast server on a lightning-fast LAN connected to a lightning-fast router with a lightning fast connection to the Internet? In other words, is the file location the bottleneck? Because 26 minutes on even a T1 is TERRIBLE. Also, the download test sites don't do file tranfer using FTP in general. They establish an HTTP/TCP/IP session and dump a BUNCH of random text. So the control mechanisms are different between the test and the real world file transfer. Perhaps more rambling thoughts later... Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=65865t=65790 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: DS3 bandwidth issues [7:65790]
Scott Roberts wrote: why do people refer to a DS3 as a DS3 and not a T3? is there something I'm missing? It's a bit esoteric. I'm working on something that will help clarify. In short, a DS3 is a frame structure (28 T1s plus 1.504 mbps overhead, all interleaved in a certain way, etc, etc). A T3 is an actual interface (certain peak-to-peak voltage, certain impedance, etc). It's rare that you would ever get your hands on an actual DS3 because that is created by, say, a T3 mux. T1s as input, DS3 frame created from those, and T3 out for further transmission. In that example, theres never a discrete DS3 out in the open - it exists only inside the mux and only briefly. To (hopefully) further clarify, you won't find a SONET box with a DS3 interface. It'll have a T3 interface. They're pretty much used interchangeably in industry though. scott Nate wrote in message news:[EMAIL PROTECTED] We've run a bandwidth test on our DS3 with nothing connected to it but a workstation (and obviously a router/pix). We went to testmyspeed.com as well as dslreports.com. We both got very good bandwidth tests (upward 6m/s) however in transferring a 200m file to/from a workstation behind the connection, we got over 30 minutes while our existing T1 got 26 minutes. Anyone mind explaining this phenomenon? Just a side note, we have no encryption between GRE tunnels. Thanks in advanced. -Nate Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=65868t=65790 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: DS3 bandwidth issues [7:65790]
I should also have added that DS is derived from digital signal while T is derived from T-Carrier. s vermill wrote: Scott Roberts wrote: why do people refer to a DS3 as a DS3 and not a T3? is there something I'm missing? It's a bit esoteric. I'm working on something that will help clarify. In short, a DS3 is a frame structure (28 T1s plus 1.504 mbps overhead, all interleaved in a certain way, etc, etc). A T3 is an actual interface (certain peak-to-peak voltage, certain impedance, etc). It's rare that you would ever get your hands on an actual DS3 because that is created by, say, a T3 mux. T1s as input, DS3 frame created from those, and T3 out for further transmission. In that example, theres never a discrete DS3 out in the open - it exists only inside the mux and only briefly. To (hopefully) further clarify, you won't find a SONET box with a DS3 interface. It'll have a T3 interface. They're pretty much used interchangeably in industry though. scott Nate wrote in message news:[EMAIL PROTECTED] We've run a bandwidth test on our DS3 with nothing connected to it but a workstation (and obviously a router/pix). We went to testmyspeed.com as well as dslreports.com. We both got very good bandwidth tests (upward 6m/s) however in transferring a 200m file to/from a workstation behind the connection, we got over 30 minutes while our existing T1 got 26 minutes. Anyone mind explaining this phenomenon? Just a side note, we have no encryption between GRE tunnels. Thanks in advanced. -Nate Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=65872t=65790 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: DS3 bandwidth issues [7:65790]
s vermill wrote: Nate wrote: We've run a bandwidth test on our DS3 with nothing connected to it but a workstation (and obviously a router/pix). We went to testmyspeed.com as well as dslreports.com. We both got very good bandwidth tests (upward 6m/s) however in transferring a 200m file to/from a workstation behind the connection, we got over 30 minutes while our existing T1 got 26 minutes. Anyone mind explaining this phenomenon? Just a side note, we have no encryption between GRE tunnels. Thanks in advanced. -Nate Nate, A few rambling thoughts in addition to those already offered: Where is this 200MB file? On a lightning-fast server on a lightning-fast LAN connected to a lightning-fast router with a lightning fast connection to the Internet? In other words, is the file location the bottleneck? Because 26 minutes on even a T1 is TERRIBLE. That's a good point. I wondered why the transfer was taking 26 minutes also. Since he said he tested with those other tools and got 6m/sec (I guess he meant 6 megabits per second which is OK, thought not great), the file transfer speed is probably due to a really slow server or maybe a slow client. We may be able to rule out the router and firewall since they were in the picture for the other tests too. However, they might be relevant since they were undoubtedly applying different rules when doing the file transfer versus the other tests. With a sniffer you can often tell where the bottleneck resides. Or maybe it will be obvious because he'll tell us that the server or client is a 286 sitting on dial-up home network. Just kidding. He should do some more tests and if he wants our help, give us more info. What is the server? What is its OS? Was it FTP he was using? What about the client? What is the config on the router and firewall? What else has he not told us about NAT, VPN, tunnels, etc.? What variables were different for the one test versus the other? Priscilla Also, the download test sites don't do file tranfer using FTP in general. They establish an HTTP/TCP/IP session and dump a BUNCH of random text. So the control mechanisms are different between the test and the real world file transfer. Perhaps more rambling thoughts later... Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=65871t=65790 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: DS3 bandwidth issues [7:65790]
six of one half dozen of the other, they both describe the same thing. I think T is a Bellcore name and DS is a some standards body name. Dave Scott Roberts wrote: why do people refer to a DS3 as a DS3 and not a T3? is there something I'm missing? scott Nate wrote in message news:[EMAIL PROTECTED] We've run a bandwidth test on our DS3 with nothing connected to it but a workstation (and obviously a router/pix). We went to testmyspeed.com as well as dslreports.com. We both got very good bandwidth tests (upward 6m/s) however in transferring a 200m file to/from a workstation behind the connection, we got over 30 minutes while our existing T1 got 26 minutes. Anyone mind explaining this phenomenon? Just a side note, we have no encryption between GRE tunnels. Thanks in advanced. -Nate -- David Madland CCIE# 2016 Sr. Network Engineer Qwest Communications 612-664-3367 I would rather have a German division in front of me than a French one behind me. --- General George S. Patton Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=65882t=65790 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: DS3 bandwidth issues [7:65790]
Being in the CLEC business I can tell you that we typically refer to T3 when discussing Transport only type ciruits of 45Mbps from point to point. When we refer to putting services on it, such as Frame Relay, ATM, PPP, voice (PRI, Trunks, etc) then we usually refer to them as DS3. However, they are certainly used interchangibly by most. A T1 or T3 is a Carrier as explained below: To see the relationship between T-carrier, E-carrier, and DS0 multiples, see digital signal X. The T-carrier system, introduced by the Bell System in the U.S. in the 1960s, was the first successful system that supported digitized voice transmission. The original transmission rate (1.544 Mbps) in the T-1 line is in common use today in Internet service provider (ISP) connections to the Internet. Another level, the T-3 line, providing 44.736 Mbps, is also commonly used by Internet service providers. Another commonly installed service is a fractional T-1, which is the rental of some portion of the 24 channels in a T-1 line, with the other channels going unused. The T-carrier system is entirely digital, using pulse code modulation and time-division multiplexing. The system uses four wires and provides duplex capability (two wires for receiving and two for sending at the same time). The T-1 digital stream consists of 24 64-Kbps channels that are multiplexed. (The standardized 64 Kbps channel is based on the bandwidth required for a voice conversation.) The four wires were originally a pair of twisted pair copper wires, but can now also include coaxial cable, optical fiber, digital microwave, and other media. A number of variations on the number and use of channels are possible. In the T-1 system, voice signals are sampled 8,000 times a second and each sample is digitized into an 8-bit word. With 24 channels being digitized at the same time, a 192-bit frame (24 channels each with an 8-bit word) is thus being transmitted 8,000 times a second. Each frame is separated from the next by a single bit, making a 193-bit block. The 192 bit frame multiplied by 8,000 and the additional 8,000 framing bits make up the T-1's 1.544 Mbps data rate. The signaling bits are the least significant bits in each frame. A DS0/1/3 is a Digital signal carried by the T carrier as explained below: Digital signal X is a term for the series of standard digital transmission rates or levels based on DS0, a transmission rate of 64 Kbps, the bandwidth normally used for one telephone voice channel. Both the North American T-carrier system system and the European E-carrier systems of transmission operate using the DS series as a base multiple. The digital signal is what is carried inside the carrier system. DS0 is the base for the digital signal X series. DS1, used as the signal in the T-1 carrier, is 24 DS0 (64 Kbps) signals transmitted using pulse-code modulation (PCM) and time-division multiplexing (TDM). DS2 is four DS1 signals multiplexed together to produce a rate of 6.312 Mbps. DS3, the signal in the T-3 carrier, carries a multiple of 28 DS1 signals or 672 DS0s or 44.736 Mbps. Digital signal X is based on the ANSI T1.107 guidelines. The ITU-TS guidelines differ somewhat. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of MADMAN Sent: Thursday, March 20, 2003 4:32 PM To: [EMAIL PROTECTED] Subject: Re: DS3 bandwidth issues [7:65790] six of one half dozen of the other, they both describe the same thing. I think T is a Bellcore name and DS is a some standards body name. Dave Scott Roberts wrote: why do people refer to a DS3 as a DS3 and not a T3? is there something I'm missing? scott Nate wrote in message news:[EMAIL PROTECTED] We've run a bandwidth test on our DS3 with nothing connected to it but a workstation (and obviously a router/pix). We went to testmyspeed.com as well as dslreports.com. We both got very good bandwidth tests (upward 6m/s) however in transferring a 200m file to/from a workstation behind the connection, we got over 30 minutes while our existing T1 got 26 minutes. Anyone mind explaining this phenomenon? Just a side note, we have no encryption between GRE tunnels. Thanks in advanced. -Nate -- David Madland CCIE# 2016 Sr. Network Engineer Qwest Communications 612-664-3367 I would rather have a German division in front of me than a French one behind me. --- General George S. Patton Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=65893t=65790 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: DS3 bandwidth issues [7:65790]
Priscilla Oppenheimer wrote in message news:[EMAIL PROTECTED] s vermill wrote: Nate wrote: We've run a bandwidth test on our DS3 with nothing connected to it but a workstation (and obviously a router/pix). We went to testmyspeed.com as well as dslreports.com. We both got very good bandwidth tests (upward 6m/s) however in transferring a 200m file to/from a workstation behind the connection, we got over 30 minutes while our existing T1 got 26 minutes. Anyone mind explaining this phenomenon? Just a side note, we have no encryption between GRE tunnels. Thanks in advanced. Since he said he tested with those other tools and got 6m/sec (I guess he meant 6 megabits per second which is OK, thought not great), the file The above is what I key'ed in on as the last test transfer he had done over the new path. Which is why I had originally suggested to tune tcp(the URL's below the jokes were seen weren't they?) since a single tcp session at 6Mbps crossing the continent(country) could be within expectations. In most stock tcp's and a 80ms RTT he would need a packet loss rate near .02%(.0002) to get 6Mbps. Nothing unrealistic about those numbers and it seemed to me someone just wanted to see 40+ Mbps numbers. But I overlooked the part about 30minutes over the DS3. Regarding the concerns about the 26 minute T1 transer. Maybe I'm a little too sleep deprived from doing datacenter moves, but I don't see the issue with 26minutes for a 200MB(bytes) file is roughly 1Mbps, don't forget overhead too. That's completely within norm for a single TCP session between two reasonably distant endpoints bandlimited by a T1. Back to the DS3 being slower for this one. As everyone has been saying break down the problem. My guess would be you've got some major performance inhibiting thing like a duplex mismatch somewhere and by being able to ramp up transmit speeds quicker the session is smacked back down due to the loss(from duplex mismatch). What might be the simpliest suggestion for testing is to start up the file transfer and while it's running do a traceroute(large packet size if you could) from one end-host to the far end and see if you notice a place of particularly high loss to go look at. My appologies for overlooking the note about 30minute 200MB transfer over DS3(not T1), Darrell Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=65895t=65790 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
DS3 bandwidth issues [7:65790]
We've run a bandwidth test on our DS3 with nothing connected to it but a workstation (and obviously a router/pix). We went to testmyspeed.com as well as dslreports.com. We both got very good bandwidth tests (upward 6m/s) however in transferring a 200m file to/from a workstation behind the connection, we got over 30 minutes while our existing T1 got 26 minutes. Anyone mind explaining this phenomenon? Just a side note, we have no encryption between GRE tunnels. Thanks in advanced. -Nate Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=65790t=65790 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: DS3 bandwidth issues [7:65790]
Increase the speed of light. By increasing the speed of light you will increase the speed of your file transfer. Ask management to fund advanced research into light accelerators, then wait to do your transfers after light has been speed up by a few orders of magnitude. (This works best for non-technical folks) or Use the turbo switch on the back of the router labeled - / oor... Pull fiber directly from A to B Help out the economy and network staff. Buy a backhoe, some explosives, and a fiber splice hit. Start at location A, use gps to plot a direct path to B(as the crow flys), point the tractor in the precise direction and do not deviate. Remove any buildings, reroute roads, destroy gardens, but keep driving in a straight line. Don't bother with regen, just stay the course. (Works good for technical staff who don't yet get it) .OR.. Nate wrote in message news:[EMAIL PROTECTED] We've run a bandwidth test on our DS3 with nothing connected to it but a workstation (and obviously a router/pix). We went to testmyspeed.com as well as dslreports.com. We both got very good bandwidth tests (upward 6m/s) however in transferring a 200m file to/from a workstation behind the connection, we got over 30 minutes while our existing T1 got 26 minutes. Anyone mind explaining this phenomenon? Just a side note, we have no encryption between GRE tunnels. Thanks in advanced. -Nate . Tune your tcp stack on the send side. http://www.psc.edu/networking/perf_tune.html http://www-iepm.slac.stanford.edu/monitoring/bulk/fast/ Or maybe you have a real life problem or capacity shortage somewhere. Good Luck, Darrell Always looking for the next big project... darrell (at) hayaitacos net Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=65796t=65790 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: DS3 bandwidth issues [7:65790]
Or he could do the file transfer to a server that is sitting on the edge of a Black Hole! :-) Darrell Newcomb wrote: Increase the speed of light. By increasing the speed of light you will increase the speed of your file transfer. Ask management to fund advanced research into light accelerators, then wait to do your transfers after light has been speed up by a few orders of magnitude. (This works best for non-technical folks) or Use the turbo switch on the back of the router labeled - / oor... Pull fiber directly from A to B Help out the economy and network staff. Buy a backhoe, some explosives, and a fiber splice hit. Start at location A, use gps to plot a direct path to B(as the crow flys), point the tractor in the precise direction and do not deviate. Remove any buildings, reroute roads, destroy gardens, but keep driving in a straight line. Don't bother with regen, just stay the course. (Works good for technical staff who don't yet get it) ..OR.. Nate wrote in message news:[EMAIL PROTECTED] We've run a bandwidth test on our DS3 with nothing connected to it but a workstation (and obviously a router/pix). We went to testmyspeed.com as well as dslreports.com. We both got very good bandwidth tests (upward 6m/s) however in transferring a 200m file to/from a workstation behind the connection, we got over 30 minutes while our existing T1 got 26 minutes. Anyone mind explaining this phenomenon? Just a side note, we have no encryption between GRE tunnels. Thanks in advanced. -Nate .. Tune your tcp stack on the send side. http://www.psc.edu/networking/perf_tune.html http://www-iepm.slac.stanford.edu/monitoring/bulk/fast/ Or maybe you have a real life problem or capacity shortage somewhere. Good Luck, Darrell Always looking for the next big project... As in increasing the speed of light? :-) Priscilla darrell (at) hayaitacos net Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=65798t=65790 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
