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 ... 5 6 [7] 8

Author Topic: Fourth line goes in next Wed  (Read 11980 times)

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 9107
  • Retd sw dev; A&A; 4 7km ADSL2; IPv6; Firebrick
Re: Fourth line goes in next Wed
« Reply #90 on: August 28, 2018, 11:14:17 PM »

I agree completely with kitz, sounds far more logical. I would have thought that change could be made even now though, no? Sell BTW to the new Openreach. Has that ship already sailed?

I don't know where I am now, I am hoping AA will get on with it and start pushing.
Logged

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 9107
  • Retd sw dev; A&A; 4 7km ADSL2; IPv6; Firebrick
Re: Fourth line goes in next Wed
« Reply #91 on: August 30, 2018, 07:54:43 AM »

AA was indeed beavering away yesterday. Another BT man coming this afternoon.
Logged

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 9107
  • Retd sw dev; A&A; 4 7km ADSL2; IPv6; Firebrick
Re: Fourth line goes in next Wed
« Reply #92 on: August 30, 2018, 12:28:49 PM »

Openreach man is here. Said "AC balance" to Janet. Has gone off on a mission.
Logged

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 30788
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Fourth line goes in next Wed
« Reply #93 on: August 30, 2018, 04:58:33 PM »

Openreach man is here. Said "AC balance" . . .

That certainly makes sense.
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.

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 9107
  • Retd sw dev; A&A; 4 7km ADSL2; IPv6; Firebrick
Re: Fourth line goes in next Wed
« Reply #94 on: August 30, 2018, 06:27:57 PM »

Success! sort of, more thereon later.

Sync rates are now perfect following discovery of yet another bad joint near the Claymore restaurant on the main road, so E-side pair swap. Our man was working for something like five hours, long day for our diligent hero.

Quote
BT Fault 3-762548671326 Right When Tested; End User Equipment;All BT tests completed ok, for the reported symptoms
Did all the connections, extensions and DSL filters meet the minimum standards ?: Yes
Did you complete the end customer premises equipment module ?: No
Did you disconnect any end customer wiring to resolve a problem ?: No
Did you complete the Base module ?: Yes
Have you conducted a sync test (modem light on) ?: Yes
What was the result of the initial pair quality test ?: Fail
Did you complete the end customer Premises Wiring Module ?: No
Have you successfully demonstrated connectivity to the NTE ?: Yes
Did you replace the NTE and why ?: Did not replace
BT
Today 17:47:37   Today 17:48:01   BT Fault 3-762548671326 Right When Tested; End User Equipment;All BT tests completed ok, for the reported symptoms
End customer contacted ?: 1602.02-I completed the ring ahead but there was no answer (voice message left where available). I continued to progress to the end customer premises.
Did you get access to the end customer premises (inc access to internal comm / equipment rooms) ?: 749.01-Engineer got access to the internal comm / equipment rooms.
What did the end customer describe as the primary issue ?: 3762.03-End customer informed us that broadband is not stable / intermittent.
Prior to any work where did you perform DeltaR / Autoprotective PQT ?: 3743.01-DeltaR / Autoprotective PQT test performed at NTE back plate.
Prior to any work, what was the leg difference in the DeltaR / Autoprotective PQT Test ?: 3763.01-The test passed with resistance within permissible range for broadband on 2018-08-30T12:03:14.
Where did you do an initial PQT after DeltaR test ?: 3854.01-PQT performed at NTE backplate.
Prior to any work what was the result of the test ?: 3749.04-The test failed on 2018-08-30T12:03:14.
Prior to any work, did you identify any issue at the PCP or noise on the line ?: 4059.01-No noise, misrouted / crossed lines or left in FTTC jumpers in PCP on the line identified.
Where was the fault located ?: 743.03-Fault located in E side / PCP.
Have you completed all the base module activities listed below ?: 755.01-Base module checks completed.
What did you do to fix it ?: 745.01-Resolved with pair change between MDF and PCP.
Did you replace the NTE ?: 750.03-NTE not replaced.
Where did you perform the final PQT ?: 3835.02-Final PQT performed at the NTE front plate.
What was the result of the final PQT?: 3836.01-The test passed on 2018-08-30T17:22:25.
Where / how did you perform the final Eclipse / FastTest ?: 3417.03-Final FastTest completed.
What was the result of the final Eclipse / FastTest ?: 4000.01-The test passed on 30/08/2018 17:32:10.   BT
Today 14:00:53   Today 17:47:37   BT Fault 3-762548671326 Engineer dispatched
Right When Tested; End User Equipment;All BT tests completed ok, for the reported symptoms

