cancel
Showing results for 
Search instead for 
Did you mean: 
greglloyd
Aspiring Expert
689 Views
Message 11 of 34

Re: Yes. That's where I can see the stats from. See below :-

Here's the log for the past few days. Note that the system reboots are made by me trying to get a jump in sync speed. Also, the latest entries at the top are for today after trying to get a new sync this morning and making the changes suggested above.

 

2000-1-1 0:0:21 Notice 104500 DSL activate succeed
2000-1-1 0:0:20 Notice 0 admin login
2000-1-1 0:0:17 Debug 104500 LAN1 up
2000-1-1 0:0:14 Debug 104500 LAN2 up
2000-1-1 0:0:14 Notice 1 System up
2000-1-1 0:0:3 Warning 10400 KLOB Pool 1 Initialized: 1048576 bytes <0x80300000 ... 0x80400000>
2000-1-1 1:19:0 Info 104504 Restore default succeed
2000-1-1 1:17:52 Notice 0 admin login
2000-1-1 1:16:34 Debug 104500 LAN2 up
2000-1-1 1:16:32 Debug 104500 LAN2 down
2000-1-1 1:16:30 Debug 104500 LAN2 up
2000-1-1 1:13:25 Debug 104500 LAN1 up
2000-1-1 1:13:12 Debug 104500 LAN1 down
2000-1-1 1:11:53 Debug 104500 LAN1 up
2000-1-1 1:11:52 Debug 104500 LAN1 down
2000-1-1 1:11:48 Debug 104500 LAN1 up
2000-1-1 1:11:44 Debug 104500 LAN2 down
2000-1-1 1:11:35 Debug 104500 LAN1 down
2000-1-1 0:7:2 Notice 0 admin login
2000-1-1 0:1:13 Debug 104500 LAN1 up
2000-1-1 0:1:11 Debug 104500 LAN2 up
2000-1-1 0:0:23 Notice 104500 DSL activate succeed
2000-1-1 0:0:14 Notice 1 System up
2000-1-1 0:0:3 Warning 10400 KLOB Pool 1 Initialized: 1048576 bytes <0x80300000 ... 0x80400000>
2000-1-2 0:30:52 Notice 0 admin login
2000-1-1 17:41:16 Notice 0 admin login
2000-1-1 16:53:1 Notice 0 admin login
2000-1-1 14:10:29 Notice 0 admin login
2000-1-1 14:8:3 Notice 0 admin login
2000-1-1 13:7:53 Notice 0 admin login
2000-1-1 13:3:37 Notice 0 admin login
2000-1-1 10:47:16 Notice 0 admin login
2000-1-1 7:21:28 Warning 10400 104706 prevent Smurf attack, icmp broadcast packet from 10.0.1.11 .
2000-1-1 7:21:28 Warning 10400 104706 prevent Smurf attack, icmp broadcast packet from 10.0.1.11 .
2000-1-1 7:21:28 Warning 10400 104706 prevent Smurf attack, icmp broadcast packet from 10.0.1.11 .
2000-1-1 7:17:55 Debug 104500 LAN2 up
2000-1-1 7:17:40 Debug 104500 LAN2 down
2000-1-1 7:17:38 Debug 104500 LAN2 up
2000-1-1 7:14:42 Debug 104500 LAN1 up
2000-1-1 7:13:39 Debug 104500 LAN1 down
2000-1-1 7:11:53 Debug 104500 LAN1 up
2000-1-1 7:11:50 Debug 104500 LAN1 down
2000-1-1 7:11:17 Debug 104500 LAN1 up
2000-1-1 7:11:14 Debug 104500 LAN1 down
2000-1-1 7:8:28 Debug 104500 LAN1 up
2000-1-1 7:8:25 Debug 104500 LAN1 down
2000-1-1 7:7:1 Debug 104500 LAN1 up
2000-1-1 7:6:58 Debug 104500 LAN1 down
2000-1-1 7:3:41 Debug 104500 LAN1 up
2000-1-1 7:2:58 Debug 104500 LAN1 down
2000-1-1 7:2:58 Debug 104500 LAN2 down
2000-1-1 6:13:36 Warning 10400 104706 prevent Smurf attack, icmp broadcast packet from 10.0.1.11 .
2000-1-1 6:13:36 Warning 10400 104706 prevent Smurf attack, icmp broadcast packet from 10.0.1.11 .
2000-1-1 6:13:36 Warning 10400 104706 prevent Smurf attack, icmp broadcast packet from 10.0.1.11 .
2000-1-1 5:32:28 Warning 10400 104706 prevent Smurf attack, icmp broadcast packet from 10.0.1.11 .
2000-1-1 5:32:28 Warning 10400 104706 prevent Smurf attack, icmp broadcast packet from 10.0.1.11 .
2000-1-1 5:32:28 Warning 10400 104706 prevent Smurf attack, icmp broadcast packet from 10.0.1.11 .
2000-1-1 5:28:16 Debug 104500 LAN2 up
2000-1-1 5:27:26 Debug 104500 LAN2 down
2000-1-1 5:11:48 Notice 0 admin login
2000-1-1 5:7:21 Warning 10400 104706 prevent Smurf attack, icmp broadcast packet from 10.0.1.11 .
2000-1-1 5:7:21 Warning 10400 104706 prevent Smurf attack, icmp broadcast packet from 10.0.1.11 .
2000-1-1 5:7:21 Warning 10400 104706 prevent Smurf attack, icmp broadcast packet from 10.0.1.11 .
2000-1-1 3:42:44 Notice 0 admin login
2000-1-1 3:38:6 Debug 104500 LAN1 up
2000-1-1 3:37:40 Debug 104500 LAN2 up
2000-1-1 3:37:24 Debug 104500 LAN1 down
2000-1-1 3:37:8 Debug 104500 LAN2 down
2000-1-1 3:36:37 Debug 104500 LAN2 up
2000-1-1 3:35:18 Debug 104500 LAN2 down
2000-1-1 3:33:54 Notice 0 admin login
2000-1-1 2:23:9 Notice 0 admin login
2000-1-1 0:0:41 Notice 0 admin login
2000-1-1 0:0:21 Notice 104500 DSL activate succeed
2000-1-1 0:0:18 Debug 104500 LAN1 up
2000-1-1 0:0:16 Debug 104500 LAN2 up
2000-1-1 0:0:16 Notice 1 System up
2000-1-1 0:0:3 Warning 10400 KLOB Pool 1 Initialized: 1048576 bytes <0x80300000 ... 0x80400000>
2000-1-1 10:38:39 Warning 104001 System reboot
2000-1-1 10:37:48 Notice 0 admin login
2000-1-1 2:46:30 Notice 0 admin login
2000-1-1 2:43:23 Notice 0 admin login
2000-1-1 2:37:35 Notice 0 admin login
2000-1-1 0:40:9 Notice 0 admin login
2000-1-1 0:38:34 Debug 104500 LAN2 up
2000-1-1 0:37:7 Debug 104500 LAN2 down
2000-1-1 0:25:51 Notice 0 admin login
2000-1-1 0:2:24 Notice 0 admin login
2000-1-1 0:1:34 Notice 0 admin login
2000-1-1 0:0:21 Notice 104500 DSL activate succeed
2000-1-1 0:0:18 Debug 104500 LAN1 up
2000-1-1 0:0:16 Debug 104500 LAN2 up
2000-1-1 0:0:16 Notice 1 System up
2000-1-1 0:0:3 Warning 10400 KLOB Pool 1 Initialized: 1048576 bytes <0x80300000 ... 0x80400000>
2000-1-1 14:33:23 Notice 0 admin login
2000-1-1 10:52:22 Notice 0 admin login
2000-1-1 0:3:52 Notice 0 admin login
2000-1-1 0:0:23 Warning 10400 104706 prevent Smurf attack, icmp broadcast packet from 10.0.1.11 .
2000-1-1 0:0:23 Warning 10400 104706 prevent Smurf attack, icmp broadcast packet from 10.0.1.11 .
2000-1-1 0:0:23 Warning 10400 104706 prevent Smurf attack, icmp broadcast packet from 10.0.1.11 .
2000-1-1 0:0:21 Notice 104500 DSL activate succeed
2000-1-1 0:0:17 Debug 104500 LAN1 up
2000-1-1 0:0:15 Debug 104500 LAN2 up
2000-1-1 0:0:14 Notice 1 System up
2000-1-1 0:0:3 Warning 10400 KLOB Pool 1 Initialized: 1048576 bytes <0x80300000 ... 0x80400000>
2000-1-1 13:42:6 Warning 104001 System reboot
2000-1-1 13:41:42 Notice 0 admin login
2000-1-1 12:54:49 Notice 0 admin login
2000-1-1 12:52:53 Notice 0 admin login
2000-1-1 0:0:25 Notice 0 admin login
2000-1-1 0:0:23 Warning 10400 104706 prevent Smurf attack, icmp broadcast packet from 10.0.1.11 .
2000-1-1 0:0:23 Warning 10400 104706 prevent Smurf attack, icmp broadcast packet from 10.0.1.11 .
2000-1-1 0:0:23 Warning 10400 104706 prevent Smurf attack, icmp broadcast packet from 10.0.1.11 .
2000-1-1 0:0:21 Notice 104500 DSL activate succeed
2000-1-1 0:0:17 Debug 104500 LAN1 up
2000-1-1 0:0:15 Debug 104500 LAN2 up
2000-1-1 0:0:14 Notice 1 System up
2000-1-1 0:0:3 Warning 10400 KLOB Pool 1 Initialized: 1048576 bytes <0x80300000 ... 0x80400000>
2000-1-1 10:5:12 Warning 104001 System reboot

