Slow Speeds Now After 9pm

[VMboy]

I have noticed the speeds around this time of 21:04 are really slow.

Any reason for this?

[Peter_]

As you have not posted anything such as modem power levels and of course your area then no reason.:D

[pip08456]

I have noticed the speeds around this time of 21:04 are really slow.

Any reason for this?

You should really know by now that a generalisation like this helps no-one, you included.

You've used the site enough to know that without any modem stats your problem is impossible to ascertain.

[VMboy]

Cable Modem Downstream
Downstream Lock : Locked
Downstream Channel Id : 4
Downstream Frequency : 331000000 Hz
Downstream Modulation : QAM256
Downstream Symbol Rate : 5360.537 Ksym/sec
Downstream Interleave Depth : taps32Increment4
Downstream Receive Power Level : 5.5 dBmV
Downstream SNR : 38.7 dB

-----------------------------------------------------------

Cable Modem Upstream
Upstream Lock : Locked
Upstream Channel ID : 1
Upstream Frequency : 18800000 Hz
Upstream Modulation : QAM16
Upstream Symbol Rate : 2560 Ksym/sec
Upstream transmit Power Level : 55.0 dBmV
Upstream Mini-Slot Size : 2

[Peter_]

Upstream slightly high but still within range so possibly a local glitch, you could call support but you will get offshore so if no different in the morning call in and we will run some checks.

[VMboy]

Upstream slightly high but still within range so possibly a local glitch, you could call support but you will get offshore so if no different in the morning call in and we will run some checks.

Many thanks, did you think the downstream looks ok?

[pip08456]

Upstream slightly high but still within range so possibly a local glitch, you could call support but you will get offshore so if no different in the morning call in and we will run some checks.

Or if he has a lot of time he could do the run-around with offshore:D

[VMboy]

Or if he has a lot of time he could do the run-around with offshore:D

Had enough with offshore I can tell you, will wait till the morning.

[jb66]

Traffic managed?

[pip08456]

Many thanks, did you think the downstream looks ok?

If there was a problem with the downstream do you really think Masque would not have mentioned it?

[VMboy]

If there was a problem with the downstream do you really think Masque would not have mentioned it?

I just wanted him to elaborate on it and sorry if these things annoy you.

Here is a test using I.E.

https://www.cableforum.co.uk/images/local/2010/05/54.png (http://www.speedtest.net)

---------- Post added at 23:38 ---------- Previous post was at 23:25 ----------

Traffic managed?

What do you mean by traffic managed, are you referring to the fact that I may have gone over my limit, or perhaps just the normal traffic management in general?

I kind of ask as I haven't downloaded in the last 5 hours and more.

[broadbandking]

From your upload your not traffic managed, maybe local congestion, your power levels are fine must be a local issue maybe a glitch or congestion issue.

[pip08456]

I just wanted him to elaborate on it and sorry if these things annoy you.

No don't annoy me at all, just that idiot over at the VM site!
And you should know better.

Can you post your modem logs?

[VMboy]

No don't annoy me at all, just that idiot over at the VM site!
And you should know better.

Can you post your modem logs?

What idiot are you referring to?

I had already posted my modem logs earlier, but I will do them again, however to get those speeds from speedtest site I had to do unplug the modem for a few minutes, but should I need to do this every time I notice my downloads to be slow?

Is it the downstream and upstream levels you want me to post?

[Sephiroth]

We could do with the event log and another look at upstream. If you take a few upstream readings and not e values, we can see if it's fluctuating up to 58 dBmv, which is bad.

[Peter_]

Many thanks, did you think the downstream looks ok?
Your stats are within operational parameters so any issue would be local.

[VMboy]

We could do with the event log and another look at upstream. If you take a few upstream readings and not e values, we can see if it's fluctuating up to 58 dBmv, which is bad.

Event log below, sorry but not sure how to and what you mean you want upstream readings but not e values? The upstream at the moment is Upstream transmit Power Level : 55.0 dBmV

