Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: Pauljbl on October 07, 2016, 12:05:55 AM
-
I am trying different leads from modem to faceplate and also with a different faceplate. What's the best way to test for best quality. Is it least errors or best sync speed or other things.
I do have a hg612 to get statistics. How long would you test for?
-
Hmm . . .
I know that the Huawei HG612 has a "bert" (https://en.wikipedia.org/wiki/Bit_error_rate) option to the "xdslcmd" available --
xdslcmd bert [--start <#seconds>] [--stop] [--show]
Perhaps investigate the usage of that command line? :-\
-
Higher sync rates (both upstream and downstream) at the same target SNRM means better quality.
I'd be very interested to hear the results. The likely significance of the modem-to-NTE cable (and faceplate) will I expect depend on what kind of line you have, especially how long and therefore how weak the signal is. The type of line will affect the set of frequencies in use. A weak signal will mean that noise in the local environment is more significant relatively.
-
To be meaningful you will need to do a benchmark test with your current set up. Taking as many stats as you can over a reasonably long period. The main stats you want are SNRM, Sync and errors.
Then change one thing and repeat and compare. And so on until you identify the best combination of modem, cables and faceplate.
Sent from my Nexus 6P using Tapatalk
-
Have just been doing some quick tests leaving 30mins between disconnecting. And have found between the cables I get almost the same sync rate but a slightly higher snrm with one. Does that mean the higher snrm is the better cable?
-
Have just been doing some quick tests leaving 30mins between disconnecting. And have found between the cables I get almost the same sync rate but a slightly higher snrm with one. Does that mean the higher snrm is the better cable?
In theory yes it does. But I doubt your testing was long enough to be really meaningful.
Sent from my Nexus 6P using Tapatalk
-
Let us know which cables do well and badly, if you would? Would need to capture some long-term stats ideally. (MDWS?)
-
Thinking some more about a "bert (https://en.wikipedia.org/wiki/Bit_error_rate)", if the remote DSLAM/MSAN is compliant then surely that is the most appropriate test?
For each different cable, filter and doings, perform a "bert (https://en.wikipedia.org/wiki/Bit_error_rate)" for, say, 600 seconds and note the result. I presume it would be something simple like --
- xdslcmd bert --start 600
- xdslcmd bert --show
I suspect that Konrado5 will have some experience of such testing, although it would be with the typical equipment as used in Poland.
-
Surely Burakkucat is right. Just hope that the kit supports it. Isn't there a test procedure in the standards docs?
Did the old BT ADSL modems that some Openreach engineers had used to have this? Presumably JDSUs can do it?
-
Remember of course that the results will also be wildly different depending on signal levels (line length) and signal types (different frequencies according ADSLx vs VDSL2 and according to line length).
Ideally you need a line like mine which is ultra-long and therefore ultra-weak signal. So the noise that cables let in will be very significant for me. On the other hand VDSL2 users will be good for a high-frequency test, which I can't do, as I don't even have all the ADSL tones never mind the Higher ones that VDSL2 uses. So actually we need a mix of different kinds of users.
A good cable will be good for everyone of course. But some users simply won't see any differences because their circumstances are too forgiving.
-
How will I know if my DSLAM is compliant with Bert?
-
How does the ADSL/VDSL Bert test work?
In my, albeit long ago, experience of Bert tests on leased lines you needed a tester on each end or a loop back on one end.
I know the OR engineer that originally fitted my master socket had a tester that included a Bert test function but I didn't see how he used it.
Anyone any experience?
Sent from my Nexus 6P using Tapatalk
-
I ran the Bert test but got no errors at all does this mean it's not working
# xdslcmd bert --show
xdslcmd: BERT results:
BERT Status = NOT RUNNING
BERT Total Time = 600 sec
BERT Elapsed Time = 600 sec
BERT Bits Tested = 0x000000046D9DF180 bits
BERT Err Bits = 0x0000000000000000 bits
-
I ran the Bert test but got no errors at all does this mean it's not working
# xdslcmd bert --show
xdslcmd: BERT results:
BERT Status = NOT RUNNING
BERT Total Time = 600 sec
BERT Elapsed Time = 600 sec
BERT Bits Tested = 0x000000046D9DF180 bits
BERT Err Bits = 0x0000000000000000 bits
Does the status "Not Running" mean it didn't run out that it has finished?
I would think zero errors is very suspect. Or have you got a perfect line?😋
Sent from my Nexus 6P using Tapatalk
-
How does the ADSL/VDSL Bert test work?
In my, albeit long ago, experience of Bert tests on leased lines you needed a tester on each end or a loop back on one end.
I know the OR engineer that originally fitted my master socket had a tester that included a Bert test function but I didn't see how he used it.
Anyone any experience?
Sent from my Nexus 6P using Tapatalk
He/She wont have conducted a BerT test ........... they will have used the 'DSL Close out' test that basically reports FEC/CRC rates (I wouldn't know for sure if the two different tests give the same readings ??).
BerT tests are only performed on ISDN circuits using a Harrier test set.
-
# adslctl bert --show
adslctl: BERT results:
BERT Status = NOT RUNNING
BERT Total Time = 600 sec
BERT Elapsed Time = 600 sec
BERT Bits Tested = 0x0000000213AA3100 bits
BERT Err Bits = 0x000000000000004E bits
It is caused by some CRC errors during test.
16415 kbps, SNR margin 4.8 dB.
-
I found in another thread that the Bert command doesn't work with vdsl only ADSL for some reason.
So is there any best way to test
-
I found in another thread that the Bert command doesn't work with vdsl only ADSL for some reason.
So is there any best way to test
Did you get anywhere with this? It's been a while.
Best way to "test" is to set up some router stats on your modem and a ping monitor on thinkbroadband.com. upload the data to MyDslWebStats.co.uk and gather a few days info together. That will enable you and/or the experts on here to see what's happening on your line and advise what can be done to improve it. Patience is a good quality to have when doing this as, if you need to make any changes, you will then need to take more stats to see what, if anything, has changed.
Sent from my Nexus 6P using Tapatalk
-
Hi
Also the 'BERT' test is just a snapshot of errors, and these are bursty in nature anyway, plus the better cable might allow a higher sync rate because of receiving some usable higher frequencies but these are then more susceptible to errors, which puts the error rate up. VDSL like ADSL is designed to run with some errors anyway.
I think the best metric is overall sync speed and available margin, but this will vary each time a sync is made and those differences can easily mask any changes the cable has caused.
Besides, given your VDSL signal has likely travelled along 100, 200 or 500 metres + of cable already, another metre or two isn't likely to make much difference. Provided the cable is twisted pairs and you don't have any bad local RF, they are all going to perform pretty much the same, unless you are adding 10s of metres as an extension, in which case Cat5e is what you want.
Regards
Phil