0 Ratings
Deathtrap3000
Recognised Expert
669 Views
Message 12 of 34

Re: Yes. That's where I can see the stats from. See below :-

Lucky you are being protected from all those smurf attacks.

0 Ratings
Guru
666 Views
Message 13 of 34

Re: Yes. That's where I can see the stats from. See below :-

Do you have Evolve installed by any chance? If so, uninstall it I'm prett sure 10.x.x.x is evolves lan configuration settings

If this helped you please click the Star beside my name.

If this answered your question please click "Mark as Accepted Solution" below.
0 Ratings
greglloyd
Aspiring Expert
646 Views
Message 14 of 34

Re: Yes. That's where I can see the stats from. See below :-

@Ryan - No I don't. The 10.0.1.100 address you see is what I have have manually configured the modem to (Airport Extreme networks default to the 10.0... range and I wanted the modem to be easy to access). The modem has been on that IP address for a year now with no issues at all..

 

The 34996 sync speed is nothing to do with my end I don't think. The cabinet has decided to cap at 34996 even though the max attainable is still reporting 43000 and I'm still on fast path. I just don't get it. It appears I'm on a banded profile at 10db SNR margin for no good reason. Will see what happens over the next week or two sync speed wise.

0 Ratings
Guru
614 Views
Message 15 of 34