Thu May 06 22:11:49 2010 Thu May 06 22:11:49 2010 Information (7) The s/w filename specified in the config file is the same as ...
Thu May 06 22:11:49 2010 Thu May 06 22:11:49 2010 Information (7) A software upgrade filename was specified in the config file.
Thu May 06 22:11:49 2010 Thu May 06 22:11:49 2010 Information (7) Authorized
Thu May 06 22:11:49 2010 Thu May 06 22:11:49 2010 Information (7) Registration complete!
Thu May 06 22:11:49 2010 Thu May 06 22:11:49 2010 Information (7) We registered with a DOCSIS 1.1 config file!
Thu May 06 22:11:49 2010 Thu May 06 22:11:49 2010 Information (7) Received a REG-RSP message from the CMTS...
Thu May 06 22:11:48 2010 Thu May 06 22:11:48 2010 Information (7) Sending a REG-REQ to the CMTS...
Thu May 06 22:11:48 2010 Thu May 06 22:11:48 2010 Information (7) CableModem SNMP configure complete
Thu May 06 22:11:48 2010 Thu May 06 22:11:48 2010 Information (7) IP init completed ok
Thu May 06 22:11:48 2010 Thu May 06 22:11:48 2010 Information (7) CableModem TFTP init ok
Thu May 06 22:11:48 2010 Thu May 06 22:11:48 2010 Information (7) CableModem DHCP client init ok
Thu May 06 22:11:48 2010 Thu May 06 22:11:48 2010 Critical (3) DHCP WARNING - Non-critical field invalid in response.
Time Not Established Time Not Established Information (7) MAP w/initial maintenance region received
Time Not Established Time Not Established Information (7) Downstream sync ok
Time Not Established Time Not Established Information (7) Beginning initial ranging...
Time Not Established Time Not Established Information (7) downstream time sync acquired...
Time Not Established Time Not Established Information (7) Downstream sync ok
Time Not Established Time Not Established Information (7) starting ds time sync acquisition...
Time Not Established Time Not Established Information (7) Locked on the downstream. Waiting for UCDs...
Time Not Established Time Not Established Information (7) Downstream lock ok
Time Not Established Time Not Established Information (7) Sync Start
Thu May 06 21:07:53 2010 Thu May 06 21:07:53 2010 Critical (3) DHCP WARNING - Non-critical field invalid in response.
Thu May 06 20:50:18 2010 Thu May 06 20:50:18 2010 Critical (3) DHCP WARNING - Non-critical field invalid in response.
Time Not Established Time Not Established Critical (3) No Ranging Response received - T3 time-out
Time Not Established Time Not Established Critical (3) No Ranging Response received - T3 time-out

[Sephiroth]

Thanks for the event log. I was asking you to produce stats in quick succession and note the upstream power and whether or not it is moving around. I was looking for a string of T3 errors in the event log, which are not present. Had they been, I would have expected upstream power variability which you have yet to confirm.

If your upstream power is steady then VM will need to examine the noise level at the CMTS.

[VMboy]

Thanks for the event log. I was asking you to produce stats in quick succession and note the upstream power and whether or not it is moving around. I was looking for a string of T3 errors in the event log, which are not present. Had they been, I would have expected upstream power variability which you have yet to confirm.

If your upstream power is steady then VM will need to examine the noise level at the CMTS.

The upstream seems to be steady at 55.0 dBmV
The downstream level is the one that moves around, at the moment it's moving around Downstream Receive Power Level : 5.8 dBmV
Downstream SNR : 39.2 dB

---------- Post added at 09:39 ---------- Previous post was at 09:28 ----------

Result with no proxy used using FF.

https://www.cableforum.co.uk/images/local/2010/05/50.png (http://www.speedtest.net)

Result with proxy using FF, this proxy is used for anti virus program.

https://www.cableforum.co.uk/images/local/2010/05/51.png (http://www.speedtest.net)

Result using I.E with no proxy.

https://www.cableforum.co.uk/images/local/2010/05/52.png (http://www.speedtest.net)

Result using I.E with proxy.

https://www.cableforum.co.uk/images/local/2010/05/53.png (http://www.speedtest.net)

The thing I wanted to say is that I didn't get these kind of speeds last night.

[Peter_]

What is the operational config can you please post it.

[VMboy]

What is the operational config can you please post it.

Certainly, here it is.

Cable Modem Operation Configuration
Network Access : Allowed
Maximum Downstream Data Rate : 10240000
Maximum Upstream Data Rate : 512000
Maximum Upstream Channel Burst : 1600
Maximum Number of CPEs : 1
Modem Capability : Concatenation Enabled, Fragametation Enabled, PHS Enabled

[Sephiroth]

I think we've had some of this discussion before. The DS power variation is normal. If temperature is stable, power/SNR will vary +/- ½ dBmv/dB.

But that wretched AV system you use (wretched because of the proxy). You've got built in slow down there because you're at the mercy of your proxy link.

I'm guessing with regard to last night, though. My guess is that you hit congestion. The stats we've seen don't show anything amiss. But if you do some downloads and then post the event log (not having rebooted the modem), there may be more information.

[VMboy]

But that wretched AV system you use (wretched because of the proxy). You've got built in slow down there because you're at the mercy of your proxy link.

I have these slow speeds after 9pm even with the non proxy usage but as you say it could be congestion.


But if you do some downloads and then post the event log (not having rebooted the modem), there may be more information.

Will Do.

[Peter_]

Certainly, here it is.

Cable Modem Operation Configuration
Network Access : Allowed
Maximum Downstream Data Rate : 10240000
Maximum Upstream Data Rate : 512000
Maximum Upstream Channel Burst : 1600
Maximum Number of CPEs : 1
Modem Capability : Concatenation Enabled, Fragametation Enabled, PHS Enabled
You are on 10Mb and you have only posted one speed test under 6Mb all the rest are over 8Mb, so without checking your account it appears to be a fairly normal connection. remember that it is sold as an up to 10Mb service.;)

Post your speeds tonight so that we can compare them.

[VMboy]

Post your speeds tonight so that we can compare them.

Will do and thanks.

[pip08456]

Just as a matter of interest what AV prog are you using?

[Ignitionnet]

I have noticed the speeds around this time of 21:04 are really slow.

Any reason for this?

Some areas see a usage spike just after 9PM due to the STM measuring being over at that time.

if all else is as it should be don't worry. The only evidence of an issue so far is your antivirus proxy slowing things slightly. Apart from that it's just as you were.

[VMboy]

Just as a matter of interest what AV prog are you using?

