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: Upstream SNRM/bitloading weirdness  (Read 2010 times)

GaryW

  • Member
  • **
  • Posts: 96
Upstream SNRM/bitloading weirdness
« on: December 13, 2017, 07:54:20 PM »

Hi all,

I'm seeing a weird inconsistency between the reported upstream SNRM and what I see when I look at SNR/tone and bits/tone.  I'm using  a Billion 8900AX-2400 and I'm on an ECI DSLAM.

My modem is only using US0 (tones 6-31) - probably due to the long line. The SNRM in the basic stats is around 6db, but when I look at the SNR/tone and bits/tone data it shows around 10-12db margin for each and every tone...  Overall I'm only getting a little over 500 kbps upstream...but if the "missing" 2 bits were added to each tone I'd be getting somewhere over 600kbps.

What's even weirder, is that when I used to use a (Lantiq-based) BT HH5a I did get over 600kbps, but with every Broadcom based modem I've used (BT Smart Hub, TP-Link VR2600, and now the Billion) I only ever get a little over 500kbps!

Has anybody seen similar behaviour?  Would switching to a Lantiq-based modem restore the upstream performance? (but not the HH5a as it's lacking in other ways and downstream performance was much worse than the broadcom modems)

You can see my stats on MWDS, username GaryW.

Thanks,
Gary
Logged
EE 4G - Huawei B618s-22d - BT WHWF

roseway

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 43568
  • Penguins CAN fly
    • DSLstats
Re: Upstream SNRM/bitloading weirdness
« Reply #1 on: December 13, 2017, 10:43:05 PM »

Welcome to the Kitz forum.

The 'inconsistency' is actually quite consistent. The SNRM is the SNR margin but the SNR per tone graph shows the actual SNR for each tone. SNRM is the difference between the actual SNR and a base value which is defined in terms of the error rate expected at that level of SNR.
Logged
  Eric

GaryW

  • Member
  • **
  • Posts: 96
Re: Upstream SNRM/bitloading weirdness
« Reply #2 on: December 13, 2017, 11:52:31 PM »

Welcome to the Kitz forum.

The 'inconsistency' is actually quite consistent. The SNRM is the SNR margin but the SNR per tone graph shows the actual SNR for each tone. SNRM is the difference between the actual SNR and a base value which is defined in terms of the error rate expected at that level of SNR.

Hi,

It does indeed show the actual SNR, and if you subtract the 3db per bit you should be left with the SNRM for that tone...which is where my figure of 10-12db SNRM for each tone comes from.  In contrast, for downstream the SNRM per tone is fairly consistent with the overall stated SNRM.  Trust me, if you look at the graphs there's a huge gap above the bitloading for each tone on the upstream...whereas for downstream there's a 6ish db gap above most tones.   (It's hard to see directly on MWDS as you can't overlay the graphs, but on dslstats it leaps out of the page).

Logged
EE 4G - Huawei B618s-22d - BT WHWF

roseway

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 43568
  • Penguins CAN fly
    • DSLstats
Re: Upstream SNRM/bitloading weirdness
« Reply #3 on: December 14, 2017, 07:49:38 AM »

Quote
if you subtract the 3db per bit you should be left with the SNRM for that tone

I don't know where that 3 dB figure came from, but it's a false assumption. In fact you can't sensibly talk about SNRM on a tone by tone basis - as I said in my previous message, the SNRM base level is defined in terms of the error rate for the connection as a whole. The SNRM base level differs between different modems and different connections. Just for comparison you can see my bitloading graph with SNR per tone superimposed. The downstream gap is about 2 dB, and the upstream gap is about 5 dB.
Logged
  Eric

GaryW

  • Member
  • **
  • Posts: 96
Re: Upstream SNRM/bitloading weirdness
« Reply #4 on: December 14, 2017, 09:46:47 AM »

Hi,

Well, that 3dB figure came for a number of places, including this web-site!  It's also confirmed by the chart that you included in your post: compare the left-hand scale (bits) and the right-hand scale (dB) and you'll see that each bit corresponds to 3dB....  For the SNRM for each tone you've actually quoted the number of bits (left-hand scale) rather than the dB (right-hand scale).  Your graph shows a typical SNRM for downstream tones of 4-6dB (and according to MWDS your downstream SNRM is about 4dB; it also shows that the typical SNRM for upstream tones is around 12dB (and according to MWDS your upstream SNRM is about 10dB).

In other words, your upstream and downstream make sense...whereas my upstream doesn't (I've got a similar upstream SNRM per tone to yours on my graphs, but my modem is saying my overall SNRM is about 6dB rather than the 10dB that yours is saying).

