30M Moved channels?

Neo-Tech · 08-11-2011, 18:42

Hi,

My internet went down last night at about 00:26 this morning, and came back on about 2 hours later. I checked this evening to see what had changed. My host name remained the same, except my channels have changed.

Before they were 97, 97, 98 and 99. Now they are:

Locked QAM256 106 55616000 Kbits/sec 307000000 Hz 4.0 dBmV 41.6 dB Hybrid
Locked QAM256 105 55616000 Kbits/sec 299000000 Hz 4.2 dBmV 42.0 dB Hybrid
Locked QAM256 107 55616000 Kbits/sec 315000000 Hz 3.4 dBmV 41.4 dB Hybrid
Locked QAM256 108 55616000 Kbits/sec 323000000 Hz 2.6 dBmV 41.2 dB Hybrid

My upstream remained the same, except the power level dropping by 1dBmV.

Event log showed the following:
Time Priority Description
Tue Nov 08 01:46:29 2011 Critical (3) DHCP FAILED - Requested Info not supported.;CM-MAC=;CMTS-MAC=;CM-QOS=1.1;CM-VER=3.0;
Tue Nov 08 01:46:14 2011 Critical (3) No Ranging Response received - T3 time-out;CM-MAC=;CMTS-MAC=;CM-QOS=1.0;CM-VER=3.0;
Tue Nov 08 01:45:28 2011 Critical (3) SYNC Timing Synchronization failure - Failed to acquire QAM/QPSK symbol timing;;CM-MAC=;CMTS-MAC=00:00:00:00:00:00;CM-QOS=1.0;CM-VER=3.0;
Tue Nov 08 01:43:50 2011 Critical (3) SYNC Timing Synchronization failure - Failed to acquire FEC framing;CM-MAC=;CMTS-MAC=00:00:00:00:00:00;CM-QOS=1.0;CM-VER=3.0;
Tue Nov 08 01:43:32 2011 Critical (3) No UCDs Received - Timeout;;CM-MAC=;CMTS-MAC=00:00:00:00:00:00;CM-QOS=1.0;CM-VER=3.0;
Tue Nov 08 01:43:22 2011 Warning (5) Lost MDD Timeout;CM-MAC=;CMTS-MAC=00:00:00:00:00:00;CM-QOS=1.0;CM-VER=3.0;
Tue Nov 08 01:43:22 2011 Warning (5) MDD message timeout;CM-MAC=;CMTS-MAC=00:00:00:00:00:00;CM-QOS=1.0;CM-VER=3.0;
Tue Nov 08 00:28:11 2011 Critical (3) DHCP FAILED - Requested Info not supported.;CM-MAC=;CMTS-MAC=;CM-QOS=1.0;CM-VER=3.0;
Tue Nov 08 00:27:24 2011 Critical (3) No Ranging Response received - T3 time-out;CM-MAC=;CMTS-MAC=;CM-QOS=1.0;CM-VER=3.0;
Tue Nov 08 00:26:56 2011 Critical (3) Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities received - T4 time out;CM-MAC=;CMTS-MAC=;CM-QOS=1.1;CM-VER=3.0;
Tue Nov 08 00:26:54 2011 Warning (5) Lost MDD Timeout;CM-MAC=;CMTS-MAC=;CM-QOS=1.1;CM-VER=3.0;
Tue Nov 08 00:26:54 2011 Warning (5) MDD message timeout;CM-MAC=;CMTS-MAC=;CM-QOS=1.1;CM-VER=3.0;
Tue Nov 08 00:26:31 2011 Critical (3) SYNC Timing Synchronization failure - Failed to receive MAC SYNC frame within time-out period;CM-MAC=;CMTS-MAC=;CM-QOS=1.1;CM-VER=3.0;

Now most of you are probably going to say, it's working, leave it. I just want to know why channels have changed.

Danke.

grim reaper · 08-11-2011, 19:04

VM were probably doing some maintenance .... or maybe there was a problem at the ubr

whatever the reason you were disconnected, ... and most likely so was everyone else on the ubr ..... when you reconnected your modem connects to the first available chamnnels it finds (someone else got your old channels first)

when your modem disconnects from the ubr you are not guarenteed to get the same channels when you reconnect .... in fact it's more likely that your channels will change

Ignitionnet · 08-11-2011, 19:55

Actually my first thought was who really gives a monkey's uncle, it's just some random number

The post above is total nonsense, ignore it. Your DOCSIS 3 modem has a choice of exactly one set of channels at any one time, every DOCSIS 3 modem in a MAC domain shares the same downstream channels, that's the way cable networks are built with a lot of modems sharing the same channels and same bandwidth.