It's Avast 4.8, and the web shield only works if a localhost proxy is used.

I must say however I have often seen a decent speed download even with the proxy being activated.

[VMboy]

Post your speeds tonight so that we can compare them.

All seems to be fine right now, but thought to post the info as requested.

Firefox with Proxy

https://www.cableforum.co.uk/images/local/2010/05/46.png (http://www.speedtest.net)
__________________________________________________ __________________________________
Firefox without Proxy

https://www.cableforum.co.uk/images/local/2010/05/47.png (http://www.speedtest.net)
__________________________________________________ __________________________________

I.E with Proxy

https://www.cableforum.co.uk/images/local/2010/05/48.png (http://www.speedtest.net)
__________________________________________________ __________________________________
I.E without Proxy

https://www.cableforum.co.uk/images/local/2010/05/49.png (http://www.speedtest.net)

Cable Modem Downstream
Downstream Lock : Locked
Downstream Channel Id : 4
Downstream Frequency : 331000000 Hz
Downstream Modulation : QAM256
Downstream Symbol Rate : 5360.537 Ksym/sec
Downstream Interleave Depth : taps32Increment4
Downstream Receive Power Level : 5.9 dBmV
Downstream SNR : 39.1 dB
__________________________________________________ __________________________

Cable Modem Upstream
Upstream Lock : Locked
Upstream Channel ID : 1
Upstream Frequency : 18800000 Hz
Upstream Modulation : QAM16
Upstream Symbol Rate : 2560 Ksym/sec
Upstream transmit Power Level : 55.0 dBmV
Upstream Mini-Slot Size : 2
__________________________________________________ __________________________

Cable Modem Operation Configuration
Network Access : Allowed
Maximum Downstream Data Rate : 10240000
Maximum Upstream Data Rate : 512000
Maximum Upstream Channel Burst : 1600
Maximum Number of CPEs : 1
Modem Capability : Concatenation Enabled, Fragametation Enabled, PHS Enabled
__________________________________________________ ________________________

Cable Modem Status
Item Status Comments
Acquire a Downstream Channel 331000000 Hz Locked
Connectivity State OK Operational
Boot State OK Operational

[Peter_]

Looks more like an issue with Firefox as everything else is fine.

[VMboy]

Looks more like an issue with Firefox as everything else is fine.

Many thanks.

[VMboy]

I had to reset the modem as the speeds were bad again this morning, and I notice now that the speeds are back to normal I have also noticed a few other changes to the modem info, for example.....

The changes are in bold, first previously
Downstream Frequency was 331000000 and now it's 339000000 Hz
And Downstream Channel ID was 4 now it is 5


Cable Modem Downstream
Downstream Lock : Locked
Downstream Channel Id : 5
Downstream Frequency : 339000000 Hz
Downstream Modulation : QAM256
Downstream Symbol Rate : 5360.537 Ksym/sec
Downstream Interleave Depth : taps32Increment4
Downstream Receive Power Level : 5.7 dBmV
Downstream SNR : 39.1 dB

__________________________________________________

Cable Modem Upstream
Upstream Lock : Locked
Upstream Channel ID : 2 this was 1 previously
Upstream Frequency : 22200000 Hz this was 18800000 Hz previously
Upstream Modulation : QAM16
Upstream Symbol Rate : 2560 Ksym/sec
Upstream transmit Power Level : 54.0 dBmV
Upstream Mini-Slot Size : 2

Why is it the speeds go back to what I would normally expect at this time of the morning after resetting the modem?

[Sephiroth]

You can be provisioned with any available channel in the pool. If you switch your modem off and someone else switches their modem on, your previous channels are available to someone else.

Did we cover the question of your upstream power level? If you did 5 sets of stats in a minute and noted your upstream and report it, we can judge if that's a problem (which I think it is if you're having problems out of peak hours).

[VMboy]

Did we cover the question of your upstream power level? If you did 5 sets of stats in a minute and noted your upstream and report it, we can judge if that's a problem (which I think it is if you're having problems out of peak hours).

I'm not really sure if we did or not, how do I do this?

[Sephiroth]

You know how to do your modem stats. 5 in a row and what's the US in each case?

[VMboy]

You know how to do your modem stats. 5 in a row and what's the US in each case?

Do you want me to do this when the problem is there or at any time?

And I take it all you want is the US level 5 times in succession in a space of one minute.

[Sephiroth]

At any time. Space of 30 secs if possible. In any case under a minute.

I'm trying to see if the modem is rising above the 55 dBmv level.
And another event log to see if there are T3s in succession. Try not to cold start the modem - it makes diagnosis very difficult.

[VMboy]

Just so I get this right, you want me to go to the Cable Modem Upstream, and just report the line for Upstream transmit Power Level, and just to hit refresh page every 30 seconds?

And also the event log.

[Sephiroth]

Yep - that's it, notng the upstream each time. Event log needed at the end of the 5 refreshes only.

[VMboy]

Yep - that's it, notng the upstream each time. Event log needed at the end of the 5 refreshes only.

30 Second Intervals

Upstream transmit Power Level : 54.0 dBmV
Upstream transmit Power Level : 54.0 dBmV
Upstream transmit Power Level : 54.0 dBmV
Upstream transmit Power Level : 54.0 dBmV
Upstream transmit Power Level : 54.0 dBmV

