CODA-4582 - Open Issues for Investigation

[RogersDave]

*** This post was last edited May 2, 2017 ***

Good morning Community,

As I mentioned in a post two days ago, we have received the next firmware 2.0.10.20 from Hitron. We are currently running initial testing on this version and will push it out to participants in the firmware trial program as soon as it passes initial testing.

However, while running these tests, we discovered abnormal behavior with ICMP and are awaiting feedback from Hitron today to asses how this will be addressed. As soon as I this is confirmed, I’ll update the change log with the correct version information and start pushing it out.

In parallel, we are still working on the following high priority items. In some cases below, I requested affected customers to reach out to me via private message. If you do so, please include your modem MAC address in the subject line (even if we exchange messages daily) as there are a lot of you reaching out to me daily 🙂

UDP Packet Loss

The investigation for what has been reported as UDP packet loss is still ongoing. We have deployed a probe at one fellow forum member on both a CODA-4582 and a CGNM-3552 to collect additional data. We are actively working with Hitron and Intel on the results observed.

Based on what we know so far, in most instances UDP packet loss is coupled with higher uplink usage in the area. Although the impact is noticeable in specific logs (League of Legends), the root cause for the perceivable impact (while playing) is likely related to bufferbloat (see next issue).

Bufferbloat

When comparing the performance of a CODA-4582 to a CGNM-3552 in the same network conditions, the CODA-4582 consistently reports higher bufferbloat when tested on DSLReports.

Update April 12: The solution for this problem will come in two folds. It will require a change in software which will possibly be included in 2.0.10.27 but more likely in 2.0.10.28 and a change in network configuration.

The network configuration change is not compatible with the current firmware so this change will only come after a vast majority of the modems are running the new code. We are however looking at a way to make the change only for specific modems to support testing in the community.

Update April 22: This problem seems resolved in firmware 2.0.10.27

5 GHz WiFi Low range for channels 36 to 48

Lower WiFi channels on the modem have a much smaller range. This is due in part to the limit imposed by Industry Canada to maximum transmit power.

Furthermore, the current automatic channel selection (auto mode) tends to select the lower channels when in similar load conditions.

Workaround: manually select higher channels (149-153-157-161)

Update April 22: The channel selection algorithm has been improved in firmware 2.0.10.27

Loss of OFDM Channel Lock

Under some RF conditions, the modem fails to lock properly on the OFDM channel. This typically result in variable performance.

Update April 12: This problem is resolved in 2.0.10.26T2

List of connected device does not get fully populated

This is a known issue that has been tracked since firmware 2.0.10.13. We are making improvements at every firmware but it is not a perfect system.

The situation is worst after a reboot or firmware upgrade as the list gets reset and must be repopulated as devices renew their DHCP lease.

NAT Loopback not working for wired clients

When setting up port forwarding to an internal server, it is possible for a client on WiFi to reach the server using the external IP/port. If the client is on a wired interface, it doesn't work.

Update April 12: This problem is resolved in 2.0.10.26T2 (not confirmed)

LAN Counters not working

Some customers reported that LAN counters (especially in bridge mode) are reporting inaccurate values.

This problem has been reported to Hitron for investigation.

Unexpected modem reboot

Some customers reported their modem reboots unexpectedly. We have also seen this behavior in our lab.

Update April 12: This problem is resolved in 2.0.10.26T2

Missing SC-QAM Channels

After a reboot, some modems are missing SC-QAM channels. A fix has been implemented in 2.0.10.26T2 to address this behavior but it has not corrected all scenarios.

Investigation continues with Hitron.

WiFi Survey

The WiFi Survey functionality in firmware 2.0.10.26T2 (and possibly before) reports incorrect SSID names.

Guest Network

When connecting to the Guest Network, an error message is displayed "only allow DHCP client to use this wireless".  This has been reported in firmware 2.0.10.26T2.

Update April 22: This issue has been resolved in firmware 2.0.10.27

Update May 2: It seems this issue is not fully resolved and still experienced by some users

---