VM likely resegmented the network and split your local area, moving it onto a new downstream port, hence different channel IDs.

Neo-Tech · 08-11-2011, 20:10

Quote:

Originally Posted by Ignitionnet

Actually my first thought was who really gives a monkey's uncle, it's just some random number

The post above is total nonsense, ignore it. Your DOCSIS 3 modem has a choice of exactly one set of channels at any one time, every DOCSIS 3 modem in a MAC domain shares the same downstream channels, that's the way cable networks are built with a lot of modems sharing the same channels and same bandwidth.

VM likely resegmented the network and split your local area, moving it onto a new downstream port, hence different channel IDs.

Haha most people would think that, but it's just something I'm rather curious about, and something I might want to look at going into, in the future. Only 16!

Thanks for clearing that up though. Can I assume it was done to balance the load?

Ignitionnet · 08-11-2011, 21:49

Quote:

Originally Posted by Neo-Tech

Haha most people would think that, but it's just something I'm rather curious about, and something I might want to look at going into, in the future. Only 16!

Thanks for clearing that up though. Can I assume it was done to balance the load?

You can indeed. You were either cleaved off the current MAC domain and joined with another, more lightly loaded one or you were put onto an entirely fresh set of ports along with a smaller subset of customers.

Say you were sharing the downstreams with another 499 people, the split would have roughly left 250 people on the old port and moved 250 people to the other one, meaning you've gone from 500 people sharing 200Mbit/s which gives you 400kbit/s each to 250 people on each 200Mbit, 800kbit/s each.

Obviously you all get better speeds than that as the odds of everyone using their full whack at once are zero.

Same on the upstream just with smaller pipes, less people on each channel so more capacity for each customer. It's capacity per customer that broadband services are measured in when doing capacity planning.

Make sense?

Neo-Tech · 10-11-2011, 19:49

Quote:

Originally Posted by Ignitionnet

You can indeed. You were either cleaved off the current MAC domain and joined with another, more lightly loaded one or you were put onto an entirely fresh set of ports along with a smaller subset of customers.

Say you were sharing the downstreams with another 499 people, the split would have roughly left 250 people on the old port and moved 250 people to the other one, meaning you've gone from 500 people sharing 200Mbit/s which gives you 400kbit/s each to 250 people on each 200Mbit, 800kbit/s each.

Obviously you all get better speeds than that as the odds of everyone using their full whack at once are zero.

Same on the upstream just with smaller pipes, less people on each channel so more capacity for each customer. It's capacity per customer that broadband services are measured in when doing capacity planning.

Make sense?

Well, if TBB graphs are anything to go by, idle has dropped a fair bit, but there are peaks of latency increases, worse than before. But I'll give it a few weeks and see how it goes. It could just be a heavy downloader on my port. Apart from that, everything else feels the same.

And yes, it makes sense now.

Sephiroth · 11-11-2011, 10:22

In my area, they've resegmented the other way round. My beautifully small domain has had a lump added from a hitherto heavily loaded domain to make my segment visibly slower.

The resegmentation has been confirmed to me by VM. The only other possible buggeration factor is that this week, I've come off Modem Mode to see how the (wireless disabled) SH performs and how TBB response varies from the Airport Extreme.

Next week I'll be back on Modem Mode but as I post a lot about the SH I did feel I ought to get to know even more about its behaviour.

Neo-Tech · 15-11-2011, 18:20

Quote:

Originally Posted by Sephiroth

In my area, they've resegmented the other way round. My beautifully small domain has had a lump added from a hitherto heavily loaded domain to make my segment visibly slower.

The resegmentation has been confirmed to me by VM. The only other possible buggeration factor is that this week, I've come off Modem Mode to see how the (wireless disabled) SH performs and how TBB response varies from the Airport Extreme.

Next week I'll be back on Modem Mode but as I post a lot about the SH I did feel I ought to get to know even more about its behaviour.

I've had no confirmation as such yet. Just waiting for a few more days to pass before I can come to a short conclusion on mine. And do let us know how it goes, it'd be interesting to see the differences (again).

Sephiroth · 15-11-2011, 19:40

The SH in modem mode behaved the same in router mode (wireless off) and firewall in the PC.

The TBB response has been in the same in Modem Mode, Routyer Mode and Airport Extreme.

Neo-Tech · 16-11-2011, 10:08

Surprised... Mine's being a pig again, pages take a little more than a few seconds before it loads, and a reboot fixes it. *sigh*