Cable Modem Event Log

First Time Last Time Priority Description
Mon May 10 15:43:37 2010 Mon May 10 15:43:37 2010 Critical (3) Started Unicast Maintenance Ranging - No Response received - ...
Sun May 09 23:55:13 2010 Sun May 09 23:55:13 2010 Information (7) The s/w filename specified in the config file is the same as ...
Sun May 09 23:55:13 2010 Sun May 09 23:55:13 2010 Information (7) A software upgrade filename was specified in the config file.
Sun May 09 23:55:13 2010 Sun May 09 23:55:13 2010 Information (7) Authorized
Sun May 09 23:55:12 2010 Sun May 09 23:55:12 2010 Information (7) Registration complete!
Sun May 09 23:55:12 2010 Sun May 09 23:55:12 2010 Information (7) We registered with a DOCSIS 1.1 config file!
Sun May 09 23:55:12 2010 Sun May 09 23:55:12 2010 Information (7) Received a REG-RSP message from the CMTS...
Sun May 09 23:55:12 2010 Sun May 09 23:55:12 2010 Information (7) Sending a REG-REQ to the CMTS...
Sun May 09 23:55:12 2010 Sun May 09 23:55:12 2010 Information (7) CableModem SNMP configure complete
Sun May 09 23:55:12 2010 Sun May 09 23:55:12 2010 Information (7) IP init completed ok
Sun May 09 23:55:12 2010 Sun May 09 23:55:12 2010 Information (7) CableModem TFTP init ok
Sun May 09 23:55:12 2010 Sun May 09 23:55:12 2010 Information (7) CableModem DHCP client init ok
Sun May 09 23:55:12 2010 Sun May 09 23:55:12 2010 Critical (3) DHCP WARNING - Non-critical field invalid in response.
Time Not Established Time Not Established Information (7) MAP w/initial maintenance region received
Time Not Established Time Not Established Critical (3) No Ranging Response received - T3 time-out
Time Not Established Time Not Established Information (7) MAP w/initial maintenance region received
Time Not Established Time Not Established Critical (3) No Ranging Response received - T3 time-out
Time Not Established Time Not Established Information (7) MAP w/initial maintenance region received
Time Not Established Time Not Established Information (7) Downstream sync ok
Time Not Established Time Not Established Information (7) Beginning initial ranging...
Time Not Established Time Not Established Information (7) downstream time sync acquired...
Time Not Established Time Not Established Information (7) Downstream sync ok
Time Not Established Time Not Established Information (7) starting ds time sync acquisition...
Time Not Established Time Not Established Information (7) Locked on the downstream. Waiting for UCDs...
Time Not Established Time Not Established Information (7) Downstream lock ok
Time Not Established Time Not Established Critical (3) Received Response to Broadcast Maintenance Request, But no Un...
Time Not Established Time Not Established Information (7) Reset downstream scanning state!
Time Not Established Time Not Established Information (7) MAP w/initial maintenance region received
Time Not Established Time Not Established Critical (3) No Ranging Response received - T3 time-out
Time Not Established Time Not Established Information (7) MAP w/initial maintenance region received
Time Not Established Time Not Established Critical (3) No Ranging Response received - T3 time-out
Time Not Established Time Not Established Information (7) MAP w/initial maintenance region received

[Sephiroth]

Thanks for taking the trouble. It looks like the upstream power is stable. This tells you that the CMTS at the VM end is satisfied that it can talk to your cable mode. he event log also shows stability today. Most significantly, no T3 timeouts.

I'd say, judging by the event log, that whever afflicted the network at the weekend has passed. Things should be back to normal now.

Does that seem right to you?

[VMboy]

I suppose so,

What I will say though is when the problem occurred the Upstream transmit Power Level was 55.0 dBmV

[Andrewcrawford23]

I suppose so,

What I will say though is when the problem occurred the Upstream transmit Power Level was 55.0 dBmV
repeat the process when the problem occur but 55 should be fine although each ubr has its only tolrance i would be surpised if it couldnt handle 55

[Sephiroth]

repeat the process when the problem occur but 55 should be fine although each ubr has its only tolrance i would be surpised if it couldnt handle 55

The UBR doesn't have to handle 55 dBmv.

By the time it reaches the UBR from the CM, the power level should be 0 dBmv (in the ideal world). The UBR is like the CM and has a similar power sensitivity range - so for example if it reaches the UBR at -5 dBmv that would prolly be OK. When it asks the CM to spew out at 55 dBmv, it's to overcome noise on the line that otherwise makes the CM unreadable at the UBR.

IMO it's not a good circuit that needs to drive the CM so hard.

[VMboy]

Sephiroth,

Shall I repeat the process when I have the slow speeds?

[Sephiroth]

Sephiroth,

Shall I repeat the process when I have the slow speeds?

Actually yes. T3 errors can occur because of congestion. If they don't occur when there's no congestion but they do in the evening when there is potential congestion, then we have the likely answer.

[VMboy]

Ok Seph, will do.

[Ignitionnet]

