dav0r
translate
Premium
join:2003-06-15
Albertville, MN
 ·Charter Pipeline
 ·Embarq
| numbers and sync...
how are these numbers? really not sure, been so long since i had dsl and never had to check back then...
Upstream Speed: 448 kbps
Downstream Speed: 5888 kbps
wan adsl linedata near:
noise margin downstream: 26 db
output power upstream: 13 db
attenuation downstream: 14 db
wan adsl linedata far:
noise margin upstream: 9 db
output power downstream: 17 db
attenuation upstream: 7 db
wan adsl chandata:
DSL standard: ANSI T1.413
near-end interleaved channel bit rate: 0 kbps
near-end fast channel bit rate: 5888 kbps
far-end interleaved channel bit rate: 0 kbps
far-end fast channel bit rate: 448 kbps
Also, this is the 2nd time since I've been 'testing' DSL over the past two weeks or so that I've been knocked off my 768 sync profile. I realize that they're overprovisined at the DSLAM per my prior calls but wonder if this is just from resetting to default to login non-bridged to the modem? I don't think so as sync will come from the far end. Just not sure why it keeps getting knocked down.
I'm debating whether or not to wait until November 9th to see if things really improve before I 'stop testing' to see if I want to change. Unless it's very strong/consistent I doubt I will. It's more consistent but I know where I live determines a lot. I was told I'm 3,000 ft. from where I connect to and I know that's very close so should be okay I am thinking.
At any rate, any comments about the numbers welcome. Again this was done with default IP non-bridged and not sure if that matters at all. Thx. |
|
dav0r
translate
Premium
join:2003-06-15
Albertville, MN
·Charter Pipeline
·Embarq
| reset the modem...
Upstream Speed: 864 kbps
Downstream Speed: 5888 kbps
only other change was noise down db: 25
guess i'll wait 'til the 9th. if things stabilize may be better. really don't think my first hop will get below 16ms, however. been 17ms average really.
not sure if the upgrade in the area would change my first hop. if i'm only 3,000 not sure why it's that high i guess. will wait until after the 9th to check things and just see if the noise numbers are okay for now i'm thinking. thanks for any comments in advance. |
|
espaeth
Digital Plumber
Premium,MVM
join:2001-04-21
Minneapolis, MN
 ·voip.ms
