how-to block ads
|
|
Uniqs:
2127 |
Share Topic
 |
 |
|
|
|
| Cleveland West Side practically unusable since Jan 17So, on the 14th, WOW dropped my entire head end and brought us back up in the 50.4 space during change window. Thanks so much for the warning so I could make sure things didn't explode and start paging me at 4AM. (Yes, that is very much sarcasm. So much sarcasm.) And it should go without saying, but will be said anyway, that WOW_Dan is not to blame here. He's just the messenger, this is not his fault, and it's a few morons who shouldn't have enable who have caused this.
So anyway. It is not my modem. It is whatever they screwed up worse on an already dangerously screwed up network. (Hint: if two CCNAs can spot the fail from what I sent them, then the people you hired aren't qualified to configure a Mot SB3100, forget an Arris C5. I can refer you to some competent network architects who know the difference between a VLAN, PAT, and a FlexWAN PA doing MPLS if you want.)
Since the 17th, I have been dropping connection from World of Warcraft, AIM, Yahoo! Messenger, rsync, and ssh seemingly at random as well as losing DNS+DNSSEC - for around 2-5 minutes at a time. Not so mysteriously, HTTP and IMAP are usually unaffected for the duration and work just fine. To reiterate: it's not my modem, period. See, if it was my modem, HTTP would quit working. IMAP would stop. They don't. Backbone issues? Hm, we'll go with how about no, since that would break everything instead of just selected protocols. Certainly, Google Talk wouldn't continue to work, as it has through every outage. And I'd say this is definitely unrelated to the latency issues, since it's a total cessation of passing packets.
Is it specific port filtering or shaping? No, it probably is not, but I can't say for sure since there's a misconfigured PAT in the way that should be exclusive to settop and not DOCSIS segment. What I do know is that all of the affected services suddenly saw a huge latency drop - 60ms to 30ms in Warcraft, for example - which is when the problems started. (And going from 60ms to 30ms is enough of a drop to make me suspicious to begin with. Halving an already low ping overnight is not realistic unless you just started peering with 'em.) MTR's results absolutely do not jive with that, and show jitter has gone absolutely through the roof - 0.2ms or less to a minimum 2ms with spikes NOT reproducible outside of Wide Open West's network. Let me reiterate: results outside of WOW's network involving similar/same hops do NOT show this extent of jitter.
mtr uswest.battle.net
HOST: REMOVED.FOR.SECURITY Loss% Snt Last Avg Best Wrst StDev
1.|-- THIS is an Arris C-series 100.0 10 0.0 0.0 0.0 0.0 0.0
2.|-- Cisco WS-X6182-2PA 0.0% 10 10.8 11.7 9.7 15.6 1.8
3.|-- Cisco WS-C3750V2-??TS-E 0.0% 10 14.0 12.2 10.0 14.0 1.0
4.|-- 216.55.39.53 0.0% 10 21.0 27.6 19.5 62.6 14.8 - "HI WE STILL FAIL AT DNS. -XO Communications."
5.|-- vb1111.rar3.chicago-il.us 0.0% 10 38.3 34.3 30.9 38.3 2.3
6.|-- 207.88.14.194.ptr.us.xo.n 20.0% 10 41.4 41.5 40.9 43.8 0.9
7.|-- 206.111.2.90.ptr.us.xo.ne 0.0% 10 42.4 41.9 40.3 44.4 1.1
8.|-- cr1.cgcil.ip.att.net 0.0% 10 123.4 93.8 88.4 123.4 10.5
9.|-- cr1.sffca.ip.att.net 0.0% 10 88.1 89.2 87.2 92.5 1.7
10.|-- gar4.sc1ca.ip.att.net 0.0% 10 84.7 93.0 84.7 138.4 17.0
11.|-- 12.122.251.126 0.0% 10 108.0 90.6 85.7 108.0 8.6
12.|-- mdf2-bi8k-2-eth-2-1.rwc1. 0.0% 10 86.1 87.1 86.1 88.2 0.7
13.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
mtr useast.battle.net
HOST: REMOVED.FOR.SECURITY Loss% Snt Last Avg Best Wrst StDev
1.|-- THIS is an Arris C-series 100.0 10 0.0 0.0 0.0 0.0 0.0
2.|-- Cisco WS-X6182-2PA 0.0% 10 10.8 11.7 9.7 15.6 1.8
3.|-- Cisco WS-C3750V2-??TS-E 0.0% 10 14.0 12.2 10.0 14.0 1.0
4.|-- 216.55.39.53 0.0% 10 21.0 27.6 19.5 62.6 14.8
5.|-- vb1111.rar3.chicago-il.us 0.0% 10 38.3 34.3 30.9 38.3 2.3
6.|-- 207.88.14.194.ptr.us.xo.n 20.0% 10 41.4 41.5 40.9 43.8 0.9
7.|-- 206.111.2.90.ptr.us.xo.ne 0.0% 10 42.4 41.9 40.3 44.4 1.1
8.|-- cr1.cgcil.ip.att.net 0.0% 10 123.4 93.8 88.4 123.4 10.5
9.|-- cr1.sffca.ip.att.net 0.0% 10 88.1 89.2 87.2 92.5 1.7
10.|-- gar4.sc1ca.ip.att.net 0.0% 10 84.7 93.0 84.7 138.4 17.0
11.|-- 12.122.251.126 0.0% 10 108.0 90.6 85.7 108.0 8.6
12.|-- mdf2-bi8k-2-eth-2-1.rwc1. 0.0% 10 86.1 87.1 86.1 88.2 0.7
13.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
mtr 1.ponyfortress2.com (74.91.112.232) - CAUTION: More DNS fail. Use the IP.
HOST: REMOVED.FOR.SECURITY Loss% Snt Last Avg Best Wrst StDev
1.|-- THIS is an Arris C-series 100.0 10 0.0 0.0 0.0 0.0 0.0
2.|-- Cisco WS-X6182-2PA 0.0% 10 10.8 11.7 9.7 15.6 1.8
3.|-- Cisco WS-C3750V2-??TS-E 0.0% 10 14.0 12.2 10.0 14.0 1.0
4.|-- ge-6-20.car1.Cleveland1.L 0.0% 10 13.1 14.6 11.8 35.2 7.2
5.|-- ae-2-4.bar1.Cleveland1.Le 0.0% 10 14.1 14.6 11.4 28.9 5.2
6.|-- ae-6-6.ebr1.Washington1.L 0.0% 10 19.1 23.0 19.1 37.2 5.4
7.|-- ae-81-81.csw3.Washington1 0.0% 10 20.0 22.9 19.4 44.8 7.7
8.|-- ae-3-80.edge1.Washington4 0.0% 10 20.9 29.3 20.6 82.5 19.5
9.|-- gblx-level3-40g.Washingto 0.0% 10 21.6 32.3 20.6 112.1 28.5
10.|-- lag9.csr1.DCA3.gblx.net 0.0% 10 22.1 32.8 19.3 129.4 34.1
11.|-- po1.ar5.ATL1.gblx.net 0.0% 10 36.7 50.2 34.0 152.1 37.1
12.|-- Internap-Atlanta.TenGigab 0.0% 10 34.6 44.2 34.6 124.0 28.1
13.|-- border10.tge4-1-bbnet2.ac 0.0% 10 34.8 43.7 34.8 116.1 25.4
14.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
Don't know WHAT is up with L3 at InterNap DC, but given testing time, most likely related to a series of ongoing DDoS attacks which has been interfering with the whole peering point.
These were performed from AS2828 public-facing, and are reasonably similar to results from AS3356. And anyone who doesn't immediately know what these mean has no business with enable on WOW's network.
AS2828 LG traceroute useast.battle.net
1 65.106.2.113.ptr.us.xo.net (65.106.2.113) 0 msec 4 msec 0 msec
2 216.156.13.33.ptr.us.xo.net (216.156.13.33) 4 msec 56 msec 0 msec
3 vb1700.rar3.chicago-il.us.xo.net (216.156.0.161) 8 msec 4 msec 4 msec
4 207.88.14.194.ptr.us.xo.net (207.88.14.194) 0 msec 4 msec 0 msec
5 206.111.2.90.ptr.us.xo.net (206.111.2.90) 4 msec 0 msec 76 msec
6 cr1.cgcil.ip.att.net (12.122.81.94) [MPLS: Label 17051 Exp 0] 28 msec 24 msec 20 msec
7 cr2.wswdc.ip.att.net (12.122.18.22) [MPLS: Labels 0/18357 Exp 0] 24 msec 28 msec 24 msec
8 12.122.134.197 20 msec 20 msec 24 msec
9 12.122.251.78 24 msec 20 msec 20 msec
10 mdf001c7613r0003-gig-10-1.wdc1.attens.net (63.240.193.10) 20 msec 20 msec
mdf001c7613r0004-gig-12-1.wdc1.attens.net (63.240.193.14) 36 msec
11 * * *
AS2828 LG traceroute 1.ponyfortress2.com
1 65.106.2.113.ptr.us.xo.net (65.106.2.113) 0 msec 4 msec 0 msec
2 ge11-0-4d0.mcr1.chicago-il.us.xo.net (216.156.13.25) 4 msec 4 msec 0 msec
3 ae1d0.mcr2.chicago-il.us.xo.net (216.156.1.82) [MPLS: Label 426864 Exp 0] 4 msec 0 msec 4 msec
4 vb1701.rar3.washington-dc.us.xo.net (216.156.0.165) 20 msec 24 msec 24 msec
5 te4-0-0.cvr1.atlanta6-ga.us.xo.net (207.88.14.114) 32 msec 80 msec 32 msec
6 207.88.188.18.ptr.us.xo.net (207.88.188.18) 32 msec 32 msec 32 msec
7 border10.tge3-1-bbnet1.acs.pnap.net (64.94.0.12) 32 msec 32 msec 28 msec
8 * * *
AS3356 LG traceroute useast.battle.net
1 ae-2-4.bar1.Cleveland1.Level3.net (4.69.132.194) 0 msec 0 msec 0 msec
2 ae-6-6.ebr1.Washington1.Level3.net (4.69.136.190) 24 msec 8 msec 8 msec
3 ae-8-8.ebr1.Washington12.Level3.net (4.69.143.218) 8 msec 20 msec 8 msec
4 ae-103-3503.edge1.Washington12.Level3.net (4.69.158.25) 8 msec 8 msec
ae-101-3501.edge1.Washington12.Level3.net (4.69.158.17) 8 msec
5 att-level3-te.washingtondc12.Level3.net (4.68.62.30) 8 msec 48 msec 8 msec
6 cr2.wswdc.ip.att.net (12.122.84.82) [AS7018 {ATT-INTERNET4}] 16 msec 16 msec
cr1.wswdc.ip.att.net (12.122.88.174) [AS7018 {ATT-INTERNET4}] 12 msec
7 12.122.135.9 [AS7018 {ATT-INTERNET4}] 8 msec
12.122.134.197 [AS7018 {ATT-INTERNET4}] 12 msec 8 msec
8 12.122.251.82 [AS7018 {ATT-INTERNET4}] 12 msec
12.122.251.78 [AS7018 {ATT-INTERNET4}] 12 msec 8 msec
9 mdf001c7613r0004-gig-12-1.wdc1.attens.net (63.240.193.14) [AS17231 {ATT-CERFNET-BLOCK}] 12 msec
mdf001c7613r0003-gig-10-1.wdc1.attens.net (63.240.193.10) [AS17231 {ATT-CERFNET-BLOCK}] 20 msec 20 msec
AS3356 LG traceroute 1.ponyfortress2.com (74.91.112.232)
1 ae-2-4.bar1.Cleveland1.Level3.net (4.69.132.194) 0 msec 0 msec 0 msec
2 ae-6-6.ebr1.Washington1.Level3.net (4.69.136.190) 8 msec 8 msec 8 msec
3 ae-61-61.csw1.Washington1.Level3.net (4.69.134.130) 8 msec
ae-91-91.csw4.Washington1.Level3.net (4.69.134.142) 8 msec
ae-71-71.csw2.Washington1.Level3.net (4.69.134.134) 8 msec
4 ae-1-60.edge1.Washington4.Level3.net (4.69.149.15) 8 msec 8 msec
ae-4-90.edge1.Washington4.Level3.net (4.69.149.207) 8 msec
5 gblx-level3-40g.WashingtonDC4.Level3.net (4.68.63.170) 12 msec 8 msec 8 msec
6 lag9.csr2.DCA3.gblx.net (67.16.146.29) [AS3549 {GBLX}] 60 msec 32 msec
lag9.csr1.DCA3.gblx.net (67.16.146.25) [AS3549 {GBLX}] 212 msec
7 po1.ar5.ATL1.gblx.net (67.17.105.214) [AS3549 {GBLX}] 1228 msec 204 msec 204 msec
8 Internap-Atlanta.TenGigabitEthernet3-4.ar5.ATL1.gblx.net (207.218.80.218) [AS3549 {GBLX}] 200 msec 68 msec 216 msec
9 border10.tge4-1-bbnet2.acs.pnap.net (64.94.0.76) [AS14745 {INTERNAP-BLOCK-4}] 204 msec
border10.tge3-1-bbnet1.acs.pnap.net (64.94.0.12) [AS14745 {INTERNAP-BLOCK-4}] 216 msec
border10.tge4-1-bbnet2.acs.pnap.net (64.94.0.76) [AS14745 {INTERNAP-BLOCK-4}] 212 msec
10 * * *
Discount GBLX hops; ATLGA was under significant DDoS attack at the time of sampling with insufficient mitigation. Go go GBLX. WHY it's going Level3 from WOW's network, I just don't know. XO has a massive peering connection at Internap Atlanta - I can't see any logical reason for going AS3356 to AS3549 to AS14745 when you can quite literally go AS2828->AS14745 direct, but maybe BGP sees something I don't.
But do you know how else I know it's NOT my modem? Because rebooting my modem doesn't fix it. In fact, if I just let it sit, it starts working again. This seems to now happen any time I go over 50-100PPS sustained. Oh, and completely at random. In fact, I can actually look at graphs and see that any time I exceed 100PPS for more than a few minutes, regardless of bandwidth utilization, an upstream hop starts stalling out frequently and will randomly just quit passing packets. I know it's upstream, because the IPv4 gateway is still reachable, still reports up, still reports zero packet loss. Latency spikes and disconnects are confirmed by over 30 other people (including 4 known to be routed with XO and 7 via L3) to be just me. I'm the only one on WOW.
I also know it's not my modem because I'm also seeing random latency spikes regardless of bandwidth and PPS rates. These spikes are not reflected at the IPv4 gateway heartbeat either. Signal levels? Nope. Downstream -7.6dBmV @ 36.7dB, Upstream ranging 38-47.4dBmV based on weather. (Not worth a truck roll - it's weather related. Always has been, always will be.) Speedtest is showing strange behavior - down at 16.06Mb/s (up from 15) and upload has dropped to absolutely not possible.
Here's some ping and smoke tests to one of those two IPs that WOW isn't actively blocking from performing quality tests, shall we?
Ping test which shows packet loss: »/pingtest/9···/2869210
SmokeTest (ongoing) to 144.1: »/r3/smokepi···9502e68a
SmokeTest (ongoing) to 144.10: »/r3/smokepi···aa37e2a2
By the way, initial results are pretty embarrassing - 50ms+ average from all points, significant packet loss and extreme jitter over the past 24 hours.
I honestly don't care what it is. I don't care about excuses or proclamations of "innocence" or "investigating further." At this point, I apparently know the network better than the people supposedly responsible for it. There is no innocence here - there is deliberate blocking of ICMP traffic and there is clear evidence of a specific issue. There is no investigating further - there is a specific problem, most likely with the WS-C3750V2 or immediate next hop, which requires work be performed to at least the minimum required by an entry level position in IT which includes opening a TAC case. Frankly, I am beyond tired of this at this point. Yes, AT&T ENS blew up their network last night - I am painfully well aware. This is not AT&T ENS. This is not XO. This is not Level3.
Hell, for all I know, XO and Level3 are conspiring to slap you around for passing your 10net traffic right out the public facing interface and chewing their CPU cycles filtering it. And YES. YOU ARE DOING IT AND IT IS BOTH WRONG AND STUPID. Your 10net is COMPLETELY wrong. Hell, maybe someone should also tell LW463 to not let his underlings assume people are idiots. Especially people who have worked on geographically diverse DOCSIS systems many times WOW's size before MPLS existed. Or maybe just start by getting rid of the guy who thinks it's "D slam" and lists "Frontpage" as a PROGRAMMING LANGUAGE. Here's a hint: it's an abbreviation for Digital Subscriber Line Access Multiplexer and Copper Mountain was only deployed for very small scale G.991 SDSL and IDSL by minor CLECs; I had some going to Copre DSUs passing V.35. Baby Bells primarily ran Redbacks in mixed-mode with Radius auth'd PPPoA for interLATA and resale and PPPoE for local IP term. I think there might have been a few Nortel NMS deploys in GTE territory since they favored DMS, but don't hold me to it. Huh, turns out old rootwyrm might just have a bit of experience in the regulated communications space, huh? (Oh, and I'm pretty sure you got some 24 and a 64 networks I used to manage DNS for.)
Either way, I am beyond tired of this. And I don't mean metaphorically. I mean physically. You see, every time this happens, and I'm asleep? I GET WOKEN UP BY SERVICE ALARMS. I already had to turn off every single live/dead ping alarm because of the ICMP blocking, which is just childish on their part at best, and if being implemented via BOOTP on modem, hysterically incompetent in light of the other much more significant problems present in the config. Blah blah, home internet, yeahNO. I get woken up by alarms because the automated system I had to write to power cycle the modem via AC outlet control gets tripped, sees the heartbeat gateway is just fine, and says it's external. Meantime, the opposite end of rsync waits 120 seconds, tests remote host, finds it completely unreachable, and fires off an alarm because it thinks the host has died. My NAS sync AND backups just flat out break, and I've been forced to totally disable it, because the outages are just that right length that it exceeds retry count and breaks the mirror. Oh, and then there's the time I've spent troubleshooting a problem which is rather explicitly and clearly WOW's network and responsibility to detect and fix. Did I mention it's happening outside of normal change window too? Yeah. That's another indicator that something's rotten in Denmark, by the by.
So yes, at this point, I would say I am justifiably furious. Especially since I've had to be the one to do all the work, the problems I have found are not only beyond amateurish in nature AND quality of work, but also extremely hazardous and just flat out stupid. I mean seriously, how can this be going on and WOW have absolutely NO awareness of things? How is it DOCSIS 3 managed to get rolled out on this, forget DVRs even working HALF the time? (And that's the LEAST of the potential woes.) Did your network engineers negotiate for "no on call ever"? Just completely ignore their pagers and cell phones after 4:30PM? Do they have no concept of end-to-end heartbeat? Do they just make absolutely no effort whatsoever to monitor service quality or even baseline function? Pretend that 15 minute MRTG sampling is adequate monitoring? I cannot find any rational or logical explanation for why this has been going on for several days with WOW apparently blissfully unaware the whole time. I can tell you for fact that when I had root on the equipment in that very same building - and yes, I mean that EXACT SAME HEADEND right down to the dishes - I got paged the very SECOND anything went down for ANY reason. Frankly, I don't think it's in the slightest unreasonable to expect the same level of professionalism and service from WOW's staff that most IT professionals consider standard.
Like I said; I don't care what the exact problem is, and I'm tired of excuses from people who apparently decided padding their resume was a good idea. Again; no offense intended directly or indirectly, Dan. Not saying you're guilty of it - you definitely are not. I know you're just the messenger here, and I really do appreciate the help. Not your fault OR responsibility that they're putting you in this position, and I don't blame you. But I am tired of these morons putting you in this position with their technical incompetence.
All I want to know at this point is 1) WHEN is this all going to be fixed? 2) WHAT procedural steps will WOW be taking to ensure this does not ever happen again? | |
 mix
join:2002-03-19
Utica, MI | You think anyone is going to read all of this? | |
| said by mix:You think anyone is going to read all of this?
Why, yes, I do. Because it's the job of the people it's directed to and at. Period. | |
Reviews:
 ·WOW Internet and..
 ·Google Voice
| reply to RootWyrm
Very informative. Very in depth. Very convincing. I called Time warner, they agreed to match my service and price I currently get with wow. Issues are not fixed by middle of next week, I am switching. WOW is done getting 2nd chances with me. They show over and over they can not handle the network competently. You can go back and see all the issues I had recently. Took getting escalated to a supervisor to give maintance direct orders what to do to get my issues solved. Started emailing the GM of the Cleveland area about my issues, quick responses, I mentioned leaving wow, how I no longer have faith in them to solve my issues, and all of a sudden he stopped responding. The local supervisor atleast seems like he doesn't care, or doesn't believe that it is an area issue. I am so sick of the "we will monitor" "we will get back to you" blah blah blah. Just fix it, or I am gone. | |
Reviews:
·WOW Internet and..
·Google Voice
| reply to mix
I read it. This just proves my issue is not isolated. Something is broken in the Cleveland area and they refuse to do anything about it. Tell me, if there were issues in your area, you experienced them, and wow just ignored it, would you have read it then?
Yeah its long if you don't really care. But when you have the same exact issues, it is a good read to know other people have them too. | |
Reviews:
·WOW Internet and..
·Google Voice
| reply to RootWyrm
Re: Cleveland West Side practically unusable since Jan 17 I have been monitoring more. Over the past hour or so my TTL on pings have been changing, as well as my ping going up and down consistently at various times. I hope this means somewhere at WOW someone is activly working on the issue. To clarify the TTL, I pinged google.com the first time. Every procedding time I have been using that same IP for google everytime. So it is not connecting to different google servers everytime. | | |
|
| reply to RootWyrm
Solution: Change your ISP. | |
| reply to RootWyrm
If you are having problems with your WOW Service in the Cleveland Metro Market; email Kirk. He is the General Manager and VP of the System.
Here is his email address: kzerkle@wideopenwest.com
He is based in Cleveland unlike WOW support. | |
| reply to RootWyrm
Where would you go? Comcast has that ridiculous 250gb a month bandwidth cap. In 2012, with HD movie streaming, etc. that is simply unacceptable. If they ever drop that cap, I'd be back with Comcast in a heartbeat. | |
| Comcast does NOT service Cleveland they gave up that complete area when they gave Adelphia to TWC (they do service the very rural area around Defiance though), but you could take TWC NEO/WPA or AT&T. | |
| Cox is also in some parts of the cleveland area. | |
| reply to 25139889
These issues have gone to the network engineering group multiple times now, which is the only place they can go. Even if Kirk got involved, it'd end up with the same incompetents, and he'd just end up passing on the same messages from the same blatantly unqualified people.
The configuration is so broken, that I can't and won't go into detail on three problems publicly because of just how severe the risk is. I've tried twice to raise these extremely severe issues, to have them dismissed out of hand by the people who are supposed to be fixing this, making the same patently false claims and trying to treat me like an idiot, or simply refusing to reply or acknowledge the problems. | |
| reply to RootWyrm
said by RootWyrm: I can't see any logical reason for going AS3356 to AS3549 to AS14745 when you can quite literally go AS2828->AS14745 direct, but maybe BGP sees something I don't.
cheaper to go the long way than the direct way (money wise)? | |
Reviews:
·Insight Communic..
| reply to RootWyrm
Dude, as a warning watch it with the bashing of the company, or you will find your address made unserviceable like mine was simply because i got aggrivated at the tun around a spouted off a lil bit that i they were not going to service me to come out and remove the pedistal, or i will. | |
| reply to hudiat
dont leave, thats what they want why grease the squeeky wheel when its allready fallen off, just put a new wheel on. | |
| reply to RootWyrm
Still no response. Still no resolution. Still no improvement. » /r3/smokepi···9502e68a» /r3/smokepi···aa37e2a2Multiple outages tonight with the exact same symptoms as previously discussed. Also continuing to show unacceptable levels of packet loss to a core router. A free tip from an actual professional: the acceptable number is "less than 1%". You're averaging, oh, around 15% seems like a fair number. Not a customer modem. Not a desktop box. A core router. I'm not going anywhere, but the longer this goes on with no response at all and the longer it goes on unresolved? The less I believe that WOW values customers, has any idea about networks at all, and believes that it is absolutely acceptable to expose their customers to extreme security risks and incompetent service. We've got how many other threads with similar symptoms, being blamed on everything but the network, despite clear evidence to the contrary. Why yes, your Arris DOCSIS 3.0 modem certainly has the exact same problem as my SA 2100 DOCSIS 2.0 on a totally different headend. It is to laugh. We know WOW_Dan's around - he's replied to settop issue threads elsewhere. Maybe the folks upstairs are unfamiliar with the FCC regulations? PII violations remain FCC, not LFA, and this isn't a Klimas v. Comcast. Maybe their VP of Operations wants a call from the FCC before they'll do anything? Angry phone calls from Level3 and XO? A widely publicized local news report? I mean, if that's what it's going to take to get so much as a "we are improving our monitoring and change control" out of WOW, let me know, and I'll get started on arranging those. | |
Reviews:
·WOW Internet and..
·Google Voice
1 edit | and today my transmit power dropped.
Last I checked was when the issues started a few days ago, and transmit was 37-40.
Noticed the lag was a little worse today than the past few days, so I checked again, right now it is 35.
Also, recieve ddropped from -5ish to -6ish (not a big drop, but still they both dropped).
The lag in gaming has been unbearable the past few days. Kirk didn't respond to my email. Sent Friday, I figured no weekend response, but it is wednesday afternoon with no response.
Dan, is there an update at all on the circuit? | |
| said by hudiat:and today my transmit power dropped.
Last I checked was when the issues started a few days ago, and transmit was 37-40.
Noticed the lag was a little worse today than the past few days, so I checked again, right now it is 35.
Also, recieve ddropped from -5ish to -6ish (not a big drop, but still they both dropped). Current signal issues can, believe it or not, be attributed in part to a solar event. Largest CME since 2003. No, seriously - this is not off my BOFH Excuse Of The Day calendar.
»boingboing.net/2012/01/24/what-h···-ma.html
While the event is technically over, it's not uncommon for it to take up to 24 hours for complex RF systems to restabilize. During which time, there can (and usually is) increased reports of signal "problems" that are just residual from the CME event. It should be noted, headends are required by the FCC to be RF hardened (and are checked from all angles including overhead) to the point where that equipment is effectively CME immune. Unfortunately, all those lines and junctions on the poles are not in the headend and not CME immune.
The lag in gaming has been unbearable the past few days. Kirk didn't respond to my email. Sent Friday, I figured no weekend response, but it is tuesday afternoon with no response.
Dan, is there an update at all on the circuit?
DOWNSTREAM
ChannelID: 3
Mod: 256QAM
Freq: 621000000
Power: -10.2 dBmV
SnR: 35.3 dB
UPSTREAM
Green
ChannelID: 2
Mod: 32QAM
Freq: 37000000
Power: 48.2 dBmV
Compare to prior -7 dBmV, 36dB, 45 dBmV and it's obvious that signal quality has suffered a nasty hit. Still not my modem - still showing packet loss at headend core. It's entirely possible I'm still seeing CME aftereffects, but we should be nearly clear of the window. Speedtests are showing near expected results on repeated runs - 15.8/1.11, so it's not enough signal loss to cause impact.
So are they trying to fix it and just screwing up signalling in the process, or just steadfastly ignoring it and pretending that bandwidth tests are the only thing that matter? | |
|
