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:

Author Topic: ECI Line Card 0xb206 vs 0xd086  (Read 3539 times)

Ixel

  • Kitizen
  • ****
  • Posts: 1282
ECI Line Card 0xb206 vs 0xd086
« on: October 17, 2017, 12:59:55 PM »

I don't know if this is the right place to post this but it might interest a few people perhaps. What I've found is that 0xd086 is shown on the ECI /r (unlocked) as newer than 0xb206.

The following is 0xd086 on my second line (used on AAISP):
Code: [Select]
ATU-C Vendor ID:                          Infineon 208.134
ATU-C System Vendor ID:                   43,45,20,49,65,74,65,6C
Chipset:                                  Lantiq-VRX200 Unknown
Firmware Version:                         5.8.1.8.1.6
API Version:                              4.17.18.6
XTSE Capabilities:                        0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2
Annex:                                    B
Line Mode:                                G.993.2 (VDSL2)
Profile:                                  17a
Line State:                               UP [0x801: showtime_tc_sync]
Forward Error Correction Seconds (FECS):  Near: 89708 / Far: 1177
Errored seconds (ES):                     Near: 1103 / Far: 183
Severely Errored Seconds (SES):           Near: 0 / Far: 0
Loss of Signal Seconds (LOSS):            Near: 0 / Far: 0
Unavailable Seconds (UAS):                Near: 35 / Far: 35
Header Error Code Errors (HEC):           Near: 0 / Far: 0
Non Pre-emtive CRC errors (CRC_P):        Near: 546 / Far: 0
Pre-emtive CRC errors (CRCP_P):           Near: 0 / Far: 0
Power Management Mode:                    L0 - Synchronized
Latency / Interleave Delay:               Down: Fast (0.0 ms) / Up: Fast (0.0 ms)
Data Rate:                                Down: 75.255 Mb/s / Up: 15.990 Mb/s
Line Attenuation (LATN):                  Down: 17.9dB / Up: 24.0dB
Signal Attenuation (SATN):                Down: 17.8dB / Up: 23.8dB
Noise Margin (SNR):                       Down: 6.0dB / Up: 6.0dB
Aggregate Transmit Power (ACTATP):        Down: 6.7dB / Up: 13.0dB
Max. Attainable Data Rate (ATTNDR):       Down: 75.661 Mb/s / Up: 15.956 Mb/s
Line Uptime Seconds:                      1902
Line Uptime:                              31m 42s

This is 0xb206, same DSLAM and cabinet just a different line card (used via Zen for my original and first line):
Code: [Select]
ATU-C Vendor ID:                          Infineon 178.6
ATU-C System Vendor ID:                   45,43,49,20,74,65,6C,65
Chipset:                                  Lantiq-VRX200 Unknown
Firmware Version:                         5.8.1.8.1.6
API Version:                              4.17.18.6
XTSE Capabilities:                        0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2
Annex:                                    B
Line Mode:                                G.993.2 (VDSL2)
Profile:                                  17a
Line State:                               UP [0x801: showtime_tc_sync]
Forward Error Correction Seconds (FECS):  Near: 159 / Far: 121341
Errored seconds (ES):                     Near: 0 / Far: 519
Severely Errored Seconds (SES):           Near: 0 / Far: 3
Loss of Signal Seconds (LOSS):            Near: 0 / Far: 1027
Unavailable Seconds (UAS):                Near: 898 / Far: 898
Header Error Code Errors (HEC):           Near: 0 / Far: 0
Non Pre-emtive CRC errors (CRC_P):        Near: 0 / Far: 0
Pre-emtive CRC errors (CRCP_P):           Near: 0 / Far: 0
Power Management Mode:                    L0 - Synchronized
Latency / Interleave Delay:               Down: Interleave (10.0 ms) / Up: Interleave (8.0 ms)
Data Rate:                                Down: 52.981 Mb/s / Up: 11.379 Mb/s
Line Attenuation (LATN):                  Down: 20.7dB / Up: 24.5dB
Signal Attenuation (SATN):                Down: 20.1dB / Up: 24.4dB
Noise Margin (SNR):                       Down: 6.1dB / Up: 6.1dB
Aggregate Transmit Power (ACTATP):        Down: 6.7dB / Up: 6.9dB
Max. Attainable Data Rate (ATTNDR):       Down: 62.147 Mb/s / Up: 11.430 Mb/s
Line Uptime Seconds:                      171
Line Uptime:                              2m 51s

So 0xb206 is apparently v178.6 and 0xd086 is apparently v208.134. I wonder if d086 is limited to newer line cards or whether more line cards in ECI cabinets will get changed to this at a later date?

Also yes, I know my stats on the second line are still bad (error seconds are through the roof, about 3-5 error seconds for every 10 seconds of uptime by the looks of it). It's not affecting the connection however, and I'm also amazed DLM hasn't intervened yet unless the locked ECI /r I was using was reporting different statistics. If DLM intervenes tonight then I might try and find out what firmware version the ECI /r locked modem may be using and then try to put that on my unlocked ECI /r. Unless someone happens to know the version or know where I can get the file?

