Hi - wondering if anyone can help me troubleshoot an issue i'm having with my network.
I have a TG1672G with TWC 300mbps service.
It is bridged to my home LAN - multiple speed tests across the LAN from point to point show a consistent 650-800mpbs throughput and sustained local large file transfers have no issues.
The reason i mention that is because during high-speed WAN downloads - from say Dropbox or Google Drive, or any site that can sustain a download in the higher ranges, if the browser download speed gets above 8mb/s or so for a file of over several hundred MB, at some point the WAN connection will be lost. The modem will of course reconnect but it means the download has to be restarted.
The curious thing to me is that if is, for example, a 1gb file download at 3MB/s - no issue at all. Whereas another 1gb download that can reach over 8mb/s - almost certain to have an interupt.
Obviously to effectively troubleshoot i would like to provide useful details - the event log on the Arris has no entry for any of the events. The Cisco router (RV320) simply shows a 'WAN connection down' message followed 30s later by a 'WAN connection is up' message.
Can anyone suggest a suitable approach to effectively troubleshoot the issue? And any more details that would be helpful.
I suppose a good overall question is "What scenarios would only cause high data-rate downloads to fail?"
Many thanks
Solved! Go to Solution.
Copy and paste the modems signal level and error log pages without doing a reset, need to see history& Correcteds
Next issue.. is wireless, the firewall or IP flood detect still on in the 1672?
Is the wan port of your router connected to the port 1 on the 1672 thru a cat 6 cable?
Thank you :-)
Wireless disabled, ditto firewall - i will check the ip flood.
Here is the status info:
I should note - after the cable block i have a straight shot to the Arris. No splitters.
EDIT: confirming DoS attack protection is disabled
Downstream 1 | 15 | 603.00 MHz | -1.60 dBmV | 35.78 dB | 256QAM | 16478785171 | 67868 | 3700 |
Downstream 2 | 9 | 567.00 MHz | -1.40 dBmV | 38.61 dB | 256QAM | 9102072239 | 128168 | 20175 |
Downstream 3 | 10 | 573.00 MHz | -1.40 dBmV | 38.61 dB | 256QAM | 9809134318 | 117126 | 13259 |
Downstream 4 | 11 | 579.00 MHz | -1.70 dBmV | 37.64 dB | 256QAM | 9524536953 | 108072 | 9623 |
Downstream 5 | 12 | 585.00 MHz | -1.70 dBmV | 36.61 dB | 256QAM | 9440189615 | 100686 | 7708 |
Downstream 6 | 13 | 591.00 MHz | -1.50 dBmV | 37.64 dB | 256QAM | 9354751602 | 81176 | 5314 |
Downstream 7 | 14 | 597.00 MHz | -1.30 dBmV | 37.36 dB | 256QAM | 9671220925 | 70958 | 4091 |
Downstream 8 | 16 | 609.00 MHz | -1.30 dBmV | 37.36 dB | 256QAM | 9619138486 | 56687 | 2386 |
Downstream 9 | 17 | 615.00 MHz | -1.30 dBmV | 37.64 dB | 256QAM | 8980033861 | 45537 | 1468 |
Downstream 10 | 18 | 621.00 MHz | -1.20 dBmV | 36.61 dB | 256QAM | 9018629957 | 47108 | 1412 |
Downstream 11 | 19 | 627.00 MHz | -1.10 dBmV | 37.36 dB | 256QAM | 9068400734 | 45282 | 1389 |
Downstream 12 | 26 | 669.00 MHz | -1.40 dBmV | 37.36 dB | 256QAM | 9567267481 | 48417 | 3363 |
Downstream 13 | 29 | 687.00 MHz | -1.50 dBmV | 37.36 dB | 256QAM | 11811388366 | 39744 | 3551 |
Downstream 14 | 30 | 693.00 MHz | -1.10 dBmV | 37.64 dB | 256QAM | 11949335893 | 34580 | 4138 |
Downstream 15 | 31 | 699.00 MHz | -1.10 dBmV | 37.64 dB | 256QAM | 10851512411 | 42838 | 61511 |
Downstream 16 | 32 | 705.00 MHz | -0.80 dBmV | 37.64 dB | 256QAM | 10128629108 | 45439 | 229004 |
Looks like a corroded or loose connector allowing local tv ch 36 ingress on the home freq of 603 mhz for a start. I also need to see the upstream info.
The s/n on that ch is a lot lower than the rest, the home ch is more critical, see if doing a factory reset will bump some other freq in it's place, you probably will need to repair the custom bridged mode settings after the reset.
You have horrible amounts of correctables and uncorrectables on all channels and I'll bet they are crashing the buffer , or overflowing it. It's hard to tell how bad as TWC has a bunch of modems that don't show the total or unerrored bytes sent.
Correctables are bytes that are resent only once, between the modem and the head end via coax, however if the retry fails, they become uncorrectable and MUST BE renegotiated all the way back to the originating server. That is all the way back thru multiple hops.
Since your Down to Up ratio is 15 to 1, that request screws over a huge quantity of DS bytes, they can't be put into the proper order and saved by your CPE till the bad one is fixed, if this happens a bunch of times in a row, the router/ modem crashes.
Verify all connections are not corroded and a tad more than finger tight. reset the fec counters, see what the corrected/uncorrecteds do after an hour., this may be bad outside line/pole tapoff connections if it still is bad and needs twc out to investigate.
You also need to, especially using dropbox which is horrible, is to impose a 25- 50% QOS restriction on the machine using it and any others that have hi bandwidth requirements.
That will allow other devices to share bandwidth and allow for error correction.
This is also another sign of bad connections, it's ingress from your 4G phone, on their 705 mHz slot... Believe it's AT&T on 705& 711 mHz, T mobile on 699 mHz
Downstream 16 | 32 | 705.00 MHz | -0.80 dBmV | 37.64 dB | 256QAM | 10128629108 | 45439 | 229004 |
Thanks again - very helpful.
I will throw a new run of coax to the block under the house (still previous owners line - could be 7-10 years old) and check for corrosion as far as possible.
I must say i though the correctables were horrendously higher than i am used to seeing. My observation in this install is that the errors seem to come in waves. For example - many days with errors in the zero to low hundreds then all of sudden - boom - some kind of event that creates thousands. Then back to normal again.
For example - here is after one hour:
DCID | Freq | Power | SNR | Modulation | Octets | Correcteds | Uncorrectables | |
Downstream 1 | 15 | 603.00 MHz | -1.70 dBmV | 35.78 dB | 256QAM | 16590895015 | 0 | 0 |
Downstream 2 | 9 | 567.00 MHz | -1.50 dBmV | 38.61 dB | 256QAM | 9215877041 | 0 | 0 |
Downstream 3 | 10 | 573.00 MHz | -1.50 dBmV | 38.61 dB | 256QAM | 9949393866 | 1 | 0 |
Downstream 4 | 11 | 579.00 MHz | -1.90 dBmV | 37.64 dB | 256QAM | 9581236029 | 0 | 0 |
Downstream 5 | 12 | 585.00 MHz | -1.80 dBmV | 36.61 dB | 256QAM | 9495821741 | 0 | 0 |
Downstream 6 | 13 | 591.00 MHz | -1.60 dBmV | 37.36 dB | 256QAM | 9415275471 | 0 | 0 |
Downstream 7 | 14 | 597.00 MHz | -1.50 dBmV | 36.61 dB | 256QAM | 9800364999 | 0 | 0 |
Downstream 8 | 16 | 609.00 MHz | -1.50 dBmV | 37.36 dB | 256QAM | 9745073772 | 0 | 0 |
Downstream 9 | 17 | 615.00 MHz | -1.40 dBmV | 37.64 dB | 256QAM | 9020873446 | 0 | 0 |
Downstream 10 | 18 | 621.00 MHz | -1.30 dBmV | 36.39 dB | 256QAM | 9065560882 | 0 | 0 |
Downstream 11 | 19 | 627.00 MHz | -1.20 dBmV | 37.36 dB | 256QAM | 9116856624 | 0 | 0 |
Downstream 12 | 26 | 669.00 MHz | -1.50 dBmV | 37.36 dB | 256QAM | 9620122274 | 0 | 0 |
Downstream 13 | 29 | 687.00 MHz | -1.50 dBmV | 37.36 dB | 256QAM | 11884925184 | 0 | 0 |
Downstream 14 | 30 | 693.00 MHz | -1.20 dBmV | 37.64 dB | 256QAM | 12053804294 | 0 | 0 |
Downstream 15 | 31 | 699.00 MHz | -1.20 dBmV | 37.64 dB | 256QAM | 10930233698 | 0 | 0 |
Downstream 16 | 32 | 705.00 MHz | -0.90 dBmV | 37.64 dB | 256QAM | 10231889847 | 12 | 641 |
Reset FEC Counters |
Minimal as you can see - EXCEPT as you observed the AT&T ingress on Ch16.
Here is the upstream info:
Upstream
UCID | Freq | Power | Channel Type | Symbol Rate | Modulation | |
Upstream 1 | 35 | 30.60 MHz | 45.00 dBmV | DOCSIS2.0 (ATDMA) | 5120 kSym/s | 64QAM |
Upstream 2 | 36 | 37.00 MHz | 44.50 dBmV | DOCSIS2.0 (ATDMA) | 5120 kSym/s | 64QAM |
Upstream 3 | 34 | 23.30 MHz | 46.00 dBmV | DOCSIS2.0 (ATDMA) | 5120 kSym/s | 64QAM |
Upstream 4 | 33 | 18.50 MHz | 45.25 dBmV | DOCSIS1.x (TDMA) | 2560 kSym/s | 16QAM |
Thanks for the advice on the QoS restrictions on those machines requiring those services - will explore that config now.
Thanks for your help :-)
If it's an overhead line, running thru trees, the branches and tree rodents have chewed it up, explains the correction faults, Probably when windy out, I have no idea if the modem did resets and cleared those counters, usually it takes a 3 second loss to do a reset.
the outside connectors are probabbly bad/loose/corroded. Cable in the house is probably ok but if connectors are old, they may be old hex crimped, not compression, also look at tighten what's on the back side of wall plates.
Both overhead and underground lines can have problems,
Can you post a photo of the outside grounding block and pole tap off block?
You're running a lot of data in the past hour.
Very possible that bursts are exceeding the routers capacity, other customers have noticed that when going to 200&300 meg speeds, QOS may help steady data flow and allow error correction to work.
Yes - i will locate the pole and upload a picture.
Understood on the internal cable/connectors. I am also of the mind that the fewer joins in any circuit the better - so with that in mind there are actually no wallplates before the modem - the cable enters the house to the block then goes straight via a 50ft cable into the Arris.
All the TV's in the house use the TWC app which probably represents the high data usage over the last hour - plus regular large file transfers.
Just to close this out:
So after inspecting my line as far as i could (it goes underground), I found a nick in the cable out by the street - enough to expose the braid.
After a call to TWC the engineer came out the next day, and then the following morning another crew to run a new cable from the box to the house.
I have been testing multiple large download's, averaging around 17MB/s (this on 300mb service). No disconnects or dropouts so far.
Thanks again for help