Neo-Tech · 22-11-2011, 21:46

Annnnd a 2 weeks goes by, and I'm moved... again!

Locked QAM256 34 55616000 Kbits/sec 307000000 Hz 4.0 dBmV 41.8 dB Hybrid
Locked QAM256 33 55616000 Kbits/sec 299000000 Hz 4.4 dBmV 42.0 dB Hybrid
Locked QAM256 35 55616000 Kbits/sec 315000000 Hz 3.5 dBmV 41.5 dB Hybrid
Locked QAM256 36 55616000 Kbits/sec 323000000 Hz 2.9 dBmV 41.4 dB Hybrid

Locked ATDMA 3 20480 Kbits/sec 45800000 Hz 35.8 dBmV

Hostname remains the same, still. However, I have noticed Upstream Power going down a bit every time this happens, which is twice now.

Event Log if anyone can shed any light on why VM did something again.

Tue Nov 22 01:35:55 2011 Critical (3) DHCP FAILED - Requested Info not supported.;CM-MAC=;CMTS-MAC=;CM-QOS=1.1;CM-VER=3.0;
Tue Nov 22 01:35:51 2011 Critical (3) No Ranging Response received - T3 time-out;CM-MAC=;CMTS-MAC=;CM-QOS=1.0;CM-VER=3.0;
Tue Nov 22 01:35:44 2011 Critical (3) SYNC Timing Synchronization failure - Failed to acquire QAM/QPSK symbol timing;;CM-MAC=;CMTS-MAC=00:00:00:00:00:00;CM-QOS=1.0;CM-VER=3.0;
Tue Nov 22 01:35:19 2011 Critical (3) SYNC Timing Synchronization failure - Failed to acquire FEC framing;CM-MAC=;CMTS-MAC=00:00:00:00:00:00;CM-QOS=1.0;CM-VER=3.0;
Tue Nov 22 01:34:26 2011 Critical (3) SYNC Timing Synchronization failure - Failed to acquire QAM/QPSK symbol timing;;CM-MAC=;CMTS-MAC=;CM-QOS=1.0;CM-VER=3.0;
Tue Nov 22 01:34:11 2011 Critical (3) No UCDs Received - Timeout;;CM-MAC=;CMTS-MAC=00:00:00:00:00:00;CM-QOS=1.0;CM-VER=3.0;
Tue Nov 22 01:34:01 2011 Warning (5) Lost MDD Timeout;CM-MAC=;CMTS-MAC=00:00:00:00:00:00;CM-QOS=1.0;CM-VER=3.0;
Tue Nov 22 01:34:01 2011 Warning (5) MDD message timeout;CM-MAC=;CMTS-MAC=00:00:00:00:00:00;CM-QOS=1.0;CM-VER=3.0;
Tue Nov 22 01:33:52 2011 Critical (3) DHCP FAILED - Requested Info not supported.;CM-MAC=;CMTS-MAC=;CM-QOS=1.0;CM-VER=3.0;
Tue Nov 22 01:33:36 2011 Critical (3) No Ranging Response received - T3 time-out;CM-MAC=;CMTS-MAC=;CM-QOS=1.0;CM-VER=3.0;
Tue Nov 22 01:26:07 2011 Critical (3) DHCP FAILED - Discover sent, no offer received;CM-MAC=;CMTS-MAC=;CM-QOS=1.0;CM-VER=3.0;
Tue Nov 22 01:25:28 2011 Critical (3) Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities received - T4 time out;CM-MAC=;CMTS-MAC=;CM-QOS=1.1;CM-VER=3.0;
Tue Nov 22 01:25:25 2011 Warning (5) Lost MDD Timeout;CM-MAC=;CMTS-MAC=;CM-QOS=1.1;CM-VER=3.0;
Tue Nov 22 01:25:25 2011 Warning (5) MDD message timeout;CM-MAC=;CMTS-MAC=;CM-QOS=1.1;CM-VER=3.0;
Tue Nov 22 01:24:56 2011 Critical (3) SYNC Timing Synchronization failure - Failed to receive MAC SYNC frame within time-out period;CM-MAC=;CMTS-MAC=;CM-QOS=1.1;CM-VER=3.0;
Thu Nov 10 12:48:11 2011 Critical (3) SYNC Timing Synchronization failure - Loss of Sync;CM-MAC=;CMTS-MAC=;CM-QOS=1.1;CM-VER=3.0;
Time Not Established Critical (3) DHCP FAILED - Requested Info not supported.;CM-MAC=;CMTS-MAC=;CM-QOS=1.0;CM-VER=3.0;