Re: Yes. That's where I can see the stats from. See below :-

A little bit of advice.

 

You havn;'t been "capped" at the dslam, your broadband is doing exactly what it's supposed to do.

 

Clearly because of a slight increase in environmental impulse noise, the margin has risen slightly.

 

This could be from some subtle change that at the moment seems a mystery, or it could be e.g. street lamps or similar,

 

but it is a credible and often expected source to cause it. (darker nights etc. heating pumps, lighting, Tvs)

 

The most important thing is the connection is still very healthy, as you're STILL on fastpath.

 

But be warned, if you make too many interventions, it'll punish you by turning interleave on, and that is very difficult

 

to reverse once it's set (automatically).  But your slight rise in margin will reverse on its own in time, if the source

 

of the cause goes away. If it were mine, I wouldn't panic, just keep an eye, over-reaction can kill it for you, and in real

 

terms, it's doing what it's designed to do. Just make sure you have good segregation with power lines and transformers

 

away from the network/modem/hub lines and placement of equipment (away from rads and electrical stuff).

 

Remember, don't keep resetting it .... you'll be glad you didn't.

0 Ratings
greglloyd
Aspiring Expert
609 Views
Message 16 of 34

Re: Yes. That's where I can see the stats from. See below :-

Hi Roger,

 

Totally agree with everything you say and the line is still very healthy. I agree about leaving everything alone now and that is what I'm going to do. I've felt the wrath of over zealous rebooting before and ended up stuck with heavy interleaving and Impulse Noise Protection on which really increased the ping times and harmed throughput significantly. Had to get a BT engineer out eventually to reset the profile that time as it appeared that it would never return to previous values. So defo wanting to avoid a repeat of that!

 