Anyway, hope someone finds this useful and hope I've posted this in the right section (if not please move it accordingly).
Logged

renluop

  • Kitizen
  • ****
  • Posts: 3326
Re: ECI Line Card 0xb206 vs 0xd086
« Reply #1 on: October 17, 2017, 03:33:23 PM »

Code: [Select]
AAISP ATU-C System Vendor ID:43,45,20,49,65,74,65,6C
Zen ATU-C System Vendor ID: 45,43,49,20,74,65,6C,65

Likely irrelevant, but why is the order of elements in the IDs different?
Logged

Ixel

  • Kitizen
  • ****
  • Posts: 1282
Re: ECI Line Card 0xb206 vs 0xd086
« Reply #2 on: October 17, 2017, 03:36:57 PM »

Code: [Select]
AAISP ATU-C System Vendor ID:43,45,20,49,65,74,65,6C
Zen ATU-C System Vendor ID: 45,43,49,20,74,65,6C,65

Likely irrelevant, but why is the order of elements in the IDs different?

Good question, I wonder why too as I don't know. Surely can't solely be related to the version being different?
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: ECI Line Card 0xb206 vs 0xd086
« Reply #3 on: October 17, 2017, 05:33:43 PM »

AAISP ATU-C System Vendor ID: 43,45,20,49,65,74,65,6C
Zen   ATU-C System Vendor ID: 45,43,49,20,74,65,6C,65


Taking those two lines, we can see that each Vendor ID is a sequence of blocks of 8-bits.

Notice that a sequence of 16-bits from one line is just the same from the other line, if you exchange the two 8-bits blocks.

[Edited to correct my nonsense about the number of bits.]
« Last Edit: October 18, 2017, 03:02:01 PM by burakkucat »
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.

Browni

  • Reg Member
  • ***
  • Posts: 137
Re: ECI Line Card 0xb206 vs 0xd086
« Reply #4 on: October 17, 2017, 06:11:58 PM »

Little endian display vs big endian?

Ixel

  • Kitizen
  • ****
  • Posts: 1282
Re: ECI Line Card 0xb206 vs 0xd086
« Reply #5 on: October 17, 2017, 06:13:45 PM »

AAISP ATU-C System Vendor ID: 43,45,20,49,65,74,65,6C
Zen   ATU-C System Vendor ID: 45,43,49,20,74,65,6C,65


Taking those two lines, we can see that each Vendor ID is a sequence of blocks of 8-bits.

Notice that a sequence of 16-bits from one line is just the same from the other line, if you exchange the two 8-bits blocks.

[Edited to correct my nonsense about the number of bits.]

I see, well just for reference...

First one says: CE Ietel

Second one says: ECI tele

Perhaps it's a bug either in the firmware either on the line card or the modem. I'm more curious to see if DLM takes action overnight however, as I'm currently up to 9984 error seconds on the downstream and still rising. I had the new line active on Friday afternoon of last week originally with the HG612 until I saw the error seconds going through the roof, then I switched to a locked ECI /r and DLM didn't intervene even this morning. Stats are from the unlocked ECI /r with LEDE.

One other thing I discovered by mistake was that I was able to use my Zen login on my new AAISP line (second line). This happened by accident when engineer plugged everything back in. I was expecting it to not work and for me to change it and then suddenly I noticed I had internet access haha. I quickly changed it over to AAISP's login however :).
« Last Edit: October 18, 2017, 03:03:07 PM by burakkucat »
Logged

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 7382
  • VM Gig1 - AAISP L2TP
Re: ECI Line Card 0xb206 vs 0xd086
« Reply #6 on: October 17, 2017, 06:47:12 PM »

yep d is newer than b on hexa format :)

sad news on the errors Ixel, I was hoping you would be in the clear on the 2nd line.  Seems openreach need to find the source in your local area to get this fixed, have you asked aaisp about that yet?
« Last Edit: October 17, 2017, 06:49:45 PM by Chrysalis »
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: ECI Line Card 0xb206 vs 0xd086
« Reply #7 on: October 17, 2017, 09:25:04 PM »

Little endian display vs big endian?

Ack.

. . . well just for reference...

First one says: CE Ietel

Second one says: ECI tele

[Duo2 ~]$ echo "CE Ietel" | dd conv=swab 2>/dev/null
ECI tele
[Duo2 ~]$

Somebody, somewhere, has had a "minor mishap" with their code!  :D
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.

Ixel

  • Kitizen
  • ****
  • Posts: 1282
Re: ECI Line Card 0xb206 vs 0xd086
« Reply #8 on: October 17, 2017, 09:27:46 PM »

yep d is newer than b on hexa format :)

sad news on the errors Ixel, I was hoping you would be in the clear on the 2nd line.  Seems openreach need to find the source in your local area to get this fixed, have you asked aaisp about that yet?