By the time it reaches the UBR from the CM, the power level should be 0 dBmv (in the ideal world). The UBR is like the CM and has a similar power sensitivity range - so for example if it reaches the UBR at -5 dBmv that would prolly be OK. When it asks the CM to spew out at 55 dBmv, it's to overcome noise on the line that otherwise makes the CM unreadable at the UBR.

It should be whatever VM set it to be, they set a target receive power based on a number of factors.

Transmit power doesn't rise to overcome noise generally, when it does it's quite obvious and accompanied by copious amounts of T3 timeouts and disconnections. It rises to overcome attenuation.

If a modem hits the CMTS at -5dBmV and target is +3 the CMTS will have the modem adjust the required 32 notches, which will also increment the power adjustment field on the flap list of the CMTS.

A stable 55 is quite acceptable, the Ambits will actually go as high as 61.

---------- Post added at 12:25 ---------- Previous post was at 12:22 ----------

Actually yes. T3 errors can occur because of congestion. If they don't occur when there's no congestion but they do in the evening when there is potential congestion, then we have the likely answer.

T3 timeouts do not occur due to high load on the upstream or downstream.

[VMboy]

So no need to post any more results then?

[Ignitionnet]

No.

I'm still lost as to what the actual issue is beyond that your antivirus proxy sucks. Tests posted with it not in place have been fine and zero evidence of issues from any of the other pasted information beyond that people must be really bored going by how much they've indulged this 4 pages of apparent non-issue.

[VMboy]

No.

I'm still lost as to what the actual issue is beyond that your antivirus proxy sucks. Tests posted with it not in place have been fine and zero evidence of issues from any of the other pasted information beyond that people must be really bored going by how much they've indulged this 4 pages of apparent non-issue.

I am sorry but it is an issue! even someone in Virgin Media agrees as such.

I often experience slow speeds with or without that proxy, so please don't look at these speedtests as quite frankly I won't be using that site again as they give out completely wrong information.

As I have said when the problem exists I have tried downloading the blueyonder game files after say 11pm, and even without that proxy the speeds have been atrocious, so how you can say it's an apparent non-issue beggars belief.

---------- Post added at 13:36 ---------- Previous post was at 13:25 ----------

No.
Tests posted with it not in place have been fine and zero evidence of issues from any of the other pasted information beyond that people must be really bored going by how much they've indulged this 4 pages of apparent non-issue.

Perhaps if you had read the bottom of this post.

http://www.cableforum.co.uk/board/35016065-post19.html

[pip08456]

The thing I wanted to say is that I didn't get these kind of speeds last night.

But were you using the crappy AV prog at the time.

As Igni states it would appear everything is OK except when the proxy is in use for the AV prog you are running.

[Ignitionnet]

I am sorry but it is an issue! even someone in Virgin Media agrees as such.

Not in this thread and that's all I have to go by.

I often experience slow speeds with or without that proxy, so please don't look at these speedtests as quite frankly I won't be using that site again as they give out completely wrong information.

So why post them?

As I have said when the problem exists I have tried downloading the blueyonder game files after say 11pm, and even without that proxy the speeds have been atrocious, so how you can say it's an apparent non-issue beggars belief.

I could say that because you only mentioned it now, hence from the point of view of everyone besides you it's an 'apparent non-issue'.

Perhaps if you had read the bottom of this post.

http://www.cableforum.co.uk/board/35016065-post19.html

I did - if it was so bad why didn't you get some readings then?

I would not be at all surprised if things slow down a bit after 9PM, STM measurement goes off and some people will have downloads queued and ready to go. Speeds aren't guaranteed, bandwidth is shared, etc, etc, you know the score.

As it is the thread is 4 pages of total waffle. It would seem to me that the most likely course of events is simply that there's a spike of utilisation on some of the channels serving your area after 9PM. This was noted on my own service when I was on the old network.

Basic troubleshooting:

Issue: Slowdown shortly after 9PM.
Test: What changes at 9PM?
Answer: Traffic management measurement is no longer active.

Conclusion: Likely a load spike caused by traffic management no longer being active.

Evidence: Outside of this period performance reported as normal.

[VMboy]

I posted them because I was asked to post them.

---------- Post added at 15:11 ---------- Previous post was at 15:08 ----------

But were you using the crappy AV prog at the time.

As Igni states it would appear everything is OK except when the proxy is in use for the AV prog you are running.

This crappy program that you call it is Avast which is a well known Anti Virus program.

It's nothing to do with the use of the program, neither is it anything to do with the proxy as I have already said the speedtest site is giving out incorrect results.

[pip08456]

Tha Anti-Virus part of the program is indeed good. It's the web protection side using a proxy that is the problem

[VMboy]

Tha Anti-Virus part of the program is indeed good. It's the web protection side using a proxy that is the problem

Yes I know, but I have also said that the problem occurs even when I switch the proxy off.

[Connor80]

I have recently started to experience slowdown on my Virgin media broadbad after around 10pm, apologies for my lack of knowledge but how do i go about addressing this, or providing any info to help guys on the forums address it?

Many thanks

[pip08456]

I have recently started to experience slowdown on my Virgin media broadbad after around 10pm, apologies for my lack of knowledge but how do i go about addressing this, or providing any info to help guys on the forums address it?

Many thanks

First you will get help more quickly if you start your own thread detailing the full exxtent of the problem.

Also include the following from the modem pages.



Config page

Upload page