However, weirdness. With the new modem included, the combined measured upstream drops by 50% so measured combined u/s speeds are around 0.3Mbps according to various speed testers including AA's one. (In contrast, downstream has as expected gained 2.5 Mbps combined.)

So, Firebrick cockup in config - can't see it. Or upstream packet loss but not downstream. That is all I can think of just now. AA looking into it right now.
Logged

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 30788
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Fourth line goes in next Wed
« Reply #95 on: August 30, 2018, 07:18:38 PM »

So we now have a definite statement that one (if not all four) of the lines serving Torr Gorm are now routed via a (newly installed) primary cross-connection point (cabinet no 10, I believe) near the Claymore Restaurant. (If Mrs Weaver could photograph it, when next passing, a copy of the image would be appreciated, please.)

I appreciate that you will not be able to easily make the following sequence of tests but, ideally, it would be good to connect a computer directly to each of the four modems, in turn, and establish a PPP session from the computer to the end-point in A&A land. For each connection, note the synchronisation speeds and then throughput speeds.

Once that has been completed, reconnect all four modems to the mux (small managed switch) and connect a computer directly in place of the Firebrick FB2700. In theory it should be possible to configure the computer to, once again, establish a PPP session with the A&A end-point. It might be somewhat awkward due to the four VLANS . . .  :-\ 
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.

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 9107
  • Retd sw dev; A&A; 4 7km ADSL2; IPv6; Firebrick
Re: Fourth line goes in next Wed
« Reply #96 on: August 30, 2018, 07:59:26 PM »

I was indeed going to run an ethernet cable directly into that modem instead.

But I am afraid that don't have anything other than the Firebricks that can generate PPP if I understood correctly, no Pcs at hand, nor Macs and I broke the raspberry pi again some while ago.

I can get all the sync speeds courtesy of BT and AA in fact. That is what I relied on before I worked out how to do the whole NAT-through-brick thing.

Modems 2 /3 /4 are all about 440k u/s sync. Modem 2 is about the same as the others, at 2.9Mbps downstream.

The combined downstream measured rate presumably TCP payload according to say AA's speed tester is 10.2 Mbps so exactly as expected since before the combined downstream TCP payload rate was about 7.6Mbps from speedtesters.

With three modems the measured combined upstream was around 1.1Mbps, so I was expecting something like 1.4 - 1.5 Mbps u/s combined TCP payload.

I just wonder what I am doing wrong, or whether there is still some kind of real problem.
Logged

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 9107
  • Retd sw dev; A&A; 4 7km ADSL2; IPv6; Firebrick
Re: Fourth line goes in next Wed
« Reply #97 on: August 30, 2018, 08:01:22 PM »

One other thing, I notice that Mrs Weaver has got links 2 (new) and 4 swapped at the wall sockets, due to eqpt testing last week. I should expect this will not matter as the sync speeds are the same and Firebrick egress rate limited settings are the same too, or am I way way wrong?

I have an iPad monitoring tool that inspects links' states via the Firebrick and it actually rang a bell to tell me that there was a swapped pair of links. Yay. The tool works. (It spotted that the reported BBEU values were the wrong way round.)
« Last Edit: August 30, 2018, 08:04:09 PM by Weaver »
Logged

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 9107
  • Retd sw dev; A&A; 4 7km ADSL2; IPv6; Firebrick
Re: Fourth line goes in next Wed
« Reply #98 on: August 30, 2018, 09:37:14 PM »

Resolved:

After Mrs Weaver swapped the links back the correct way round, the weirdness went away. I don't really understand that.

