Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[NewtronStar]

Just to give you guys with FTTC what the DLM will do when it see's your SNRM getting close to 4.5 dB.

It's been one of those funky days when the attainable rate hit 40000 kbps and the sync rate hit 32000 kbps, my line cannot cope with these rates and the DLM put my SNRM to 3.5 dB after the retrain last night.

I did turn off the HG612 this afternoon for 30 minutes and SNRM went back to 6.0 dB but the attainable was still to high for the blast of evening RFI and again the DLM has intervened half an hour ago.

[NewtronStar]

Have decided to go back to the MKII SSFP and finding it seems much more effective this time around, I've had enough of watching the DS & US duck and dive in a 24 hour period.

So I just pulled out MKI SSFP and NTE5 and just sniped of the wires and re-terminated eveything and keeping a close eye on the SNRM

The Graph I post will show you the SNRM just before the HG612 was switched off for internal  maintenance you will see it took me over 30 minutes to complete 22:43 to 23:34 and the SNRM is flat lined

It does seem better what do you think ?

[burakkucat]

It does seem better what do you think ?

As there is so little to look at in the "before" and "after" segments of that graph, perhaps it might be an idea to wait and collect 24 hours worth of data, then show two graphs -- one full 24 hours "before" and one full 24 hours "afterwards". 

[NewtronStar]

Yeah cheers B*CAT you know me i turn off the PC collecting the stats when it's bedtime.

I'll know after a few days if it makes any difference, I am now getting so desperate to see my DS and US stay at 6dB 24/7 the Data Socket (extension socket) may have to go.

[NewtronStar]

Nothing has improved B*CAT with MKII SSFP installed again, have been monitoring the stats over 4 days it looks the same when the MKI SSFP was installed.

The upside is I am 100% sure the MKII and the BT80 RF3 will not make any dent into RFI in my location, so thats 4 months of testing the MKII and BT80 RF3 completed.

What I will be doing next week is to removed the data socket terminals (extension socket) in the SSFP and connect the SSFP DSL socket to the HG612 direct using a 4 meter DSL cable.

[kitz]

It's not so much the 4.5db.. It's more the errors generated when your snrm is that low.
Chrys maintains a steady 4db, without much issue.

I know you turn your pc off at night, and I trust that you leave the router connected, but have you not considered just leaving things to graph for a period of say a week to try and get a full sample for the sake of curiosity.  If you turn your monitor off it shouldn't use too much electricity.

I also appreciate that its evenings when your line is hit worst, but it would be nipped to see a full picture.

[burakkucat]

Eric's DSLstats will run on a Raspberry Pi.

A Raspberry Pi uses a minimal amount of electricity . . . 

[NewtronStar]

It's not so much the 4.5db.. It's more the errors generated when your snrm is that low.
Chrys maintains a steady 4db, without much issue.

Well Kitz if I hit an SNRM of 4.5dB the DLM will re-sync the modem, you see I have to keep a fine balance here if I sync to high the SNRM will be to low in the evening with which then generates a lot of ES and SES, you have to remember my SNRM is not steady over a 24 hour period it swings from 7.5dB afternoon to 4.8dB in the evening.

The last time I left the modem with an SNRM of 3dB I was banded for 2 weeks.
So you see it may work for CHRY but not me !

[NewtronStar]

Eric's DSLstats will run on a Raspberry Pi.

A Raspberry Pi uses a minimal amount of electricity . . . 

I am sure it would B*Cat but I prefer HG612_Modem_stats when it comes to +24 hours monitoring of stats and I don't know how to post a five day graph monty in DSLstats 

[NewtronStar]

I was able to test with 4 meters of DSL cable direct from HG612 to Master socket and the stats look the same when using Data Extension Socket (DES) so at least that rules out that DES is causing the terrible SNRM swings in the evening.

Removed the SSFP MKII again because what ever it's doing seems to accentuate the (possible HR fault) on my line with large DS & US errors when the land line rings.

Replace old DSL cable from DES to HG612 with a new one very little change.

[Chrysalis]

so you had a low DLM snrm ,like I did a few months back?

[NewtronStar]

so you had a low DLM snrm ,like I did a few months back?

Thats about right, but unlike your goodself I could not leave the modem sitting with an SNRM of 3.5dB any longer than 24 hours my DLM would give me a kick in the arse and a bruise that would last 14 days, so had to manually re-sync the FTTC Modem to get close to 6dB.

But my US Sync for a few months is consistently higher than the attainable, so it could be that both the DS and US pair are unbalanced

[Chrysalis]

yeah you got higher loop loss, on my adsl with high loop loss was lots of variable snrm at night and if it went anywhere near 3-4db the line would be unstable.  The problem was the tones that only have low bit count, they get destroyed at night, on my vdsl asides from the adsl power cut back tones all my bitloading even with my fault is not that critical whilst you have tones barely working due to your loop loss.  I did have higher crc errors at 4db but they were not service affecting for over 3 months up until my fault.

[NewtronStar]

yeah you got higher loop loss, on my adsl with high loop loss was lots of variable snrm at night

That about sums it up CHRY, you use the word (higher loop) to me it's called the longer line on the FTTC product (800 to 1200 meters of copper wire) from the PCP (Primary connection point) cabinet all the way to your master socket, the longer the line is = more noise and loss of broadband signal.

Still think I am lucky to even get FTTC 40/10 service being 1000 meters from the PCP, it's just the SNRM is not as stable as it was 2 and half years ago when I first got connected to FTTC 

[boost]

Are you able to post your full stats n graphs Newtron? More for my curiosity than me having anything helpful to say, unfortunately

Also, someone was talking about limiting synch rates on FTTC on here before to ensure they stayed fastpathable. I've not needed to do it myself but presumably is achievable with the HG, somehow? You could possibly limiting the loading on your more problematic tones, unless you see bitswaps across the lot?