Possible Bug in VMNG300 firmware?

[pip08456]

I doubt if it will do it Chrys.

---------- Post added at 18:31 ---------- Previous post was at 18:26 ----------

Originally Posted by craigj2k11

whoops

read again, the channel number and frequency matches on both the superhub and VMNG300 i.e. they are the same, so whatever number they start from, they both start from the same one

So this was a mistake?

Originally Posted by craigj2k11

Right, firstly my little story (ill keep it short):
I had the superhub, was causing me problems, rang CEO office, got VMNG300

when i first typed that it was at least 30 lines!

Anyway the problem:
On the superhub I got channels 125, 126, 127 and 128, this is exactly the same on the modem. however upstream, on the superhub would mostly connect to channel 6, but if i restarted a couple of times it would get channel 5, which seemed a lot less utilised and gave me lower ping. On the modem it only gives me channel 6 (or so it would seem).... i posted on the VM forums and asked why I couldnt get 5 (i spent 45 minutes sat next to the modem pulling the power lead out and plugging it back in (yes im sadundoubtable!)) anyway the guy on VM forums told me that I was connected to channel 5, and double checking the modem stats it said channel 6, so does the modem have a firmware bug where it reports channel 5 as being channel 6?

if it is a bug, i can certainly see why is hasnt been picked up lol, i cant really see how anyone would notice it, unless in the same situation as me

[craigj2k12]

right, your mixing me up now

Both the superhub and the modem report channel 6 upstream on frequency 35800000Hz

There was another channel i used to get, channel 5 (not sure of the frequency) which i got on the superhub. Since installing the modem I have never had channel 6, so i queried it on the VM forum, and they told me I was connected to channel 5, even though the modem said 6.

The channels and their frequencies match up on the superhub and the modem, but obviously both of those count the channels from 1, and the CMTS counts from 0

[Skie]

The the difference in how channels are numbered is probably between the CPE and the systems virgin use.

Virgins starts at 0 while the superhub and bettermodem start counting from 1.

Probably :p

[craigj2k12]

Originally Posted by Skie

The the difference in how channels are numbered is probably between the CPE and the systems virgin use.

Virgins starts at 0 while the superhub and bettermodem start counting from 1.

Probably :p

thats what I said, but i want to know why i cant connect to the less utilised channel, which comes through on the modem as channel 5 and probably on the CMTS as 4

[Skie]

Its probably not any less utilized now. If it was a good channel before, then gradually as modems were rebooted they would have hopped onto it and eventually it would cease to be the channel modems prefer.

That dosent explain why my downstream channels are out of order mind. How on earth it can go 28 27 29 is beyond me. I guess 27 is worse than 28 but better than 29.

[craigj2k12]

Originally Posted by Skie

That dosent explain why my downstream channels are out of order mind. How on earth it can go 28 27 29 is beyond me. I guess 27 is worse than 28 but better than 29.

the superhub puts them out of order since R25, dont know why, it was reported in the beta firmware thread but they said it didnt matter. However the VMNG300 puts them in order

[Chrysalis]

Skie what I remember from when I could use the other channel was if I left the superhub to its own devices, then 9 times out of 10 it would pick the higher utilised channel. If it was a completely random logic then it would be roughly 50% chance of getting either channel. The only time I seen the lower channel was when I emulated fault conditions. The very first time I got on it was after a long outage, then the other times was when I either did a lot of power cycles 20+ or after deliberatly reducing the SNR by half removing the cable. So if anything it appeared to be used as a fallback channel.

Then a change to docsis2 occured and I eventually got the vmng300. Since utilisation remained fairly low I stopped bothering trying to jump channels and I also wrongly thought I stayed on it anyway by the channel id been 7 on the vmng300. Now utilisation is going up again my curioisity is back. However.

1 - is the channel even there anymore it may have been merged into the larger docsis2 channel.
2 - if its there is it still available to use to my modem as VM may have made it unavailable to me.