·Vitelity VOIP
·Callcentric
·VoiceStick
·ViaTalk
·Comcast
·Embarq
| reply to dav0r
said by dav0r  :wan adsl linedata far: noise margin upstream: 9 dboutput power downstream: 17 db attenuation upstream: 7 db You start to lose sync at an upstream margin of 6 dB, so it looks like your line has to train down to maintain the connection.
-Eric |
|
dav0r
translate
Premium
join:2003-06-15
Albertville, MN
·Charter Pipeline
·Embarq
2 edits | Ah okay makes sense. Thanks. They mentioned attenuation when I spoke with them now I understand. Probably want that over 10db ideally then...
Edit... is this usually corrected at the DSLAM or at the CPE? I'm guessing I may have to open the old NID or whatever that box is outside and check for the wire changes per that FAQ.
Will probably call first to see, or I guess I could plug in to the test port outside maybe... need to research.
near-end interleaved channel bit rate: 0 kbps
near-end fast channel bit rate: 5888 kbps
far-end interleaved channel bit rate: 0 kbps
far-end fast channel bit rate: 864 kbps
//seems to have a problem keeping that... |
|
Soldae
@comcast.net
| reply to dav0r
ACtually, the lower the attenuation the better. However, the noise margin should be above 9. Embarq used to use 6 as a cutoff point, but now they've found that having that guideline was causing a lot of multiple dispatches. So they've risen it to 9. If your modem is on for a bit and the noise margin goes to 9, it usually means there is some sort of interference building on your line. Make sure your filters (if you're not splittered) are on everything that goes into a phone jack.
Maybe even unplug everything except your modem, and see how it works after a bit of time. If the noise margin stays where it should, you have a filter causing the problem. Otherwise, I would call Embarq when the noise margin is around 9, see if you're on a DSLAM that they can see the errors building. Otherwise, I'd request a tech out there to take a looksie at your line.
Also, you're profile isn't changing, the modem is syncing up at the rate it's able to at that time, and if it's not syncing at the full rate, then you definitely have an issue. |
|
dav0r
translate
Premium
join:2003-06-15
Albertville, MN
·Charter Pipeline
·Embarq
| Good info thank you. Yeah it's been 10 twice but most of the time it's 9 for the noise. I don't use pots lines or anything else that plugs in to the wall. The modem is the only thing using that infrastructure. It's a new building but I believe that the wires do split upstairs... not sure if that matters. I don't know a lot about base-level hardware for telephony. (wiring/boxes/etc.) I'll just call Embarq and say "Hey it's 9, can I do anything to get to 10 or above on a regular basis?" They've been nothing but very helpful when I call in which has been awesome. ISP stress is for the birds. But yes it did it today again, first boot synced at 480, then reset it and got 864 which appears to be the max sync and sounds right with loss/overhead in mind for 768. Thanks again, very helpful. |
|
ace1974
join:2007-06-09
Goldsboro, NC | reply to dav0r
yeah 9 is too high of a noise margin,, at that level your going to be seeing a lot of random drop syncs..I typically like to see it around 11 or more.. |
|
dav0r
translate
Premium
join:2003-06-15
Albertville, MN
·Charter Pipeline
·Embarq
| 
ouchies... |
output power downstream: 17 db
attenuation upstream: 7 db
tone 0- 31: 00 00 00 06 78 9a aa aa aa ab bb bb bb aa a9 87
tone 32- 63: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
tone 64- 95: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
tone 96-127: 00 2e 2f 1f 30 30 31 30 31 31 41 41 41 41 41 40
tone 128-159: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
tone 160-191: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
tone 192-223: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
tone 224-255: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
tone 256-287: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
tone 288-319: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
tone 320-351: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
tone 352-383: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
tone 384-415: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
tone 416-447: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
tone 448-479: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
tone 480-511: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Doesn't seem to drop but will resync at a lower rate from time to time on a power cycle. It's holding, however. Think I'll just wait to see what the supposed upgrade brings on/around Nov. 9th.
My only issues with the line is the fluctuating upstream sync/noise and the first hop being 16-18ms. Would rather have that below 10ms but not sure if that'll be possible with the current config; don't know 'where' I'm actually connecting to but I would think that if I'm 3,000ft and it's not more than 100 miles away should be under 10ms/avg.
The peering seems a little flakey too but that was said to change. Here is a sample of how flakey things can be. In order to change off of cable I'd want my TCP ping to chi.speakeasy.net to hang around 22ms max. Cable averages about that and bottoms out around 18ms. Congestion at hop 3 and my first hop are the biggest probs ATM, however. If it gets stable won't mind losing the 10.0/1.0 for 5.0/768. Stability/latency is job one. |
|
espaeth
Digital Plumber
Premium,MVM
join:2001-04-21
Minneapolis, MN
·voip.ms
·Vitelity VOIP
·Callcentric
·VoiceStick
·ViaTalk
·Comcast
·Embarq
| Ok.. Let's tackle these things one at a time.
First off, the 9dB noise margin on the upstream. This value is derived from the raw signal to noise ratio on the line. This is most greatly affected by distance from the DSLAM and the conditioned quality of the line. You could be 3,000 ft from the CO but if you have numerous bridge taps on the line and thinner than standard gauge copper wire in the path your signal will degrade much faster than a normal span. The only thing that's going to improve that number is if you get jumpered onto a copper pair with better conditioning (both on the telco cable plant and the internal wiring at your residence), or they move the DSLAM closer to you.
Second, let go of focusing on your first hop latency. It's completely unimportant to anything you are looking to do. Your first hop doesn't run a game server, doesn't serve up web content, doesn't serve up files, and doesn't act as a VoIP gateway. If you want to make a decision based on latency, measure it against the places that actually contain the content you wish to use. Take a look at the following:
By your first hop latency logic, cable should be better than DSL because I have a first hop latency of 6ms vs 16ms on DSL. Notice however that end-to-end path latency is 7-10ms better on DSL vs cable.
Thirdly, peering instability is a term that's used to describe frequent route changes and frequent BGP peering transitions. From what you said in the other thread, this isn't what you are describing. As I understand it, your issue is with jitter/latency variance in traceroute results. That's not a good thing to focus on either, and that can be best explained by drawing an analogy to how the US Postal service works. If you're not familiar with automatic sorting machines, have a look at this: »video.google.com/videoplay?docid···64931512 .
Routers have 2 classes of traffic: packets to the router, packets to something else. Packets destined for something else go through routing ASICs which are just like the mail sorting machines -- they automatically whip packets to their destination at blazing fast speeds. Packets to the router get yanked out of this high speed forwarding system and get handled by a software process on the router similar to letters that need to be sorted by people rather than the sorting machine. If there's a bunch of mail that gets kicked out of the sorter to be handled by people, it's possible for those letters/packages to be delayed a bit because they're limited by how many items humans can sort in a given amount of time. The rest of the letters that take the normal path through the sorting machine, however, are completely unaffected by this slowdown. The extra delays you see in those routers are because the routers don't dedicate many resources to dealing with traffic that falls outside of the normal forwarding path.
When your computer sends packets it typically assign them a large TTL (Time to Live) value (ie, 128). Each router that touches the packet decrements this counter by 1; if the counter makes it down to 0 before the packet reaches its final destination it is discarded and a TTL Exceeded notification is sent back to the source of the packet. This prevents packets from bouncing around forever in the event of a routing loop.
Traceroute works by sending out packets addressed to the final destination but with a TTL=1, the first hop that gets the packet will decrement the TTL, it becomes 0, and the packet changes from being to someone else to being something the router has to deal with and gets pushed aside for special handling. Once it gets a resource in the special handling queue the router will generate a packet back to your computer saying "this packet died here". Your traceroute program shows where this packet came from, and how long it took from when the initial packet went out. Traceroute then sends a packet with TTL=2, the first hop treats it as a packet to someone else marks the TTL=1 and zings the thing along, where the 2nd hop in the path has to repeat the above process. This happens all the way down the path until it reaches its final destination. It's important to note that the key discriminator here is the TTL value, not ICMP vs TCP vs UDP. Routers only focus on the IP header, which includes the TTL, and don't really care about the ICMP/UDP/TCP header.
It is because traffic to a router is handled differently than traffic through a router that you can't make a determination of performance based on traceroute data. That's like trying to make a guess on how fast the automated sorting machines are based on how quickly a human postal worker can sort letters that get tossed aside. There's very little relation between the two processes even though they happen in the very same building, just like packets are handled in the same router.
Traceroute can give you information about your forward network path, and can be used in some cases to troubleshoot certain types of network problems. For latency concerns, start with end-to-end latency -- ping your game server, ping web servers, ping the things actually serving up content. If those ping results all come back normal, ignore the crap in the middle. Looking at traceroute data out of context is just going to start you chasing down problems that don't exist.
-Eric |
|
dav0r
translate
Premium
join:2003-06-15
Albertville, MN
·Charter Pipeline
·Embarq
1 edit | Cool thanks. Yeah also test with a friend from time to time into me when possible. Basically sure the 17ms doesn't matter much but the problem is that not only is the first hop longer the end result is longer as well.
I probably just hook up to an old CO and have a geriatric DSL connection here... really not sure. I can call and ask about that. But glad I did ask because they actually said that it was on the bad side slightly when I was on the phone with them so it's good to understand things better.
Agree about the 'crap in the middle' and the end result is most important with tracerts. It's important to not focus too much, also agree (or try most of the time). When Embarq was running well, which has so far been only 50% of the time on off hours, the only thing it did as well as the cable was getting to LA. DFW was about the same, too, but everything else was +10/+20ms further. That's why I wish my first hop could be lower just to get the end result down (or at least hoping it would lower it but you're right I don't know exactly what it means for my DSL scenario; where it is, if it would even matter, etc.).
Anyway, great info for anyone to read up on. I understand about 1/3 of what really goes on for IP/ISP topology. 1/3 of it is private and I can't find out what I'd really like to know anyway (how congested, routing decisions/changes, etc.), the other 1/3 would be the rest of the world. I'm only one piece of the connection and even with games that are hosted for that session by an end user doesn't mean things are/were optimal for everyone or not.
I suppose the bottom line is that I'll simply have to try 'what I do' after the upgrade. Don't kill people too much for trying to articulate suckage into ISP terms. Even though I don't fully understand what I'm seeing at times usually if there is some sort of difference on my end (or my ISPs network/close-chosen peer network) I need some type of information to report to them other than "Hey, I was playing Halo3 today and it sucked way worser than usual, could you fix your stuff that you fix over there when things are broken?" Don't think I would get too far with that. But for a base yes, try it and see how it goes generally is a better mechanism than trying to learn exactly what is going on when it is not fully understood.
Still... those numbers sucked. That I do know.
Edit: Just wish I could get numbers like this with solid DSL because I like being more 'on my own' as often as possible...
1 {1 ms {1 ms {1 ms 192.168.1.59
2 7 ms 7 ms 8 ms 10.55.224.1
3 9 ms 7 ms 8 ms 24.196.48.1
4 9 ms 11 ms 9 ms 172.18.186.57
5 20 ms 27 ms 20 ms 12.116.239.17
6 20 ms 19 ms 20 ms 12.123.6.13
7 20 ms 19 ms 19 ms 12.123.6.25
8 24 ms 19 ms 19 ms 192.205.33.210
9 19 ms 20 ms 19 ms 4.68.101.129
10 53 ms 52 ms 52 ms 209.247.11.22
11 53 ms 52 ms 54 ms 4.68.122.45
12 53 ms 53 ms 53 ms 8.9.232.74
13 52 ms 51 ms 51 ms 72.249.0.66
14 51 ms 52 ms 52 ms 72.9.144.30 |
|
espaeth
Digital Plumber
Premium,MVM
join:2001-04-21
Minneapolis, MN
·voip.ms
·Vitelity VOIP
·Callcentric
·VoiceStick
·ViaTalk
·Comcast
·Embarq
| said by dav0r :Don't kill people too much for trying to articulate suckage into ISP terms. The reason I corrected your use of "peering instability" is because you've said that in a few posts now and it means something completely different than what you are describing. If that were to end up in a ticket that made it to the engineering group, they'd likely just check their BGP adjacencies, see they've been stable for weeks, and close the ticket.
In order for support departments to fix a problem they need to see and reproduce it themselves. That's why it's important that if you're going to use industry terminology that you are using it accurately as to not send folks in the wrong direction to look at a problem.
For your latency tests you might want to pick something a little less popular that Speakeasy's DNS servers. Those things get hammered by people doing testing all day long so some loss is inevitable. Try testing a continuous ping against steadfast.net or some other site in Chicago instead.
-Eric |
|
dav0r
translate
Premium
join:2003-06-15
Albertville, MN
·Charter Pipeline
·Embarq
| Good idea. mail.siteprotect.com likely gets hammered as well but that seems to be another good barometer. I think I just need to keep my pants unbunched for now because during off-peak (like way off-peak like 7am) things are good. I did noticed that my upstream changed from 864 to 832 w/o a power cycle.
Wish I knew as much about this stuff as Nortel/telephony. Dang. Didn't mean for that to sound snotty btw... I really think part of the issue is me being served by an older switch. I need to verify this... but my NXX hangs off of STMCMNXSRS0 which is really hosted by OSSEMNXODS0 per LERG7 SHA. The STP pair is CHSKMNXC21W & OSSEMNXO21W (Chaska/Osseo)... Looks like it may be a Nortel switch. Wish I knew the configuration.
»www.localcallingguide.com/lca_pr···xtdays=0 |
|
dav0r
translate
Premium
join:2003-06-15
Albertville, MN
·Charter Pipeline
·Embarq
| reply to dav0r
I'm still hanging around 9db for the upstream noise but Embarq assured me that this is fine until 6db. Basically he said my stats are totally cool where they are guess I will run with that.
He also advised that the first week of November is when the DSLAM addition is slated to be turned up which should alleviate some latency during busy hours for users.
My sync had bounced again yesterday upon reconnect but today I reconnected and it remained 5888/864 from overnight and the reset was the same when it came back. If that latency issue gets fully resolved and I'm under 30ms to Chicago consistently and under 80ms to LA consistently I will likely be ditching mister cable.
Embarq's tech support is awesome. Honest, informative, etc. Love it. Still hopeful here. I think when I called to cancel Charter (haven't done so yet they talked me out of it) they may have done something to my routing. Since that call my peering changed the next morning and has not changed since in over two weeks. Probably a coincidence but not sure. Stats are better, however. We'll see though because they always seem to come and go with no reason, rhyme, or most importantly accountability. |
|
Soldae
@comcast.net
| reply to dav0r
If you stay at 9db, call back in. They recently changed their regulations from a cutoff at 6db to 9db. So if a tech told you 6db, he either hasn't been trained on it, or he forgot.
Also, their dispatches are getting looked at, so you may have to ask for a supervisor to get a tech out there to look at the line (they're exempt from the dispatch regulations).
But, if everything keeps working, then awesome! |
|
Shadow18
join:2004-12-28
Chesterhill, OH
| reply to dav0r
My "Numbers":
Upstream Speed: 736 kbps
Downstream Speed: 3520 kbps
Upstream Noise Margin
noise margin upstream: 18 db
output power downstream: 15 db
attenuation upstream: 5 db
Downstream Noise Margin
noise margin downstream: 27 db
output power upstream: 12 db
attenuation downstream: 16 db
My Traceroute To Dallas:
Tracing route to tailormadeservers.com [72.9.144.30]
over a maximum of 30 hops:
1 1 ms 1 ms 1 ms 192.168.1.1
2 12 ms 13 ms 12 ms oh-71-2-96-1.dyn.embarqhsd.net [71.2.96.1]
3 12 ms 12 ms 13 ms oh-69-34-31-185.sta.embarqhsd.net [69.34.31.185]
4 21 ms 21 ms 21 ms sl-gw10-roa-3-3.sprintlink.net [160.81.95.37]
5 21 ms 21 ms 21 ms sl-bb20-roa-2-0.sprintlink.net [144.232.0.5]
6 21 ms 21 ms 21 ms sl-bb22-chi-4-0-0.sprintlink.net [144.232.18.36]
7 31 ms 32 ms 32 ms sl-bb21-kc-3-0.sprintlink.net [144.232.20.129]
8 32 ms 32 ms 32 ms sl-bb20-kc-15-0.sprintlink.net [144.232.2.117]
9 43 ms 44 ms 43 ms sl-crs1-fw-0-4-0-1.sprintlink.net [144.232.20.56]
10 44 ms 43 ms 43 ms sl-st20-dal-12-0-0.sprintlink.net [144.232.9.193]
11 44 ms 43 ms 43 ms 144.228.250.114
12 44 ms 44 ms 44 ms border4.tge4-1-bbnet2.ext1.dal.pnap.net [216.52.191.94]
13 45 ms 44 ms 45 ms colo4dallas-3.border4.ext1.dal.pnap.net [216.52.189.10]
14 44 ms 44 ms 44 ms 206.123.64.21
15 44 ms 44 ms 44 ms 72.249.0.66
16 44 ms 44 ms 44 ms tailormadeservers.com [72.9.144.30]
Trace complete.
Chicago:
Tracing route to chi.speakeasy.net [64.81.159.2]
over a maximum of 30 hops:
1 1 ms 1 ms 1 ms 192.168.1.1
2 12 ms 12 ms 12 ms oh-71-2-96-1.dyn.embarqhsd.net [71.2.96.1]
3 12 ms 13 ms 12 ms oh-69-34-31-181.sta.embarqhsd.net [69.34.31.181]
4 20 ms 20 ms 21 ms sl-gw31-chi-4-1.sprintlink.net [160.81.42.5]
5 21 ms 20 ms 21 ms sl-bb21-chi-4-0.sprintlink.net [144.232.26.29]
6 20 ms 21 ms 21 ms sl-bb22-chi-15-0.sprintlink.net [144.232.26.97]
7 21 ms 21 ms 21 ms sl-st21-chi-11-0-0.sprintlink.net [144.232.20.21]
8 21 ms 21 ms 21 ms chp-brdr-01.inet.qwest.net [205.171.1.137]
9 22 ms 22 ms 22 ms cer-core-01.inet.qwest.net [205.171.139.145]
10 21 ms 21 ms 22 ms chx-edge-01.inet.qwest.net [205.171.139.162]
11 21 ms 22 ms 22 ms 63.150.27.98
12 21 ms 22 ms 22 ms dns.chi1.speakeasy.net [64.81.159.2]
Trace complete. |
|
dav0r
translate
Premium
join:2003-06-15
Albertville, MN
·Charter Pipeline
·Embarq
| This is what I'm looking for. 12ms to the first hop is pretty good and your ping to chi.speakeasy is what it should be around lower 20ms from Ohio/Minneapolis. On cable I've gotten as low as 17ms to Chicago but it'll bounce around from 19-39 and it seems that things local to me on the cable network affect me slightly from time to time; like on-demand burts or something. It's hard to pinpoint but once in a while it'll hiccup a bit.
Hoping if I can shave 5ms off my first hop and get that upstream db above 10 would probably ditch ye olde cable. I just miss DSL. Thanks for posting! |
|
dav0r
translate
Premium
join:2003-06-15
Albertville, MN
·Charter Pipeline
·Embarq
| reply to Soldae
Very good to know. I may try to either try that ring test bypass thing that was posted or simply sync up at the demarq to see if that makes a difference. I've also wondered if there is a power line near the boxes where the cable and phone go upstairs affecting both cable and DSL a little bit. I'm no electrician that's for sure... but the demarq for the cable was doing the same thing as inside the home so I don't think that's the case.
Getting closer to the slated upgrade window so as soon as that is confirmed as having been done will likely follow up on these items. Appreciate your post. |
|
bctrainers
join:2004-08-03
Olathe, KS
| my DSL line at copper is up on some high tension power lines, but this doesn't seem too bad:
Tracing route to chi.speakeasy.net [64.81.159.2]
over a maximum of 30 hops:
1 1 ms 1 ms 5 ms 192.168.1.1
2 11 ms 8 ms 8 ms ks-138-210-240-1.dhcp.embarqhsd.net [138.210.240.1]
3 8 ms 8 ms 8 ms ks-76-7-255-237.sta.embarqhsd.net [76.7.255.237]
4 20 ms 10 ms 11 ms sl-gw10-kc-7-1.sprintlink.net [160.81.124.189]
5 11 ms 9 ms 13 ms sl-bb21-kc-14-0.sprintlink.net [144.232.23.73]
6 21 ms 20 ms 20 ms sl-bb22-chi-8-0.sprintlink.net [144.232.20.128]
7 84 ms 39 ms 59 ms sl-st21-chi-11-0-0.sprintlink.net [144.232.20.21]
8 24 ms 20 ms 20 ms chp-brdr-01.inet.qwest.net [205.171.1.137]
9 21 ms 20 ms 20 ms cer-core-01.inet.qwest.net [205.171.139.145]
10 22 ms 20 ms 39 ms chx-edge-01.inet.qwest.net [205.171.139.162]
11 21 ms 22 ms 20 ms 63.150.27.98
12 34 ms 20 ms 21 ms dns.chi1.speakeasy.net [64.81.159.2]
Trace complete.
Do note i am on alpha firmware, so ping times are you can tell are rather odd.
--
--bc |
|
