![]() |
Re: Possible Bug in VMNG300 firmware?
I doubt if it will do it Chrys.
---------- Post added at 18:31 ---------- Previous post was at 18:26 ---------- Quote:
Quote:
|
Re: Possible Bug in VMNG300 firmware?
right, your mixing me up now :D
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 |
Re: Possible Bug in VMNG300 firmware?
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 |
Re: Possible Bug in VMNG300 firmware?
Quote:
|
Re: Possible Bug in VMNG300 firmware?
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. |
Re: Possible Bug in VMNG300 firmware?
Quote:
|
Re: Possible Bug in VMNG300 firmware?
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. |
Re: Possible Bug in VMNG300 firmware?
Quote:
|
Re: Possible Bug in VMNG300 firmware?
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. |
Re: Possible Bug in VMNG300 firmware?
Quote:
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. |
Re: Possible Bug in VMNG300 firmware?
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.
|
Re: Possible Bug in VMNG300 firmware?
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.
|
Re: Possible Bug in VMNG300 firmware?
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. |
Re: Possible Bug in VMNG300 firmware?
Code:
Microsoft Windows [Version 6.1.7601] |
Re: Possible Bug in VMNG300 firmware?
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 |
| All times are GMT. The time now is 16:36. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2026, vBulletin Solutions Inc.
All Posts and Content are © Cable Forum