I will try later to see if I can change channels but wont try forever maybe for 20 minutes or so.

[craigj2k12]

Originally Posted by Chrysalis

Skie what I remember from when I could use the other channel was if I left the superhub to its own devices, then 9 times out of 10 it would pick the higher utilised channel. If it was a completely random logic then it would be roughly 50% chance of getting either channel. The only time I seen the lower channel was when I emulated fault conditions. The very first time I got on it was after a long outage, then the other times was when I either did a lot of power cycles 20+ or after deliberatly reducing the SNR by half removing the cable. So if anything it appeared to be used as a fallback channel.

Then a change to docsis2 occured and I eventually got the vmng300. Since utilisation remained fairly low I stopped bothering trying to jump channels and I also wrongly thought I stayed on it anyway by the channel id been 7 on the vmng300. Now utilisation is going up again my curioisity is back. However.

1 - is the channel even there anymore it may have been merged into the larger docsis2 channel.
2 - if its there is it still available to use to my modem as VM may have made it unavailable to me.

I will try later to see if I can change channels but wont try forever maybe for 20 minutes or so.

well you have the 2 different channels before the 'major' changes to the network, but the network didnt change at all around here and changing to the modem meant that i couldnt find the channel anymore, since having the modem, there was an upstream fault (noise) which was resolved, but still no channel 5. it has to be there somewhere, just a question of finding it

[Chrysalis]

Actually I forgot to consider that the superhub the channel id actually stayed on 7 even tho the frequency changed.

So previously channel 7 was 4.4mhz and channel 8 (higher utilised) was 4.58mhz.
After network changes channel 7 was 4.58mhz on the superhub.
So different frequency but same id.

I think I probably wont get anywhere but i will try anyway.

[pip08456]

Originally Posted by craigj2k11

the superhub puts them out of order since R25, dont know why, it was reported in the beta firmware thread but they said it didnt matter. However the VMNG300 puts them in order

The downstream channel numbers aren't really a cause for concern.
On reboot the modem (or modem side) must lock onto one downstream channel first. All the information the modem needs to operate on the system is sent through that channel. That could explain the out of order channel numbers.

[Chrysalis]

yeah the downstream order isnt an issue, if the first one is highest utilised doesnt matter as the traffic is auto balanced to lowest utilised channels anyway. Thats whats so great about bonding. On the 20mbit service I had to keep hopping downstream channels as when a channel worked well one day it was over utilised the next day.

[pip08456]

That's why with some a little knowledge is dangerous, they tend to look for problems that don't exist or make them suit their problem.

[Chrysalis]

ok I finished playing.

Was harder to do and I also failed.

On the vmng300 if removing the cable it seems it eithers works with normal power levels or doesnt work, I couldnt get it to be partially connected at reduced power levels. The numerous recconections were all on the same channel.

When I tried on the superhub because of bridge mode I had the same problem I had with the vmng300 in that I couldnt keep refreshing the page to check the channel status as I had to keep doing dhcp renew's on the router to keep been able to connect to the GUI, the superhub had an additional problem because of this I couldnt relogin after a dhcp renew due to a ghosted session and the superhub restriction of one login at a time. Nevertherless I did about 10 attempts and all same channel.

So I am stuck with this jitter now until VM do another upgrade.

Pinging 194.168.4.100 with 32 bytes of data:
Reply from 194.168.4.100: bytes=32 time=11ms TTL=252
Reply from 194.168.4.100: bytes=32 time=9ms TTL=252
Reply from 194.168.4.100: bytes=32 time=22ms TTL=252
Reply from 194.168.4.100: bytes=32 time=25ms TTL=252
Reply from 194.168.4.100: bytes=32 time=12ms TTL=252
Reply from 194.168.4.100: bytes=32 time=11ms TTL=252
Reply from 194.168.4.100: bytes=32 time=9ms TTL=252
Reply from 194.168.4.100: bytes=32 time=8ms TTL=252
Reply from 194.168.4.100: bytes=32 time=11ms TTL=252
Reply from 194.168.4.100: bytes=32 time=21ms TTL=252

