Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: 1 2 [3] 4 5

Author Topic: FTTC long line 2.6km - Stats check after problems  (Read 20866 times)

Crickers

  • Member
  • **
  • Posts: 36
Re: FTTC long line 2.6km - Stats check after problems
« Reply #30 on: February 25, 2013, 03:40:00 PM »

Right, so who's got a TDR and likes tea & biscuits?  :thumbs:

Thanks for the info asbokid.
Logged

Bald_Eagle1

  • Helpful
  • Kitizen
  • *
  • Posts: 2721
Re: FTTC long line 2.6km - Stats check after problems
« Reply #31 on: February 25, 2013, 06:39:03 PM »


Quote
I'd be happy to share the 'C' code for the Windows versions if that would assist anyone for conversion to Linux.

I have been 'threatened' with that, before, by you and I am still awaiting for its materialisation.


That is no longer an idle threat, as you will see when you read through your emails ;)

As always, constructive criticism/advice is/are most welcomed.

Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: FTTC long line 2.6km - Stats check after problems
« Reply #32 on: February 25, 2013, 08:21:12 PM »

Wrong side of the bed this morning, B*Cat ??  :)

No.  :no:  I hadn't made use of it at the time I posted!   :o

The Eagle and the Cat have a good understanding and 'get on' well together. (You should see the debris on the floor when we have concluded a discussion -- clumps of plucked fur and pulled feathers everywhere!  :)  )  I feel somewhat guilty that we have hijacked Crickers thread with our discussion of coding internals . . .  :-[
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

Black Sheep

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5722
Re: FTTC long line 2.6km - Stats check after problems
« Reply #33 on: February 25, 2013, 08:22:18 PM »

 ;D
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: FTTC long line 2.6km - Stats check after problems
« Reply #34 on: February 25, 2013, 08:29:56 PM »

Right, so who's got a TDR and likes tea & biscuits?  :thumbs:

To the best of my knowledge, in alphabetical order --
  • Asbokid
  • Bald_Eagle1
  • Black Sheep
  • Burakkucat
  • Ezzer
  • WalterGMW
Bacon sandwiches are also appreciated!  :yum:
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

Crickers

  • Member
  • **
  • Posts: 36
Re: FTTC long line 2.6km - Stats check after problems
« Reply #35 on: February 25, 2013, 08:30:19 PM »

Carry on, I love a good ruck. Thread will still be here once dust has settled.  :shoot: :shoot:
Logged

Crickers

  • Member
  • **
  • Posts: 36
Re: FTTC long line 2.6km - Stats check after problems
« Reply #36 on: February 25, 2013, 08:50:51 PM »

Any one got any ideas about progressing this, but without a TDR test or is this logical next step?
I'll keep logging stats, and as I guess the DLM process is still ongoing.
 
One other question, but what impact does internal cabling have if connected at the master socket using the NTE5 faceplate? Guessing not much as it doesn't seem to make any difference if connected or not.

Second other question, are Hlog stats collected at re sync only or against some other function?

Thanks me done, wine to drink  :drink:
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: FTTC long line 2.6km - Stats check after problems
« Reply #37 on: February 26, 2013, 12:31:19 AM »

Quote
Second other question, are Hlog stats collected at re sync only or against some other function?

The data is collated only at active-CPE / DSLAM synchronisation time.

Quote
One other question, but what impact does internal cabling have if connected at the master socket using the NTE5 faceplate? Guessing not much as it doesn't seem to make any difference if connected or not.

When a SSFP is fitted to a NTE5/A it completely isolates the xDSL signals from the telephony wiring. In other words, once the interstitial SSFP has been plugged into the NTE5/A, the only signals present at its lower right front socket are telephony. Hence the fitting of the original front face-plate, with telephony extension wiring connected, will not affect the xDSL circuit's balance and performance.

Quote
I'll keep logging stats, and as I guess the DLM process is still ongoing.

The Openreach DLM is continuously monitoring the line whilst the service is deployed. Bald_Eagle1 will be able to quote you the official wording on the subject, including how it will intervene -- if it considers such intervention to be necessary.

Quote
Any one got any ideas about progressing this, but without a TDR test or is this logical next step?

That question is best left for Black Sheep's (or perhaps Ezzer's) response.
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

waltergmw

  • Kitizen
  • ****
  • Posts: 2776
Re: FTTC long line 2.6km - Stats check after problems
« Reply #38 on: February 26, 2013, 12:33:15 AM »

@ Crickers,