Future Planned Improvements

The following are items that we are working on in parallel of the above.

• Improvement in WiFi speeds
• Improvement in latency / bufferbloat

Dave

*Edited Labels*

[joelcyyz]

Well it appears as though my gremlins / issues with MAC ID based reserved DHCP addresses are back.  Very frustarted at this point!

Would appreciate any input / insight anyone has to try to fix this once and for all.

Thx!

[wes162]

I am posting an update to my earlier posts in September concerning severe bandwidth loss on my CODA modem after loss of OFDM lock.  At that time, running Firmware .28, after a fresh boot the modem’s WAN status page shows OFDM locked on one receiver and it would run at about 150Mbps for a short while, then after a few minutes speeds decay to 2Mbps and WAN status shows OFDM lock is lost.  At that point, if you disconnect the cable without rebooting, when reconnected, the CM handshakes with the CMTS without OFDM on Docsis 3.0 and runs relatively stable at about 50Mbps.

RogersDave took note of my posting back then and enrolled my modem into a beta of Firmware .33 and this seemed to work well until about late December.  At that time, very similar symptoms reoccurred.  The modem runs at 150Mbps after a fresh boot and decays to 2Mbps after perhaps 10 minutes.  On Firmware .33 however, the WAN status shows OFDM receiver is locked (even though it appears as though it is not) and disconnection and reconnection does not restore any bandwidth.  It appears as though the CM is telling the CMTS it is OFDM locked and running 3.1, and it thinks it is locked and running 3.1, but it is not.

After several weeks of back and forth with the tech support call center, which included several diagnoses of signal noise or strength issues, several White Truck Link-On techs were dispatched who replaced pretty well every connector between my house and the stand down the street (which did move signal strength levels up but didn’t fix anything) they opened a ticket with “Maintenance”   Then the Red Rogers Truck guy showed up and opened all the neighbourhood stands checking for noise, which he attributed to a rogue modem somewhere on the segment, which he found and cut off the network.  Still the problem persisted, so a “Senior Tech” Link-On guy was sent out.  More minor cabling issues repaired, line tests done, and still no fix, so he swapped out the modem (yet again).

The new CODA loaded Firmware .28T2 and ran exactly as it did back in September.  150Mbps for a little while with OFDM lock, once lock lost, 2Mbps, and after cable disconnection/reconnection, it handshakes on Docsis 3.0 running at about 50Mbps stably.  A day later, they push the latest Firmware .33T3 to the modem and the December symptoms return.  150Mbps for a little while with OFDM lock, speeds decay to 2Mbps but CM thinks OFDM locked, cable disconnection/reconnection does nothing.

This appears to me to be so clearly a software issue that I cannot understand why they keep sending over on site techs.  These modems are very buggy and do not work properly with Rogers CMTS hardware.  It seems to be a basic modem handshaking issue and very old school.

The senior tech now plans to return and install the modem at the line tap down the street to test if the problem exists there (essentially to eliminate the whole cable run between the stand and the house) and I expect that it will since the entire line was tested by numerous techs already and my other services, ie. cable TV and telephone work fine.  Everyone has tried to be helpful, so that’s great, but the diagnoses and procedures seem to be missing the obvious.

Maybe the network architects on monitoring this board can fix it.  The field people cannot.

[HughR]

@wes162

Thanks for your report.  It helps me learn about this system.  I'm not up on cable signaling, so I looked up a couple of things.

OFDM is Orthogonal frequency-division multiplexing

The "lock" is as in "phase-locked loop", i.e. that the modem is synchronized with the upstream signal.

It is not a lock in the sense of a computer program.  But it is a computer program that is reporting the lock status.

So: there could be a firmware bug reporting the locking status.

