Kitz Forum
Broadband Related => Broadband Hardware => Topic started by: les-70 on September 22, 2014, 08:29:25 PM
-
I have used a ZyXEL VMG8324, a Billion 8800NL, an HG630 and an Hg658B all with 63168 chipsets on my line. The results and typical error rates differ. I have compared them all with the HG612 which has the 6368 chipset with the 038 dsl driver. The FTTC cabinet is ECI. Each modem has been used in turn for periods of 1 day at least 5 times when the speed is capped but less times uncapped to avoid errors annoying the DLM
For reference:: My line has consistently tolerated 3-4 resync per day with no DLM intervention. My only DLM intervention occurred with the ZyXEL VMG8324 presumably due to its high error rate. I do however usually have the speed capped to keep down error rates. For comparison purposes. The minimum attainable seen on my line is 73Mb/s but for nearly two weeks now it has been 78Mb/s (speeds with HG612) ( someone on holiday I suspect)
With Hg612 and no speed cap SNRM 6db -- average daily errored sec/hour is about 30-40 (with no thunderstorms).
With the HG612 sync speed capped to give a SNRM of about 8db. (typically a loss of 8Mb/s of the sync)-- average daily-- average daily errored sec/hour is about 10-15 (with no thunderstorms).
With the HG612 sync speed capped to give a SNRM of about 9db. (typically a loss of 12Mb/s of the sync) errored sec/hour is about 7-10 (with no thunderstorms).
Results:----
ZyXEL VMG8324 (with 039 dsl driver) gave attainable up by+ 4Mb/s but actual sync +2Mb/s but error rate about 4X HG612. The factor of 4 persisted even if the ZyXEL and Hg612 were both speed capped to the same speed. The XyXEL then reported a better SNRM +1db but still had X4 the errors. (The ZyXEL may have been faulty?)
Billion 8800NL (with 039 dsl driver) gave attainable up by+ 4Mb/s but actual sync +2Mb/s but error rate about 1.5X HG612. The factor of x1.5 persists even if the Billion and Hg612 are both speed capped to the same speed. The Billion then reports a better SNRM +1db but still 1.5X the errors.
HG635 (from China) (with 037 dsl driver). Gave attainable up by+ 2Mb/s but actual sync +1Mb/s but error rate about 2X HG612. The dsl drver has no speed cap option.
Hg658 ((from China) (with 037 dsl driver). Gave attainable up by+ 1Mb/s but actual sync +1Mb/s but error rate about 1.5X HG612. The dsl driver has no speed cap option.
I have concluded that HG612 is significantly better on my line with the Billion a second choice and of course an all in one. It makes me wonder if the 6368 chipset deals better with noise giving errors.?
I wonder if any others using the 63168 modems can look at their error stats in details c.f a HG612. No two lines have the same short of noise and error issues so I wonder how general my finding are??
-
I think Ive mentioned it elsewhere, but will do so again here for completeness. But I really cant see much difference between the 2 on my line when it comes to error rates. Possibly a tad less with the Zyxel but nothing worth any mention, Im talking perhaps a couple.
There is one difference between the two though that I have noticed and thats bit-swap.
If I used the HG612, then bitswap would more or less be static throughout the day.. and my graphs from the HG612 would form a fairly even line.
The shape on the Zyxel is entirely different, it does nothing for much of the day but will always peak in the evenings.
To show what I mean.
-
I had noticed the bitswap differences. I wonder if the different experience I have is because your line has a lot less errors than mine in the first place. Your syncing at 80/20 with about 8db SNRM and you look to have about 3-4 errored secs /hour c.f. the 10 -15 I would usually get with that value of SNRM. The cause of my errors may also be noise with different characteristics, other than just size, to those on your line. Hence the interest in a variety of user experiences.
-
As you say its possible that different types of noise affect differently. Its a shame that noone could get the dsl_phy from the zyxels f/w to work on the HG612.
I dont see anything in my SNRm to indicate why I get that peak bitswap without fail each day, but I suppose its possible that theres something local to me which only affects a couple of tones to bitswap out and thereby insufficient to affect the overall SNRm average. It is strange that it wasnt there on the HG612.. but then again the HG612 was constantly bitswapping so probably did a total of more swaps over the course of the day. ???
Aside from the improved SNRm... the bitswap pattern is the only difference I see.
The broadcoms have always worked pretty well on this line.. and I get quite a lot more errors with a lantiq.. plus the SNRm tends to move a bit more.
When I was testing the TPlink I discovered a bug on something and they sent me a tool which real time monitors the SNR in a graphical format so you see SNR shifting constantly. It was quite interesting to note how much movement I constantly had in the evenings at around tone 250. Which co-incidentally is where for a loooong time where Ive always maintained was crosstalk from adsl lines. Since weve been able to see QLN graphs, sure enough theres the typical what I call the inverted shallow bowl that centers around my tone 225 which often identifies cross talk.
So whether most of the 'noise' that effects this line is crosstalk and not much from elsewhere.. who knows.
-
@les - I just noticed today when looking at Aardvarks mydslwebstats for something else, that he also sees a similar increase in bitswap during the evenings, but pretty quiet during the day. So obviously there does perhaps to be some difference in the way it handles bit-swap.
-
If I used the HG612, then bitswap would more or less be static throughout the day.. and my graphs from the HG612 would form a fairly even line.
The shape on the Zyxel is entirely different, it does nothing for much of the day but will always peak in the evenings.
Were you still using an older firmware version when you generated the HG612 graphs?
My longer line than yours is obviously more susceptible to 'noise', but I saw a big difference in DS bitswapping after my HG612's firmware was updated.
The first 30 day graph is from before the firmware was updated (a year ago) & the 2nd shows 30 days back from this evening.
I believe all the newer type modems already include 'updated' firmwares, so that could explain some of the difference.
I reckon the significantly increased DS bitswapping (particularly in the evenings) has actually made connections more stable & in some cases allowed higher sync speeds as bitloading bins/tones are now swappable rather than being marked as unusable.
-
I reckon the significantly increased DS bitswapping (particularly in the evenings) has actually made connections more stable & in some cases allowed higher sync speeds as bitloading bins/tones are now swappable rather than being marked as unusable.
I don't know BE1 having a few bins/tones during the evening RFI and they are not swapping they are marked as unused.
-
Perhaps I'm lucky & I don't experience the same amount of RFI as you do.
As Kitz mentioned, no two connections are identical & my comparison is only regarding (improved) changes in performance on my own connection.
I wonder if your connection would perform even worse in the evenings nowadays if you were still using the older firmware version :-\
-
Perhaps I'm lucky & I don't experience the same amount of RFI as you do.
no two connections are identical
That's the god dam truth BE1 :(
-
Yes BE I was using one of the older firmwares as Ive been using either the Zyxel or the TPlink for over 6 months now, so I never installed the latest HW's.
The 2 that I showed in the above caps were last full day with the HG612 and first full day with the Zyxel, just to rule out deterioration due to time and extra lines added to the cab.
-
If I used the HG612, then bitswap would more or less be static throughout the day.. and my graphs from the HG612 would form a fairly even line.
The shape on the Zyxel is entirely different, it does nothing for much of the day but will always peak in the evenings.
Were you still using an older firmware version when you generated the HG612 graphs?
My longer line than yours is obviously more susceptible to 'noise', but I saw a big difference in DS bitswapping after my HG612's firmware was updated.
Kind of a double post with here (http://forum.kitz.co.uk/index.php?topic=14343.15), but I feel its relevant in this thread too as I know les-70 is monitoring differences between the 2 chipsets.
@ BE, Ive just noticed when looking at Ronski's stats that he also displays the peak evening bitswap. I attach below a copy so you can see how it changes on his line compared to the HG612.
@ Les-70 - thought you may be interested in his error rate with the Zyxel which got put on 5 days ago. Ive included a month because thats a period where hes been on the same DLM profile. Ronski's DLM profile has decreased today so I wouldn't be surprised to see more Errors this evening.
You can see that for the past 5 days his error rate has perhaps increased by a couple per night.. but based over the full month it doesn't appear to be performing noticeably worse than the HG612. He's got an increased sync speed of approx 2.5Mb using the Zyxel (44414 -v- 41880)
-
Thanks for pointing that out. It does look as though Ronski's error rate in the last 5 days may have increased by at least as much as the x1.5 I find with 8800NL. It is hard to judge from the plots especially when it has gaps due the computer not running. The error rates don't however look big enough to bother about. When sync uses the extra sync speeds from 63168 I would be inclined to forgive the error rate as consequence of the extra speed. However it is getting the same error rate increase when the sync speed is capped, and 63168 gives instead a higher snmr, that disappoints me.
I wonder if mydsl webstats could have the option to average error rate stats between resyncs. I may make a suggestion in the mydslwebstats thread.
Could you post a plot of your bitswaps per tone some time? I wonder if that over 24 hours would give an indication of differences the line characteristic. i don't have an old one and will post one here this evening when dslstats has collected a longer sample. I can say in advance that most of my bitswapping is in the D3 band
-
Here you go :)
-
my bitswap goes up and down day to evening also but not much of a swing.
The amount of bitswapping from line to line is related to the noise its having to deal with, check 60 day history on my line and can see clear difference from old pair to new.
Now my US bitswap is pretty much 0, and my DS bitswap has reduced on the new pair.
I also expect if I had a short E side like kitz so got to use full power on D1, I would have much lower DS error rates and as such lower DS bitswaps.
-
I attach a current 8800NL (038 dsl driver) bit swap per tone. Since I am in standby mode a lot I think the count is rather less than it should be. The total is probably best deduced from the bitswaps per min anyway. I would say I would my line/modem is a significantly busier swapping in D3 than yours, I recall seeing D3 a lot busier in the evening. That also "seems" to be where the 63168 gains most of its extra bit load on my line. It is possible that with respect to the different modem error behavior, the significant line difference between us is extra noise fluctuations in D3.
-
I had to restart my PC so the bit swap/tone below is just a short early evening period. it shows how my line has most swaps in band D3 and as noted this may well lead to different results c.f. lines that don't show this.
-
Ive just reset my bitswap graph so I'll post that later. It may give us a more comparable result as regards to time span :)
-
Don't take that graph too literally. The modem doesn't actually supply bitswaps per tone information. I assemble the graph by analysing the changes in bitloading on each tone, and making the assumption that there's some correlation between bitloading changes and bitswaps.
-
I guessed that would be the case. I am taking it as an indicator of the tones which have a time variation in their SNRM.
-
Here you go, as promised... I know its not exactly 24hrs, but I hope its of some use.
-
Thanks for that. It definitely looks like your line has less noise variations than mine and a lot less in the D3 band where the 63168 chipsets seem to increase bit loading. I guess that may indeed be the reason for our different experiences with the 63168 devices. It is plausible that on my line putting more bits in D3 will increase error rates.
Separate from this thread I am now running with a HG612 and the old NTE2005 adsl v1,0 SSFP which unlike the Mark2 and Mark3 has no "RF3" type device in it. With the NTE-2005 I get a higher attainable, due again to more bit loading in D3. So far the error rate has reduced too but it is too soon to be sure about. The impact is a smaller version change seen when running my line on an actual RF3 and then removing it. Hence me thinking it may be real. If the lower errors with the NTE-2005 persist I may retest the 8800NL on the new arrangement.
-
Out of interest have you tried a lantiq chipset.. and if so is it any better/worse?
-
The BT ECI/r modem gave me a lower sync and although it is unlocked I don't think it is easy (possible?) to get the error stats. I gave up quite quickly though as the BCM chipset devices are so much more convenient.
-
for the 2 devices is it possible to have a sticky with recommended firmwares?
for lantiq they sync lower kitz even on a ECI dslam.
my fritzbox 3370 is lantiq and it syncs extremely low on interleaving and a bit lower on fast path.
-
Thanks for that. It definitely looks like your line has less noise variations than mine and a lot less in the D3 band where the 63168 chipsets seem to increase bit loading. I guess that may indeed be the reason for our different experiences with the 63168 devices. It is plausible that on my line putting more bits in D3 will increase error rates.
Mine seems to have a lot more variation in the D1 & D2 bands, but like you say not as much in D3.
My D1 band tends to get a lot of variance at around tone 250 and just below.. this is where when I had the Lantiq on I could see a lot of shifting of the SNR in real-time (http://forum.kitz.co.uk/index.php?topic=14467.0) in an area that I suspect is due to adsl/adsl2+ crosstalk. I think this same issue relates even as far back as when on adsl2+ because I could see the telltale shallow dish over those same tones even then.
Just proves that every line is different and that none are perfect. :/
-
for the 2 devices is it possible to have a sticky with recommended firmwares?
Theres a sticky here (http://forum.kitz.co.uk/index.php?topic=13930.0) with the Zyxel firmware. Im still using V100AAKL4b2.bin which Im happy with.
Theres a discussion in the Billion 8800NL thread (http://forum.kitz.co.uk/index.php?topic=14030.0) about firmware.. and [I think] les is trying to find which is best - which [i think] is partially what led him to opening this thread.
for lantiq they sync lower kitz even on a ECI dslam.
my fritzbox 3370 is lantiq and it syncs extremely low on interleaving and a bit lower on fast path.
Yes I find the same on my line - the lantiqs arent a patch on the BCM (and most others), but there are still some who swear by the Lantiqs so I was curious how it performed on les-70's line due to him having issues with the bcm 63168 that none of the rest of us appear to have seen.
-
ok thanks. :)
-
I have been testing to see how much I have to reduce the sync of the 8800NL in order to achieve the same error rate as my HG612. I have just considered the ES/hour counts as they are the most stable thing to compare. I found that with the 039 dsl driver firmware I need to use capping to reduce the sync by an extra 8-10Mb/s i.e. ~2db SNRM gain in order to get the same error rate as the HG612. With the 038 dsl driver the needed reduction was less at 6-8Mb/s. I would therefore be cautious of the 63168 devices if your connection speed is error rate limited. e.g. a non-interleaved connection that may go interleaved or DLM banded with much higher errors. To be clear - just cautious - as not all lines seem to suffer from the issues I see my line. In fact my line may or may not be a good test case.
The other finding from this study is that as the SNRM gets bigger e.g. at 9db the difference in performance on my line is less than with the SNRM at 6-7db. e.g.
HG612 ES/hour 8800NL-039 ES/hour
~6 db ~10 ~15
~9 db ~6 ~7
This may mean that some with a high SNR might find that the 6368 chipset is better for errors should their SNRM reduce to 6.
Edit -- Note that all these result are with no interleaving. With interleaving the situation could be quite different and the extra attainable speed of the 63168 chipset might or might not come with an error impact.
-
Interesting observations thanks.
I cant recreate this because I have a larger SNRm and any capping will only further increase it.. but it could explain why I see less errors on the Zyxel?
Ronski's may be another good case to compare. It shows that on his line there is less aggressive bitswap. Interesting that he also sees the evening peaks though when it ramps up similar to when on the HG612. - See the screen caps in his thread here (http://forum.kitz.co.uk/index.php?topic=14343.msg270651#msg270651).
Looking at his graph today, I notice that as predicted he will now see more ES due to the fact that interleaving depth was reduced on the 26th but it still seems to be performing within acceptable parameters. Whilst he is getting more E/S its not bothering the DLM .. plus he's getting a sync increase of 2.5Mbps.
On the whole I'd say Ronski's line seems to be doing quite nicely with the VMG8324 and seems pretty stable.
-
Thanks for pointing out Ronski's case. It is interesting but I would not wish to extrapolate these results on my line to any line with interleaving.
I had interleaving once for about 8 days and it took my prevailing ES rate on the HG612 from ~10/hour to less than 1/hour. I was quite impressed with how effective it was. For comparison the same speed reduction via a sync cap only took me about 5/hour.
I will add a note to the above post reminding that is all on fast path.
-
is the new driver just cheating on snrm? I wonder if its deliberately discounting a db or so to gain an extra bit of sync. Its interesting that capping the speed to the same as the hg612 matches the error rate.
I havent noticed a single issue using my line today, no packet loss, loss of throughput etc. and if DLM didnt exist I would be happy enough, but 6k errors in 30 hours is mouthwatering even for my line. The ES are way below 2880/day still but still is an eye widening number on CRC.
-
All my test always have the same sync speeds for both modems, i am not utilizing the extra attainable in any of the tests. The first speed 72000 gave ~6db with the HG612 but with the 8800NL with 039 shows near 7db. Even though the 8800NL has the extra SNRM, the ES difference of 10 to 15 occurs then. They only seem to become similar error rates with the speed cap at 64000 such that the HG612 snrm is a bit below ~9. I was not so worried about that factor of 1.5 in errors as much bigger change in CRC and SES rates. I noted the CRC and SES values in the 8800NL thread, with a speed such that HG612 is synced close to 6 my 8800NL CRC and SES rates are consistently bigger by x4.
Due to these results I have been fussing over exactly what the DLM might respond to. If it is just ES it is not so bad but if it is CRC and SES it looks more of an issue.
Also as you say the connection has always been OK and the real potential problem, if there is one, may be the DLM.
-
in which case my theory of the less aggressive bitswapping may be playing a part as well then for the error rates.
After some sleep and if I remember will compare bitloading.
Problem is graphs arent working for me at the moment on BE's tool. I think he doesnt like the idea of slowing the app down more, but on my pc the fast pc setting it still is too fast.