Extension wiring, if properly connected, doesn't seem to have much effect as it is after the filter circuit provided an effective SSFP has been fitted.
(Beware NOT to connect extension wiring to the two terminals meant for a VDSL extension socket though. EDIT I.e. the connector pair shown in BKK's second picture above should ONLY be used when the VDSL modem is connected remotely)

However if the master socket is not wired properly, or as several subcontractors have done around us with NO adjustments at all, quite horrendous performance follows usually leaving the poor EU with a massive battle. That is until Uncle Walter's wheelbarrow is deployed, ably assisted by remote cats and birds !

Kind regards,
Walter

PS Re a TDR; it may not come as too much of a surprise to note that Essex and Suffolk are in reasonably close proximity.
« Last Edit: February 26, 2013, 10:47:20 AM by waltergmw »
Logged

Black Sheep

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5722
Re: FTTC long line 2.6km - Stats check after problems
« Reply #39 on: February 26, 2013, 07:31:00 AM »

 You might be able to get your ISP to perform a CIDT (Copper Integrated Digital Test). This initially performs a low-frequency test of the copper pair from the Exchange to your premises, which is extremely unlikely to show a HR if it's in it's infancy. However, it then goes on to ping your router at varying frequencies, and it's this part of the test that may see a HR, if indeed one does exist. 
Logged

Crickers

  • Member
  • **
  • Posts: 36
Re: FTTC long line 2.6km - Stats check after problems
« Reply #40 on: February 28, 2013, 09:53:10 PM »

Been really busy over the last few days...

Here's stats for the last week. Doesn't seem have adjusted sync speed for the last 3 days and looks like interleaving has dropped back down.

Wondering if DLM will re-adjust again, or if a reboot might be an idea?

« Last Edit: February 28, 2013, 09:59:14 PM by Crickers »
Logged

asbokid

  • Kitizen
  • ****
  • Posts: 1286
    • Hacking the 2Wire
Re: FTTC long line 2.6km - Stats check after problems
« Reply #41 on: February 28, 2013, 10:51:36 PM »



It should be possible to tell if the RFI is caused by an outside lighting circuit switched by a photocell.

As the days get longer, and dawn comes earlier while dusk falls later, the 'phase' of the RFI noise should shift.

The 'falling edge' of the noisy period should shift to the right, and the 'rising edge' should shift to the left.
Meaning the overall duration of that daily noisy period should shorten.

That's the theory any way!

cheers, a

EDIT: dawn before dusk!
« Last Edit: March 01, 2013, 03:57:44 PM by asbokid »
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: FTTC long line 2.6km - Stats check after problems
« Reply #42 on: February 28, 2013, 11:09:46 PM »

All I shall say is that there is something definitely 'wrong' with that line.  :-X

Now where is Feathers and his Eagle-eye of analysis?
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

Crickers

  • Member
  • **
  • Posts: 36
Re: FTTC long line 2.6km - Stats check after problems
« Reply #43 on: March 01, 2013, 08:45:52 AM »

A reboot of the modem this morning has given me 6.04Mb on speedtest.net, never been over 5.5Mb before.  :fingers:

Still seeing the spike in Hlog.

Won't be online much for the next week, but will gather stats and leave DLM to work things out.

Then once this is done, will raise another fault if required with BT.
Logged

Crickers

  • Member
  • **
  • Posts: 36
Re: FTTC long line 2.6km - Stats check after problems
« Reply #44 on: August 26, 2014, 04:52:03 PM »

Well an update is long over due.....

Speed has been slowly deteriorating for some time but settled around 4.3Mb until an outage around which then resulted a speed of 2.5Mb after several frustrating calls to India.

Anyway after trying to resolve the speed issue via the normal process for 2 weeks I lost the plot (threw every dolly out of the pram) and emailed someone in BT which was redirected to Newscastle Technical Complaints team and got a response within a day.

So after another two engineer visit's and a swap to a new pair from the FTTC cab, the line speed is now around 4.7Mb.

But I still see missing bit loading and a strange Hlog graph. I have forwarded this info to BT asking for some explanation, but they are now saying they are unable to use the information as it has been obtained by using non standard firmware. Pretty poor excuse if you ask me.

As it stands no engineer has ever been able to get a JDSU to sync, I even asked the last engineer to change the annexe as suggested previously in this thread, but he was unaware of this setting and unable to find it in the menu. Are the JDSU's locked down in some way or maybe just lack of JDSU knowledge?
Logged
Pages: 1 2 [3] 4 5
 

anything