Download page

Log file.

To get these enter 192.168.100.1 into your browser

The user/pass is root.

I find that the best way to make them readable on the forum is to copy and paste them onto notepad first then copy and paste them out of there to the forum.

EXAMPLE

Cable Modem Downstream
DS-1 DS-2 DS-3 DS-4
Frequency 299000000 307000000 315000000 323000000
Lock Status
(QAM Lock/FEC Sync/MPEG Lock) Y/Y/Y Y/Y/Y Y/Y/Y Y/Y/Y
Channel Id 5 6 7 8
Modulation 256QAM 256QAM 256QAM 256QAM
Symbol Rate
(Msym/sec) 6.952 6.952 6.952 6.952
Interleave Depth I=12
J=17 I=12
J=17 I=12
J=17 I=12
J=17
Power Level
(dBmV) -2.83 -2.73 -2.78 -2.33
RxMER
(dB) 36.17 36.84 36.84 37.36
Correctable
Codewords 75 50 24 17
Uncorrectable
Codewords 1113 782 259 274

[Sephiroth]

.....

T3 timeouts do not occur due to high load on the upstream or downstream.
I disagree. If the CMTS is over-utilised (i.e. congestion) and the CPU is busy routing packets etc, then the T3 timeout period is vulnerable.

That's why I wanted the further stats read-out that you've now told him not to provide.

I absolutely agree with all of you on that stupid proxy used by VM's AV. That screws his speed in any case. But he appears to hyave other difficulties and it is worth investigating his high-ish upstream power level.

OK - so the CMTS responds to attenuation rather than noise. I was keeping it SNR-ish in my suggestion. But to suggest with such certainty that a stable 55 dBmv is acceptable doesn't admit the wisdom of at least investigating that high-ish number.

[pip08456]

I disagree. If the CMTS is over-utilised (i.e. congestion) and the CPU is busy routing packets etc, then the T3 timeout period is vulnerable.

That's why I wanted the further stats read-out that you've now told him not to provide.

I absolutely agree with all of you on that stupid proxy used by VM's AV. That screws his speed in any case. But he appears to hyave other difficulties and it is worth investigating his high-ish upstream power level.

OK - so the CMTS responds to attenuation rather than noise. I was keeping it SNR-ish in my suggestion. But to suggest with such certainty that a stable 55 dBmv is acceptable doesn't admit the wisdom of at least investigating that high-ish number.


Got tokeep my eye on this - fight between Seph and Igni!! and I have to go out!!!!!!!!!!!!!!!!!

[VMboy]

I absolutely agree with all of you on that stupid proxy used by VM's AV.

It's not VM's AV, it's Avast.

Please read this below as I keep reading that the proxy is solely to blame when it isn't.

And like I've said previously the slow speeds occur when the proxy is switched off.

[Sephiroth]

Got tokeep my eye on this - fight between Seph and Igni!! and I have to go out!!!!!!!!!!!!!!!!!
Igni usually wins. In this case it's Igni's technical basis vs my analytical nature.

---------- Post added at 19:06 ---------- Previous post was at 19:02 ----------

It's not VM's AV, it's Avast.

Please read this below as I keep reading that the proxy is solely to blame when it isn't.

And like I've said previously the slow speeds occur when the proxy is switched off.

At least quote me properly before you take a punt..

I said: I absolutely agree with all of you on that stupid proxy used by VM's AV. That screws his speed in any case. But he appears to have other difficulties and it is worth investigating his high-ish upstream power level.

[Ignitionnet]

I disagree. If the CMTS is over-utilised (i.e. congestion) and the CPU is busy routing packets etc, then the T3 timeout period is vulnerable.

There are no overutilised CPUs on the VM network and haven't been since the migration to NPE-G1s throughout. Bandwidth congestion does not cause CPU issues on the devices, the amount of traffic a 4 x MC28U BPE equipped CMTS handles even if every single port is maxed is not an issue.

There are only a couple of T3s noted in the logs and these are from the modem coming online and not in normal operation.

There is no wisdom in investigating that high-ish number. The whole point of having a wide operating range is to allow for longer cable runs, numbers of cable splits, etc. HFC isn't an exact science where every modem has a perfect power level. Upstream power levels are a balance between attenuation, amplification and noise levels. Unless it bursts to maximum it's a non-issue.

Still it's your time to spend investigating it. :)

[VMboy]

At least quote me properly before you take a punt..

I said: I absolutely agree with all of you on that stupid proxy used by VM's AV. That screws his speed in any case. But he appears to have other difficulties and it is worth investigating his high-ish upstream power level.

I did quote you properly, I stopped the text at the full stop. There was no need to have the full text being that it was only the reference to your wrongly descriptive message.

[Sephiroth]

I did quote you properly, I stopped the text at the full stop. There was no need to have the full text being that it was only the reference to your wrongly descriptive message.

By doing what you did, you took away the intended meaning of the paragraph. I'm trying to help you so it's pointless getting into this sort of argument with me.

---------- Post added at 21:25 ---------- Previous post was at 21:20 ----------

There are no overutilised CPUs on the VM network ......

There is no wisdom in investigating that high-ish number. The whole point of having a wide operating range is to allow for longer cable runs, numbers of cable splits, etc. HFC isn't an exact science where every modem has a perfect power level. Upstream power levels are a balance between attenuation, amplification and noise levels. Unless it bursts to maximum it's a non-issue.