I notice that you're on a Huawei cabinet with a Broadcom modem, whereas I'm on an ECI cabinet with a Broadcom modem.  Hence my original question - will I get some of the "missing" bits back with a Lantiq chipset?
Logged
EE 4G - Huawei B618s-22d - BT WHWF

ejs

  • Kitizen
  • ****
  • Posts: 2078
Re: Upstream SNRM/bitloading weirdness
« Reply #5 on: December 15, 2017, 08:34:55 PM »

I think the only way to really know if any particular modem will work better or worse on your line than another is to try it and see.
Logged

NewtronStar

  • Kitizen
  • ****
  • Posts: 4898
Re: Upstream SNRM/bitloading weirdness
« Reply #6 on: December 15, 2017, 08:53:10 PM »

But the OP won't be able to see the difference on DSLstats when using a Lantiq-based modem as they are not supported/capable all they would see is a change of sync and attainable on the Downstream and Upstream in the modem stats for that unit.
Logged

ejs

  • Kitizen
  • ****
  • Posts: 2078
Re: Upstream SNRM/bitloading weirdness
« Reply #7 on: December 16, 2017, 07:27:12 AM »

And if it gave more bandwidth, would the lack of stats matter?

All the per-tone data bits, snr, qln, hlog, gains is available from something with full access to the standard Lantiq command line interface, which would probably have to be an unlocked ECI modem or TP-Link 9980, or something running OpenWRT/LEDE. I think quite a lot of stats are available from DrayTek devices, I don't know if anyone has tried seeing what stats can be obtained from the newer Netgear Lantiq VDSL2 devices.
Logged

GaryW

  • Member
  • **
  • Posts: 96
Re: Upstream SNRM/bitloading weirdness
« Reply #8 on: December 18, 2017, 08:49:45 AM »

So, in line with ejs's suggestion, I also figured the only way to find it out was to try it...so I bought a Draytek 2760 modem/router!  The results were interesting...

Upstream sync did improve, back to the level I used to get with a HH5a - around 620k versus the 520k I get with my Billion router, so about a 20% improvement.  So it looks like it is a chipset thing.

However, the downstream performance was dreadful!  The Draytek could only manage just under 11400k versus the 14999k I'm getting with the Billion - so the Billion is over 30% better than the Draytek.  I'm pretty sure that I'm currently banded at 15M so the Billion can probably do better if DLM relents.  Again, the HH5a used to give the same downstream sync as the Draytek is now doing, so also looks like a chipset thing.

As you can imagine, the Draytek is being returned!  Interestingly, the Draytek also report 33dB downstream attenuation versus the 27.5dB reported by the Billion, and the Draytek also showed a max data rate of only 13500k versus the 19500k I see from the Billion (and the 14999k actual sync I'm getting with the Billion...)

Conclusion?  If you're on a long line, don't worry about whether your cabinet is ECI or Huawei...just go with Broadcom chipsets.
Logged
EE 4G - Huawei B618s-22d - BT WHWF

roseway

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 43568
  • Penguins CAN fly
    • DSLstats
Re: Upstream SNRM/bitloading weirdness
« Reply #9 on: December 18, 2017, 09:21:05 AM »

I've got a vague memory of trying a Draytek modem/router some years ago and getting a similar result. It turned out that the product was set up by default to enforce a higher target downstream SNRM, and this partly accounted for the lower connection speed. It was possible to override this default, but even doing that didn't bring the speed up to what I got with other comparable products.
Logged
  Eric
 

anything