Ping statistics for 194.168.4.100:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 8ms, Maximum = 25ms, Average = 13ms

It was only 2-3 weeks or so back when ignition signed up and I posted on his thread I had much better then that to the same ip.

[craigj2k12]

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Users\Craig>ping 194.168.4.100 -t

Pinging 194.168.4.100 with 32 bytes of data:
Reply from 194.168.4.100: bytes=32 time=17ms TTL=251
Reply from 194.168.4.100: bytes=32 time=8ms TTL=251
Reply from 194.168.4.100: bytes=32 time=9ms TTL=251
Reply from 194.168.4.100: bytes=32 time=17ms TTL=251
Reply from 194.168.4.100: bytes=32 time=12ms TTL=251
Reply from 194.168.4.100: bytes=32 time=9ms TTL=251
Reply from 194.168.4.100: bytes=32 time=17ms TTL=251
Reply from 194.168.4.100: bytes=32 time=9ms TTL=251
Reply from 194.168.4.100: bytes=32 time=11ms TTL=251
Reply from 194.168.4.100: bytes=32 time=8ms TTL=251
Reply from 194.168.4.100: bytes=32 time=7ms TTL=251
Reply from 194.168.4.100: bytes=32 time=10ms TTL=251
Reply from 194.168.4.100: bytes=32 time=8ms TTL=251
Reply from 194.168.4.100: bytes=32 time=10ms TTL=251

Ping statistics for 194.168.4.100:
    Packets: Sent = 14, Received = 14, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 7ms, Maximum = 17ms, Average = 10ms
Control-C
^C
C:\Users\Craig>

[Chrysalis]

heh I did another and I just about hung onto 10ms average.

Pinging 194.168.4.100 with 32 bytes of data:
Reply from 194.168.4.100: bytes=32 time=10ms TTL=252
Reply from 194.168.4.100: bytes=32 time=7ms TTL=252
Reply from 194.168.4.100: bytes=32 time=5ms TTL=252
Reply from 194.168.4.100: bytes=32 time=10ms TTL=252
Reply from 194.168.4.100: bytes=32 time=9ms TTL=252
Reply from 194.168.4.100: bytes=32 time=8ms TTL=252
Reply from 194.168.4.100: bytes=32 time=6ms TTL=252
Reply from 194.168.4.100: bytes=32 time=17ms TTL=252
Reply from 194.168.4.100: bytes=32 time=9ms TTL=252
Reply from 194.168.4.100: bytes=32 time=6ms TTL=252

Ping statistics for 194.168.4.100:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 5ms, Maximum = 17ms, Average = 8ms

here is some from earlier tho in afternoon. I used to be able to get like this in the evenings also only 2 or so weeks ago. I think VM have dumped some users on my port with some rebalancing.

Pinging 194.168.4.100 with 32 bytes of data:
Reply from 194.168.4.100: bytes=32 time=8ms TTL=252
Reply from 194.168.4.100: bytes=32 time=6ms TTL=252
Reply from 194.168.4.100: bytes=32 time=7ms TTL=252
Reply from 194.168.4.100: bytes=32 time=8ms TTL=252
Reply from 194.168.4.100: bytes=32 time=7ms TTL=252
Reply from 194.168.4.100: bytes=32 time=6ms TTL=252
Reply from 194.168.4.100: bytes=32 time=10ms TTL=252
Reply from 194.168.4.100: bytes=32 time=6ms TTL=252
Reply from 194.168.4.100: bytes=32 time=6ms TTL=252
Reply from 194.168.4.100: bytes=32 time=6ms TTL=252

Ping statistics for 194.168.4.100:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 6ms, Maximum = 10ms, Average = 7ms