p.s. When I referred to the capping at the cabinet that was a loose term. What I menat was that my target SNR had been increased from 6db to 10db effectively stopping me from syncing any higher that 35meg for now. I would not be surprised at all if it's something to do with increased electricity usage due to darker nights, etc. Makes sense. Just going to let DLM take it's natural course.

 

Thanks

greglloyd
Aspiring Expert
541 Views
Message 17 of 34

Re: Yes. That's where I can see the stats from. See below :-

So it's now roughly a month on from when I last posted about my drop in sync speed. To recap :-

 

1. I've had infinity for around 2 years now

2. I went onto Option 2 as soon as it was released and had a stable sync speed of around 43000 for a year

3. About a month or so ago I decided to try downgrading to option 1 as I thought I wasn't using enough bandwidth. Had a rethink during the order period and tried to cancel the order but was advised it must go through at that stage.

4. Once the order completed my speed changed to 39997 / 9999 (Option 1)

5. Immediately placed order to go back to Option 2 which completed a week later.

6. Sync speed returned to around 43000 / 9800.

7. Approx 1 to 2 weeks afterwards my sync speed dropped to 34996 / 9850 and will not budge. SNR Margin is 10db. Modem is still on fast path with no interleaving or delay.

8. Left the modem totally untouched since late October and checked the logs this morning - no automatic resyncing or rebooting has taken place during this period.

9. Did a single reboot of the modem this morning and exactly the same speed - 34996 / 9850.

10. Error counts appear to me to be low.

 

Any ideas? Just how long before the DLM changes your target snr margin? It appears like it my never change. Just want it back to where it was because before I did that reorder I had 43 meg running for a year with no issues at all. Frustrating.

0 Ratings
Sage
Sage
520 Views
Message 18 of 34

Re: Yes. That's where I can see the stats from. See below :-

As RogerB said previously there must be something effecting your conection to cause DLM to kick in and lower your throughput.

 

Tracking down said interference is a whole complicated different matter.

 

DLM is doing it's job and providing you with a stable connection at the best speed for your line under the circumstances.

 

 

0 Ratings
Highlighted
greglloyd
Aspiring Expert
505 Views
Message 19 of 34

Re: Yes. That's where I can see the stats from. See below :-

Yes, I understand that DLM is adjusting to give the best under the circumstances but it changed from 6db to 10db margin almost two months ago. The issue could have long since resolved itself but the DLM has not bothered to go back to 6db. My line has always beeen 6db target margin since I got infinity.

 

With ADSL the DLM system was well understood. Target SNR margin changes would take place exactly 7 days after stable line performance with BRAS profile then following 3 days later. With VDSL2 it is not clear when target margin changes take place and nobody seems to have a clue.

 

It would be great to have clarity about when exactly the system makes a target SNR change (we know that the IP profile changes instantly when you get a new sync speed). Because it's very clear that it's not the same as ADSL. I've had my modem connected continuously for weeks and can tell from the modem logs that the cabinet has not forced my modem to resync at ANY stage. So it's not like the DLM system has continued to monitor and decided to resync me at the same 10db SNR margin because it has detected continuing issues with the line.

 

With ADSL there were very clear timescales for changes (and yes, I do understand this is a different technology and the rules are different. I work as an IT professional and fully understand this). I just want to know if anyone has worked out the rules. I know the docs saying DLM is continuous on VDSL2 but that appears to be continuous and immediate drops in speed if line issues appear. It is most definitely not continuous monitoring for bumping the speed back up again.

0 Ratings
Guru
497 Views
Message 20 of 34

Re: Yes. That's where I can see the stats from. See below :-

I agree it would be good to have a clearer idea of how the DLM algorithm works.  Maybe it is still being regularly tweaked and is different in different cabinets?

 

Do the stats show targetSNR as well as current SNR?

 

we know that the IP profile changes instantly when you get a new sync speed  Not quite..  IP profile changes at the next pppeo connection.  Sometimes the modem resync takes long enough to force to pppeo connection to drop, so the result is instant.  In my experience I have needed a disconnect/reconnect of the router to force the new profile.

0 Ratings