I would *guess* (and I'm not qualified to do so) that the actual locking is in hardware, not software (firmware).  At least some of it would be analogue.  But some bits might be in software.

Rogers seems to have done a lot to eliminate any problem between your modem and the stand.  Are there any other customers on your segment with the CODA?  Are they having problems (they might not notice -- people put up with a lot)?

I haven't noticed a lot of CODA customers reporting this problem.  Maybe we don't know how to find out if OFDM lock has been lost (I don't).  But it suggests that it's not one of these easy-to-diagnose black and white problems with every CODA.

Good luck: 4 months is  along time.

[wes162]

I am not privy to issues with other customers in the area but I have heard mixed things from the Rogers people working on the file.  Some say they do notice issues, mostly with erratic or jittery pings that most people would not notice unless they were gaming or using other latency intense applications, other techs have said they do not see area issues.  There was some area "noise" which Maintenance attributed to a rogue modem, but that tech said it would only have affected upload speeds, not download.

The issue with CODA CM's losing OFDM lock is a well known issue.  The initial post of this thread asks for people to comment on it, which is why I posted here in the first place.  There are other posts, on this thread and others, from other Rogers customers experiencing similar symptoms (ie. fast download after reboot followed by decay).  Not everyone gets into the nitty gritty of why the speeds decay.  Unfortunately out of necessity, I have had to.

[daveinsurgent]

Hi @wes162 - I noticed that my modem also obtains an OFDM lock on boot, and then loses it. However, my speeds are not impacted as far as I can tell. They vary wildly from 400 to 870Mbps (wired, to different speed tests sites and as an aside, I have been fighting an issue of packet loss for months now.

I had a tech come out today, and I pointed out the OFDM behavior and he said the OFDM lock is irrelevant has no impact on performance at all.

It seems very, very hard to get a straight answer out of all the 'superstition' among the different people we are forced to interact with as Rogers customers 😕

[Datalink]

@daveinsurgent, did the tech do anything to address the packet loss issue?  

If the modem is in fact losing the ability to process the OFDM channel after a period of time, that would point to an cable/connector issue in the 200 to 500 Mhz range, where the OFDM channel is running.  This should be a simple process of elimination.  Are your neighbors modems (if they are 4582's) running in DOCSIS 3.1 mode.  If yes, then that points to an issue with your cable or potentially with the port on the local tap.  If the answer is no (and there are other 4582's connected to your local tap), then that points to an issue with the tap itself or with the infrastructure between the tap and the CMTS.  

Rebooting the modem, followed by successful operation, either in DOCSIS 3.0, or 3.1 mode points to some type of cable or connector issue.  The reboot will temporarily resolve the problem, but it does nothing to address the underlying cable/connector fault.  

The time to call tech support is when the modem has lost its OFDM processing.  In theory, its running DOCSIS 3.0 at that point and the question is, what about the other modems connected to the same local tap.  Are there any 4582s connected to that same local tap, and are they running in DOCSIS 3.0 or 3.1 modes?  The answer to that question would point to the source of the problem.  That's an easy check for tech support to carry out.   The answer to that question will also indicate what level of tech is required to resolve the issue, contract tech, Rogers tech or a Maintenance Crew. 

The tech statement that "OFDM lock is irrelevant" points to one of two things, 1: that the modem's indication of OFDM processing can't be relied upon for some reason, or 2: that the tech has absolutely no clue as to why DOCSIS 3.1 has been developed and is being implemented by MSO's around the world.  If that's a typical tech attitude, then those techs that hold that opinion aren't doing Rogers any favors these days, personal opinion.  I'm sure that not all techs hold that opinion, but its disheartening to hear that. 

Edit:  In a manner of speaking, the tech statement that "OFDM lock is irrelevant" could probably considered as partly correct if the modem simply switches over to DOCSIS 3.0 and runs the same data rates, but, that still completely defeats the pupose of developing DOCSIS 3.1 in the first place, along with all of the expense and trouble to develop the 3.1 CMTS equipment and modems and introduce them into service, not only with Rogers, but with any other MSO. 

[daveinsurgent]

Holy quick reply batman!

The (contract) tech snipped and re-crimped the leads of the coax cable coming in to my utility room, and replaced the pad that was installed by the first (contract) tech on Thursday; he said that pad must have been defective. He went outside to the box on the side of my house and said he made sure the ground was good. He said he can't really troubleshoot issues like packetloss, and that any configuration changes to the CODA-4582 gateway after a factory reset should be considered unsupported/unsustainable, especially putting it in to bridge mode and using a different router, since it's "pushing the modem to do things it can't do", and that this is always the cause of peoples problems.

Sorry, I was paraphrasing earlier: he specifically said that OFDM was not used and it going on and off is "Just Rogers doing stuff".

[Datalink]

Grrr, I won't say what comes to mind.  Those statements would imply that the default parameters are the only parameters that he is willing to accept.  What happens when the engineering staff change the default parameters?  What does he say in that case?  

Ok, just to play ball here, if you run the modem in Gateway mode and still have packet loss to the DNS, then you're meeting his restrictive interpretations of what is or is not supported and if you still have packet loss to the DNS, then you're proving that he didn't resolve the issue.  Has the external cable been replaced at any stage of this problem, and is it underground to the local tap, or overhead to a utility pole?  If you're in a period of time where you see packet loss as a regular occurrence, we're talking an occurrence every few seconds or so, call tech support and ask the CSR to ping the modem from the CMTS, or ping the CMTS from the modem.  Either one will do.  When you see packet loss, then the CSR should also see packet loss.  That should be enough to convince the CSR that the problem still exists and that its time to dispatch a senior tech.  Beyond that its time to get @CommunityHelps involved to dispatch a senior (Rogers) tech. 

Fwiw, my own testing with the 4582 in Bridge mode with two routers connected results in very little packet loss over the course of a 24 or 48 hour test run, usually well under 0.1%, sometimes less than 0.01%. 

[daveinsurgent]

This is certainly an exercise in social engineering as much as it is anything.

Depending on who you talk to, there is a reason for everything.  They "ping the modem from their internal tools", which I don't fully understand. Like, I understand it as a mechanism of troubleshooting -- for example, if the modem internal IP (the 7.x.y.z number) does not respond, then boy we have a problem! But if it does work fine, that doesn't disprove the existence of an issue, know what I mean?

If the ping to the Rogers DNS shows problems (which it does), then it's just that that DNS that's a problem, and I have to try google. If google works - for a short period of time - then it's proof I don't have an issue. If Google does have an issue, over a longer time frame, then it's a sign that ICMP is an unreliable troubleshooting protocol and I have to go to the Rogers Speedtest and "that seems to be working and I don't see any signal issues".

I'm capable and possibly willing to write my own custom client-server test software, and run it in a few AWS regions, just to test non-ICMP delivery reliability...

[Datalink]

Ok, can you have a look at the IP address for the modem or the router, depending on what you currently have in place.  If you log into the modem, with it running in gateway mode, you should see two addresses in the upper right hand corner of the STATUS data block.  Those should be an IPV4 address followed by a much longer IPV6 address.  If you're running the modem in Bridge mode with a follow-on router, check the external IP address.  Looking back at your trace, the second hop address (CMTS) is 174.114.112.1, so your IP address should be 174.114.112.xxx, as in anywhere from .2 to .254 if I'm correct here.  I just want to ensure that the CMTS address makes sense considering what your modem or router IP address is.  Assuming that the IP addresses make sense, that would definitely indicate that the CMTS address is a 174 address, although its not what I'm expecting to see.  So, roll with it and lets see where this leads.  Ping the CMTS, looking for packet loss.  Ignore the return times for now.  Lets assume for the sake of the argument that the IP numbers are correct at this point.  If they didn't match up, then that is another issue altogether.  Just run the ping test and lets see how this turns out.  

You can also do the same using IPV6.  Run an IPV6 trace:  tracert -6 www.google.com   If your pc is running IPV6, then you should see the entire trace from start to finish with IPV6 addresses.  Same as before, the first hop is the modem if its running in Gateway mode, 2nd hop is the CMTS.  If the modem is in Bridge mode with a follow-on router, first hop is the router, 2nd hop is the CMTS.  Ping the CMTS using the IPV6 address, again, looking for packet loss. 

Beyond that, if you wanted to ping the DNS using TCP/IP, download tcping64 from:

https://www.elifulkerson.com/projects/tcping.php

A command line to use, if you want to try this is: 

tcping64.exe -t -i 1.0 -d --tee c:\temp\tcping29jan.txt 64.71.255.204 53

That runs a tcp/ip ping to the 64.71.255.204 dns port 53

-t runs the ping test until stopped with a Control^C

-i 1 run the test once per second.  tcping64 will run intervals less than 1 second:  -i 0.50 for example runs every 500 ms.

-d prints a time stamp on every line

--tee c:\temp\tcping29jan.txt    writes the results to a text file as well in the c:\temp directory, if you have such a directory set up.  If you don't want the text file, delete this command 

So, beyond the CMTS, running a TCP/IP test to the DNS will indicate if there are packet loss issues within the Rogers network.  

If you want to do this with a DNS lookup to test UDP thru the modem, I can let you know how to run that as well.  I use a script to run a lookup, using the Rogers DNS, or any other DNS as the target DNS. 

[daveinsurgent]

Cool. I engaged Facebook support - another plug for them being very responsive and candid. They could not connect to my modem - as usual. What seems to happen is after it's been up for 30 minutes or so, something happens. I don't understand anything about cable technology enough to even begin to guess or pretend, but the OFDM lock disappears from the web GUI and support says they can't connect to my modem or that it appears offline, etc. -- this is the same behavior with the original modem and the replaced modem, as well as the changes that the two different on-site techs made (re-crimping wires, checking grounds, etc.)

While that was all going down, I decided to just go back to square 1 and really check my internal network out. I have iperf3 installed on all of my computers.

Here's a professional-grade image/diagram of my network topology:

I can ping 192.168.0.3 (the X4S in AP mode) as well as 192.168.0.2 (the switch) and 192.168.0.1 (the CODA in Gateway mode) aggressively (0.1 interval) and its 0% loss, rock solid, 0.5xx ms worst case ping.

I installed iperf3 on just about everything that I could, and I can run aggressive tests between D1 and D2, as well as D1 and S1 / D2 and S1 -- iperf3 -t 60 -u -b 0 --udp-counters-64bit -c {{ip}} spits out things like:

[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-60.00 sec 6.66 GBytes 953 Mbits/sec 0.030 ms 0/872558 (0%)
[ 4] Sent 872558 datagrams

I may get the occaisional lost packets, like 0.000x% (13 out of 1.75 million was the highest or "worst" run)

I feel like my internal network is "rock solid".  Even my MacBook - so L1 to S1,  pulls an iperf of 628Mbit/sec TCP and UDP:

[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams

[  5]   0.00-30.00  sec  2.10 GBytes   600 Mbits/sec  0.000 ms  0/1553838 (0%)  sender

[  5]   0.00-30.00  sec  2.10 GBytes   600 Mbits/sec  0.029 ms  0/1553838 (0%)  receiver

I think most people would be very happy with such characteristics internallly. I am going to look in to doing UDP/TCP testing of DNS etc. as you've suggested, but after rebooting my modem (in the span of writing this post) its already gone back to losing the OFDM lock and being unresponsive to remote support! Which I think is a good thing, because they're fixing to send a senior ("Rogers"?) tech!

** Edits **

The hop after my modem on a traceroute (my CMTS I guess) is 174.115.212.1 -- it's always "174.115.(X-1).1" if that formula makes sense - so my WAN IP is currently 174.115.213.#

[daveinsurgent]

Well, the adventure continues.

The third tech visit was not a Rogers-branded one, but still a third party contract. However I absolutely believe he was senior as the Facebook Chat agent indicated, because he immediately started telling me things that were useful, rather than telling me things that he didn't know about or weren't his job, etc.  -- so big +1 to this individual.

What's really interesting is he also told me a bunch of stuff completely contradictory - but far more believable - than what I've been told.

This tech: There are many modems in your area that are showing up unresponsive, and I am not sure why

Support: I looked in your area and your modem is the only one offline/not responding

This tech: There's noise/interference in your area that a technical team is trying to hunt down but currently does not know the source of, and the node / CMTS you connect to has concerning noise and issues as well

Support: Your area is fine

This tech: Losing OFDM is concerning, but it would not affect your download speeds. It would affect your upload speeds

Other tech: OFDM does not matter, it is not used

This tech: The line from your CME to the road box is faulty, must be replaced, and we need to run a temporary line from your neighbour until spring. Only after we install the temporary line can we continue to troubleshoot any remaining issues with packetloss - also why aren't you using the modem in bridge mode given the router that you have?

Other tech: There's no problem, we don't deal with packetloss, you must use the modem in gateway mode and not change settings

So, happy that I have someone who will help, but it looks like this is really the beginning of the actual troubleshooting.

[wes162]

Posting an update to my earlier posts concerning my problems with Coda modem losing OFDM lock shortly after reboot, resulting in dramatic loss of bandwidth.

Senior "supervisor" arrived and did troubleshooting, swapped out various connectors, swapped out the modem, problem continued.  Then he took the modem outdoors, to the cable "tap" out on the curb a few homes down the street, connected it there, and problem continued.  At that point, he could go no further and had to open another maintenance ticket.

A few days later, he told me that maintenance traced the problem to the segment between the "node" and the "tap" and that it would be a "big job" to fix this segment so it is likely not going to happen anytime soon.  He brought me an older CGN3ACR modem, which is a Docsis 3.0 modem, only 24 channels without OFDM and it has been running fine now for almost a week without issues.  This is ok for me since I'm getting close to 200Mbps and I do not need the higher speeds.  Gigabit internet would not work on this tap until they can repair the noisy segment.  Be careful about this in your area if you are upgrading your packages or your modems because the Coda's need a very clean signal to work properly, and they are not smart enough to handshake with the CMTS on a different protocol when they are experiencing problems.  No doubt the Coda could have run properly on 32 channels on Docsis 3.0 without OFDM but either it isn't programmed to do that (or the CMTS isn't telling it to) when problems are experienced on the line.

No repair here, but at least we have a workaround for now.  The "supervisor" guy was very helpful.  Finally someone took the issue seriously after about 6 months of back and forth with the call center. 

[Datalink]

@wes162 if you were to swap out the CGN3ACR for a CGNM-3552 which is a 32 channel modem, you should see very close to 950 Mb/s on the downstream side. 

In theory, the CODA-4582 should run 32 channel DOCSIS 3.0 without any issues.  This makes me wonder if there is some issue with the DOCSIS 3.0 side of the modem.  On the other hand, if there are major issues between the tap and the CMTS, then its possible that gigabit DOCSIS 3.0 operation isn't possible either.  

[daveinsurgent]

The tech that just visited me said that OFDM, even on the downstream, only improves upstream performance. I try not to make it a debate - especially since I don't know anything for sure anyway - but it didn't pass my HowShouldThisThingProbablyWork smell test.

When I lose OFDM on the CODA, I can't break 300Mbit.

[wes162]

OFDM is just a form of signal compression, squeezing more data into a tighter RF spectrum.  It can work both upstream or downstream, but I think the Rogers cable modems and CMTS's are programmed only to use it for the downstream channels.  There isn't too much need for it on upstream since most customers aren't running server farms that need lots of upstream.

[daveinsurgent]

Right, he insisted that the downstream OFDM compression's only purpose was to provide more room to the upstream -- I didn't buy that explanation, but I didn't want to argue with someone who was being otherwise much more helpful than those that preceded him.

[RyzenFX]

Interesting.... OFDM is much more resilient to noise than SC-QAM and despite having the .33 firmware, you still get the loss of OFDM lock. 

If you are on the plans that are below the Ignite Gigabit plan, I wouldn't worry too much. OFDM increases the bandwidth on the downstream literally by tenfold when compared to DOCSIS 3.0; it really only  enables Rogers  to deliver a consistent 1Gbps for their Ignite Gigabit subscribers. (As a gamer I see this in a totally different way b/c it actually reduces ping times due to it being much more resilient to noise and less prone to packet dropping during peak times due to the substantial amount of bandwidth it provides).

@daveinsurgent I think the technician was actually referring to OFDM in terms of the upstream side of things. He is technically right. OFDM in the upstream would be called OFDMA and it does provide more bandwidth. DOCSIS 3.0 standards can provide up to 100Mbps on the upstream, but DOCSIS 3.1 brings that up tenfold to 1Gbps. Lots of areas are struggling due to congestion, so this will also help relieve congestion.

[holtzkener]

How to increaase speed of Hitron CODA-4582U router switched ports:

My configuration is not BRIDGED. Native WiFi is quite fast but "buffers" often making watching streaming sites unpleasant to watch.

I have my AppleTV, Sony AndroidTV and Sony BR player connected directly to the switched ports on the CODA-4582U because these devices are close enough, six feet, expecting this to offload the WiFi traffic. This eliminated the buffering problem. Also there are many, perhaps 35 nearby WiFi access points, that I believe are causing a slowdown of required high speed transmissions over WiFi There are a number of devices,  two computers and a printer on WiFi.

I get 150Mb+ download and 15Mb+ upload speeds on my MAC over wifi using the Rogers Test.

Using the NETFLIX connection speed test, I get 100Mb over WiFi

BUT

ONLY 50Mb when connected to any of the switched ports.

Also, the modem URL has a settings page, not modifiable, that shows the switched ports at 100M.

Does this have any effect and how can this setting be increased?

I would like to be able to operate the switched ports faster, within QoS limits.

Can QoS be adjusted to allow higher switched port speeds?

Thanks

Barry

[Datalink]

@holtzkener, the ports on the modem will negotiate a data rate with the connected device.  The 4582 has gigabit ports, so, if you look at the back of the modem, specifically the connected port LEDs, they should be flashing amber for a 1 gigabit connection rate, flashing green for 10/100 Mb/s connection rate.  If you're not seeing a 1 gigabit connection rate to a connected device that could be the be the result of:

1.  The connected device only having a 10/100 Mb/s port built in; or

2.  The connecting ethernet cable has been damaged in some fashion and no longer has all 4 wire pairs in operation to support a 1 gigabit connection rate.  That requires all 4 wire pairs in the cable to be connected end to end.  Fast Ethernet cables, which some people have hanging around only support 100 Mb/s as they would only have two of the 4 wire pairs connected end to end; or

3.  The ethernet cable is not connecting at one or both ethernet ports; or

4.  The remote device, despite having a gigabit port, is only set to run that port at 10/100 Mb/s; or

5.  If the cable run to the remote device uses house ethernet wiring, then there is a possibility that the wall ports are not connected to all 4 wire pairs at some or all locations; or

6.  If a switch is used in conjunction with house cabling, perhaps the switch is a 10/100 Mb/s switch instead of a gigabit switch.

7.  If a device is connected to the modem and that device is known to operate at 1 Gibabit/sec with other modems and routers, using the same cable, that points to a port controller failure on the modem.  Swap the modem at the nearest Rogers store. 

When you run a speed test, use the www.speedtest.net Toronto Rogers or Montreal Rogers servers.  Next choice would be the www.speedtest.net Toronto Beanfield or Montreal Fibrenoire servers.

Edit: added item #7.

Hope this helps.

[holtzkener]

Thanks.

This all sounds good.

The lights on the connectors are amber indicating Gigabit.

What confused me was the fact that the ethernet connection went at speed using the same 6 ft. cable before I upgraded to the 4582 and now is slower. That's why I am looking at the router.

Also, the fact that the wifi is faster made no sense.

I'll try try different cables where I can see all 4 pairs connected and try again.

Thanks a lot. I hadn't considered the cables as a possibility, not did I know what the light's colours meant.

Barry

ps do you have a reference to the URL for the manual?