Still it's your time to spend investigating it. :)
No overutilised CPUs on the VM network? If you say so - but if there was, then T3s could follow.

We'll just have to differ on the highish number. 55 dBmv is the upper limit specified in DOCSIS for upstream at 16QAM. An upper limit might be theoretically in spec, but it's not healthy IMO.

But do please note that I asked the OP to put out a series of upstream power levels specifically to see if it bursted above 55 dBmv. So your point isn't wasted on me.

[VMboy]

By doing what you did, you took away the intended meaning of the paragraph. I'm trying to help you so it's pointless getting into this sort of argument with me.[COLOR="Silver"]


I know you are trying to help me, but your intended meaning wasn't relevant, the relevance was what you said about the AV program calling it VM's, hence the reason why I curtailed the text.

Anyway surely if someone wanted to read what you had fully said then it's not that hard to scroll up.

[Andrewcrawford23]

By doing what you did, you took away the intended meaning of the paragraph. I'm trying to help you so it's pointless getting into this sort of argument with me.

---------- Post added at 21:25 ---------- Previous post was at 21:20 ----------


No overutilised CPUs on the VM network? If you say so - but if there was, then T3s could follow.

We'll just have to differ on the highish number. 55 dBmv is the upper limit specified in DOCSIS for upstream at 16QAM. An upper limit might be theoretically in spec, but it's not healthy IMO.

But do please note that I asked the OP to put out a series of upstream power levels specifically to see if it bursted above 55 dBmv. So your point isn't wasted on me.

i think its 58 the upper limit

[Ignitionnet]

No overutilised CPUs on the VM network? If you say so - but if there was, then T3s could follow.