The two links were supposed to be the same.
« Last Edit: August 30, 2018, 09:54:41 PM by Weaver »
Logged

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 30788
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Fourth line goes in next Wed
« Reply #99 on: August 30, 2018, 09:52:55 PM »

I don't understand it. But you have a good result. And better throughput speeds.  :)
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.

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 9107
  • Retd sw dev; A&A; 4 7km ADSL2; IPv6; Firebrick
Re: Fourth line goes in next Wed
« Reply #100 on: August 30, 2018, 09:54:59 PM »

Tests with a number of speed testers with the links unswapped show that now the combined upstream is about 1.1 Mbps so no improvement at all from adding a link, which is very disappointing indeed, and really perplexing given that obviously a substantial improvment is indeed achievable given the downstream results.
Logged

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 30788
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Fourth line goes in next Wed
« Reply #101 on: August 30, 2018, 10:19:04 PM »

That is very odd.  :(

It is almost as if a cap has been applied to the US. Confused.  ???
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.

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 9107
  • Retd sw dev; A&A; 4 7km ADSL2; IPv6; Firebrick
Re: Fourth line goes in next Wed
« Reply #102 on: August 30, 2018, 11:10:05 PM »

I finally found the answer.

For some reason DLM had got upset and the upstream SNRM had got pushed right up on one of the other modems, probably to a 9dB target. Just now I noticed that the upstream SNRM on that modem #3 was 8.2dB. This had cut the upstream sync speed by over 120k to 318kbps from c. 440k before. Now this meant that the Firebrick was driving that modem way too hard, with an egress rate set for the old incorrect sync rate, and this meant enormous packet loss in that modem as the Firebrick tried to push too much of a share of the packets into it, trying to force it to go at 88% of 440kbps instead of 88% of 318kbps.

With this fixed, the upstream throughput jumped to 1.3Mbps from 1.05-1.1Mbps and that is with the reduced sync rate, 120k down, due to the crazy high target SNRM, so the throughput should be expected to improve to around 1.4Mbps exactly as predicted. So mystery solved completely.

I should have rechecked all the numbers.
Logged

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 30788
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Fourth line goes in next Wed
« Reply #103 on: August 31, 2018, 12:15:20 AM »

I am pleased to know that the mystery is finally solved. Is there no way that the circuits can "find their own levels"? It seems to be somewhat of a weak link that calculations must be made to tell the FIrebrick at what rate it should operate each circuit.
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.

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 9107
  • Retd sw dev; A&A; 4 7km ADSL2; IPv6; Firebrick
Re: Fourth line goes in next Wed
« Reply #104 on: August 31, 2018, 12:47:35 AM »

It is an absolute nuisance that the Brick needs to be told what rate to police the packets at. I am told by RevK that the Firebrick does not actually pump the packets out at a particular rate, and does not hold them back until the correct release time, which is a real shame. It sends packets to the modems straight away. RevK says it merely polices the rate, imposing a maximum rate. It must also split the traffic in the correct fractions between links though, because otherwise I can't see how it would ever work as well or as sensitively as it does.

It is highly error-prone as it is though and needs constant checks. AA gets feedback from BT and TT regarding the line rates and that drives the routers regarding downstream.

If there were a modular software subsystem that could grope some nasty interface exposed by modems, html if really desperate, and find out what the current sync rates upstream are, then there would also need to be the black magic of what I call the 'fudge factor' - a parameter which I calculate to convert sync rate into an IP data rate by using knowledge of the particular protocol stack and its parameters relating to header bloat, PDU size and ATM overheads.

I have not managed to completely automate the process, although it is semi automated, the rate calculations are done by software, and the XML snippet required is generated automatically, the last step remaining is to integrate the Xml snippet with the correct rates in it into the rest of the XML config for the Firebick, because I have a tool already working that uploads a new XML config file into a running Firebrick and causes it to take effect immediately. I can't complete the whole chain because of stupid bugs in some of Apple's Workflow tools that I have used to write the whole lot in and I just cannot get them fixed.

Logged
Pages: 1 ... 5 6 [7] 8