Indeed, and no I haven't yet. I will have to try eventually though, just worried they might just tell me that the CIDT passes and I've got virtually no packet loss so no indication of a service affecting fault as such (at least not until DLM kicks in and sends my ping up and possibly sync rate down, if it ever does, odd it never did when I had the locked ECI /r in place). I'm eager to see if it kicks in tomorrow morning with the unlocked ECI /r running today, just had a wild theory that my Zen login via the AAISP line perhaps broke an aspect of DLM but I doubt it haha. If DLM kicks in then I will revert to the locked ECI /r and leave that running to see if fastpath returns and sticks, if it does then either the locked ECI /r is not recording errors correctly or is just miraculously recording less errors.

I was told by the Openreach engineer who installed the second line that he spoke with the local engineers (he wasn't from my area), presumably after I mentioned why I wanted a second line and issues with my first line, and there's a manhole on the main road which has a degraded joint (has had water in or such). It needs sorting but the problem is traffic, so I was told. So, unless an ISP like AAISP badgers Openreach I'm guessing it probably won't get done until it's really bad.

Stats as of a moment ago:
Code: [Select]
ATU-C Vendor ID:                          Infineon 208.134
ATU-C System Vendor ID:                   43,45,20,49,65,74,65,6C
Chipset:                                  Lantiq-VRX200 Unknown
Firmware Version:                         5.8.1.8.1.6
API Version:                              4.17.18.6
XTSE Capabilities:                        0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2
Annex:                                    B
Line Mode:                                G.993.2 (VDSL2)
Profile:                                  17a
Line State:                               UP [0x801: showtime_tc_sync]
Forward Error Correction Seconds (FECS):  Near: 4108745 / Far: 1315
Errored seconds (ES):                     Near: 16317 / Far: 203
Severely Errored Seconds (SES):           Near: 0 / Far: 0
Loss of Signal Seconds (LOSS):            Near: 0 / Far: 0
Unavailable Seconds (UAS):                Near: 35 / Far: 35
Header Error Code Errors (HEC):           Near: 0 / Far: 0
Non Pre-emtive CRC errors (CRC_P):        Near: 8859 / Far: 0
Pre-emtive CRC errors (CRCP_P):           Near: 0 / Far: 0
Power Management Mode:                    L0 - Synchronized
Latency / Interleave Delay:               Down: Fast (0.0 ms) / Up: Fast (0.0 ms)
Data Rate:                                Down: 75.255 Mb/s / Up: 15.990 Mb/s
Line Attenuation (LATN):                  Down: 17.9dB / Up: 24.0dB
Signal Attenuation (SATN):                Down: 17.8dB / Up: 23.8dB
Noise Margin (SNR):                       Down: 5.9dB / Up: 6.0dB
Aggregate Transmit Power (ACTATP):        Down: 6.7dB / Up: 13.0dB
Max. Attainable Data Rate (ATTNDR):       Down: 75.629 Mb/s / Up: 15.913 Mb/s
Line Uptime Seconds:                      29893
Line Uptime:                              8h 18m 13s

Ack.

[Duo2 ~]$ echo "CE Ietel" | dd conv=swab 2>/dev/null
ECI tele
[Duo2 ~]$

Somebody, somewhere, has had a "minor mishap" with their code!  :D

Nice haha.
Logged

Browni

  • Reg Member
  • ***
  • Posts: 137
Re: ECI Line Card 0xb206 vs 0xd086
« Reply #9 on: October 17, 2017, 10:43:42 PM »

Never thought of the 0x20 being the ASCII code for a space  :P

Ixel

  • Kitizen
  • ****
  • Posts: 1282
Re: ECI Line Card 0xb206 vs 0xd086
« Reply #10 on: October 18, 2017, 10:14:21 AM »

As expected, DLM applied error correction at 6am. I've switched back to the ECI /r using Openreach's firmware and will wait for it to return to fastpath if it does (I imagine it'll take a few days at most if it remains ILQ green). Interestingly I did try a spare ECI /r which is unlocked on LAN port 1 using the default firmware, before it lost fastpath due to the high error seconds count, and for the short time I ran it the ES count was negligible. Either the ECI /r with the original firmware designed for it actually counts wrong or it just works better somehow. I know the ECI /i's original firmware definitely counted wrong, sometimes giving very strange numbers. The ping graph was also smoother when running the ECI /r with the original firmware.

If I can easily get back to fastpath then I have two options, 1) For the modem I only use the ECI /r with the original firmware (locked or unlocked) or 2) I contact AAISP and explain the situation stemming back to the first line. Personally I feel I need to take up option 2, but on the other hand if the ECI /r with the original firmware works fine then maybe I should stay with that. However the other question is what happens if and when G.INP is active on my line again, will the current ECI modem firmware be updated and therefore introduce the high amount of error seconds I'm experiencing on other modems/firmware.

I did try copying the VDSL bin file from the unlocked ECI /r to the ECI /r with LEDE but sadly it didn't remain in sync for more than 10-15 seconds. I imagine the VDSL firmware just kept crashing on LEDE for some reason, otherwise the ES count never went up from 0 when I checked the stats.

EDIT: I've emailed AAISP now, felt like I wrote an essay with the length of it but I wanted to be as detailed as possible. I asked on IRC briefly explaining my problem and AA-Shaun said they should be able to help with it. Fingers crossed!
« Last Edit: October 19, 2017, 11:54:46 AM by Ixel »
Logged