Yes - I read that from here (http://bradyvolpe.com/2009/03/03/docsis101_station-maintenance/) too.

CPU utilisation might, bandwidth congestion won't is my point and no issue either way as it's not being caused by that, not to mention that it's not actually the fault in question.

---------- Post added at 22:18 ---------- Previous post was at 22:17 ----------

i think its 58 the upper limit

DOCSIS 3 extends the limit from 55 to 58dBmV and the Ambit modems don't care and will go to 61dBmV regardless of 16QAM or QPSK.

---------- Post added at 22:20 ---------- Previous post was at 22:18 ----------

We'll just have to differ on the highish number. 55 dBmv is the upper limit specified in DOCSIS for upstream at 16QAM. An upper limit might be theoretically in spec, but it's not healthy IMO.

Ever been at a headend or logged onto an Acterna Cheetah or similar network monitoring station or a CMTS and monitored upstream impediments, checked flap lists, SNR, received power levels, etc?

We can discuss what's ideal and what websites and books say things should be all we want, doesn't change that in the real world we run on what works and what's stable and this guy is both working and stable on the upstream. It's not up to the cable company to start messing around with their network because a (working) customer doesn't like a number on their screen which isn't harming their service in any way.

If he's near the end of a line far away from an amp or has a splitter or two in between him and the hard plant it explains things just fine. As I said networks are a balancing act and VM may intentionally be driving modems' Tx power higher than you'd wish to see it to improve upstream SNR. At some point it may drop again if VM do some network realignment, with the current network alignment this is how it rolls and it seems fairly stable and working ok from the signal power and quality point of view.

EDIT: Anyway that's enough in this thread from me, please carry on and apologies for the interruption.

[Sephiroth]

Igni,

You're always right to the letter.

But I come from the old school, you might say Conservative (with both c's), that believes when a value as at the extreme end of its range, it is best to bring it down somewhat.

Simples.

[pip08456]

I know you are trying to help me, but your intended meaning wasn't relevant, the relevance was what you said about the AV program calling it VM's, hence the reason why I curtailed the text.

Anyway surely if someone wanted to read what you had fully said then it's not that hard to scroll up.

I think you'll find the intended meaning totally relevant as the AV is VM's as in VMboy's- you chose the nick.

[VMboy]

I think you'll find the intended meaning totally relevant as the AV is VM's as in VMboy's- you chose the nick.

Ok, I think there has been a misunderstanding.

When VM's was used I thought he was referring to Virgin Media, and didn't think for one minute that it was referring to part of my nic, sorry for any problems that may have arose from this.

[pip08456]

Easily done so don't worry about it. Now as we do know that the proxy for web protection is causing a problem why don't you disable it and as you still need protection use this instead and see what the results are then.

http://www.sandboxie.com/

[Sephiroth]

i think its 58 the upper limit

For DOCSIS 1 it's 55 dBmv. For DOCSIS 3, they've added 3 dBmv as Igni has mentioned.

VMBoy is DOCSIS 1.

[VMboy]

For DOCSIS 1 it's 55 dBmv. For DOCSIS 3, they've added 3 dBmv as Igni has mentioned.

VMBoy is DOCSIS 1.

I see from the event log that is says DOCSIS 1.1, is that different from DOCSIS 1.?

[Sephiroth]

Not different for the purpose of upstream power limits.

[VMboy]

Just thought to post a current event log, I see a new UCD in effect.

Wed May 12 22:06:48 2010 Wed May 12 22:06:48 2010 Information (7) New UCD in effect
Wed May 12 22:06:06 2010 Wed May 12 22:06:06 2010 Critical (3) Started Unicast Maintenance Ranging - No Response received - ...
Sun May 09 23:55:13 2010 Sun May 09 23:55:13 2010 Information (7) The s/w filename specified in the config file is the same as ...
Sun May 09 23:55:13 2010 Sun May 09 23:55:13 2010 Information (7) A software upgrade filename was specified in the config file.
Sun May 09 23:55:13 2010 Sun May 09 23:55:13 2010 Information (7) Authorized
Sun May 09 23:55:12 2010 Sun May 09 23:55:12 2010 Information (7) Registration complete!
Sun May 09 23:55:12 2010 Sun May 09 23:55:12 2010 Information (7) We registered with a DOCSIS 1.1 config file!
Sun May 09 23:55:12 2010 Sun May 09 23:55:12 2010 Information (7) Received a REG-RSP message from the CMTS...
Sun May 09 23:55:12 2010 Sun May 09 23:55:12 2010 Information (7) Sending a REG-REQ to the CMTS...
Sun May 09 23:55:12 2010 Sun May 09 23:55:12 2010 Information (7) CableModem SNMP configure complete
Sun May 09 23:55:12 2010 Sun May 09 23:55:12 2010 Information (7) IP init completed ok
Sun May 09 23:55:12 2010 Sun May 09 23:55:12 2010 Information (7) CableModem TFTP init ok
Sun May 09 23:55:12 2010 Sun May 09 23:55:12 2010 Information (7) CableModem DHCP client init ok
Sun May 09 23:55:12 2010 Sun May 09 23:55:12 2010 Critical (3) DHCP WARNING - Non-critical field invalid in response.

[Sephiroth]

This message (UCD) occurs when the CMTS has changed your upstream channel for load balancing reasons. If you put that together with the message below it, you could speculate that at the time the original upstream channel had reached a utilisation threshold.

What's your upstream power at the time of the UCD messge and/or now?

[VMboy]

What's your upstream power at the time of the UCD messge and/or now?

Upstream transmit Power Level : 54.0 dBmV

[Sephiroth]

OK. If it hasn't changed there's nothing more I can add other than it appears stable at least.

[VMboy]

OK. If it hasn't changed there's nothing more I can add other than it appears stable at least.

Thanking You.

[VMboy]

Another UCD in effect, is this normal?

Fri May 14 22:15:18 2010 Fri May 14 22:15:18 2010 Information (7) New UCD in effect
Fri May 14 11:18:08 2010 Fri May 14 11:18:08 2010 Critical (3) Started Unicast Maintenance Ranging - No Response received - ...
Fri May 14 05:58:52 2010 Fri May 14 05:58:52 2010 Information (7) The s/w filename specified in the config file is the same as ...
Fri May 14 05:58:52 2010 Fri May 14 05:58:52 2010 Information (7) A software upgrade filename was specified in the config file.
Fri May 14 05:58:52 2010 Fri May 14 05:58:52 2010 Information (7) Authorized
Fri May 14 05:58:52 2010 Fri May 14 05:58:52 2010 Information (7) Registration complete!
Fri May 14 05:58:52 2010 Fri May 14 05:58:52 2010 Information (7) We registered with a DOCSIS 1.1 config file!
Fri May 14 05:58:52 2010 Fri May 14 05:58:52 2010 Information (7) Received a REG-RSP message from the CMTS...
Fri May 14 05:58:51 2010 Fri May 14 05:58:51 2010 Information (7) Sending a REG-REQ to the CMTS...
Fri May 14 05:58:51 2010 Fri May 14 05:58:51 2010 Information (7) CableModem SNMP configure complete
Fri May 14 05:58:51 2010 Fri May 14 05:58:51 2010 Information (7) IP init completed ok
Fri May 14 05:58:51 2010 Fri May 14 05:58:51 2010 Information (7) CableModem TFTP init ok
Fri May 14 05:58:51 2010 Fri May 14 05:58:51 2010 Information (7) CableModem DHCP client init ok
Fri May 14 05:58:51 2010 Fri May 14 05:58:51 2010 Critical (3) DHCP WARNING - Non-critical field invalid in response.

[Ignitionnet]

No, obsessing over the event log in your cable modem is not normal.

It's about as normal as it was when you asked this 3 days ago, and even more normal than when you asked last year.

[VMboy]

No, obsessing over the event log in your cable modem is not normal.

It's about as normal as it was when you asked this 3 days ago, and even more normal than when you asked last year.

Very helpful indeed, NOT.

Obsessing my posts isn't normal either!

[Ignitionnet]

I was bored. i also answered your question, just as Sephiroth did when you asked the same one 3 days ago.

If you are so concerned you could, and bear with me here, contact your cable company.

I know you hate me because I just tell it like it is rather than encouraging your obsession with your cable service. I posted the most likely cause of the issue on page 4. Boring as it is not entertaining you by asking you to paste endless logs, power levels, etc, that's the most likely cause of the issue and nothing anyone has posted has contradicted it.

If you want help so much maybe contacting Virgin over this over a week long issue would be beneficial. Just a thought.

[pip08456]

No doubt it will go on for another 4 pages.