Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: snadge on May 30, 2013, 09:56:48 PM
-
is it true that you get more errors using an HG612 on ECI Dslam than using ECI modem? Tom is thinking about getting an HG612 off fleabay so he can view his stats and wotnot :)
cheers
-
Thanks for putting this up snadge im sure i read it here or think broadband
-
Let me whistle up an Eagle (type bald) for you . . . ;)
-
I have studied a few connections to ECI DSLAMS where the originally supplied ECI modem was replaced by a HG612.
In most cases, after a few days, DLM switched on Interleaving at various depths.
Thus sync speeds reduced slightly & many FEC errors were then recorded.
A modem reboot seemed to clear the FEC errors for a while, but they usually returned after a day or so.
Overall performance did reduce slightly, but at least the connection could be monitored.
The first few days (before Interleaving etc. is applied) probably show the connection's true capabilities & in every case, performance returned to previous levels a few days after reinstating the ECI modem.
HTH.
-
Gentlefolk,
I have seen one case on a lousy long line where the Huawei substitute dragged the sync speed down from 7.33 Mbps to around 5 Mbps but upon ECI reinstatement even a month later the speed fails to recover above 5.23.
As I need to proceed with care I haven't been brave enough to experiment on any others that are the worst of our horrors.
Kind regards,
Walter
-
I lose 2Mbps also when using a HG612 modem compared to ECI, current sync 25Mbps with HG612 with ECI 27+.
-
is it true that you get more errors using an HG612 on ECI Dslam than using ECI modem? Tom is thinking about getting an HG612 off fleabay so he can view his stats and wotnot :)
The ECI (3503j) doesn't report comparable error counts, so it's difficult to benchmark the ECI and the Huawei (HG612) side-by-side on that score.
The Huawei reports the full gamut: Reed-Solomon correctables, and the uncorrectables: HECs, CRCs, etc.
Whereas the ECI reports Path Code Violations (CV_P) and CRC_P errors. In the case of CRC_P errors, the ECI reports suspiciously few, and only in the near-end (Upstream) direction, where there are fewer any way.
With an engineered "line fault", and while the ECI /r is synced to a Huawei DSLAM, the DSLAM records many more CRC errors at the CPE than the ECI reports itself.
The challenge is to discover how the two modems could be compared on their error counts.
In terms of line sync rate, it might be said that the ECI has a superior DSL chipset.
However, the SoC in the ECI (edit: a Lantiq VRX268) has a lower clock speed than the Broadcom BCM6368 in the Huawei (333MHz vs 400MHz). This makes the ECI less viable for double-functioning as a router/modem.
But there really isn't a huge margin between the two in terms of sync speed.
cheers, a
-
thanks guys :)
what chipset is in the ECI BTW..?
thanks again 8)
-
Lantiq (http://www.lantiq.com/access-networks/), if I have remembered correctly. :-\
-
I was another user who would see an increase in interleaving when I swapped from the ECI modem to the Huawei one.
However, since I flashed the huawei to the latest firmware (one Asbo made, with a nice new blob in it) I've not had any level of interleaving applied. I've been running it almost 2 months now and I'm keeping an occasional eye on it.
Coincidence? Well I certainly haven't got anywhere near enough equipment (or know how!) to state yes or no. I could have just got lucky this time round I guess. Or it could be a direct result of the new blob. :-\
-
I was another user who would see an increase in interleaving when I swapped from the ECI modem to the Huawei one.
However, since I flashed the huawei to the latest firmware (one Asbo made, with a nice new blob in it) I've not had any level of interleaving applied. I've been running it almost 2 months now and I'm keeping an occasional eye on it.
Coincidence? Well I certainly haven't got anywhere near enough equipment (or know how!) to state yes or no. I could have just got lucky this time round I guess. Or it could be a direct result of the new blob. :-\
Yeah, my cab is also ECI hardware. BT OR installed the HG612 at my place and I was seeing various levels of interleaving in the past, until I somehow managed to freeze DLM with no interleaving through various experimentations. However, I would love to experiment the HG612 with the new blob on the line, but sadly a few attempts a couple of months ago after a line fault was fixed failed to get BT to contact Openreach to get a DLM reset done. Not sure what I can do on that front, probably nothing. Even though the JDSU the engineer showed me said around 90 something megabits attainable, they won't accept that my line can go faster than the speed band of 60 megabits (59995 Kbps sync currently, with attainable of around 90M/27M) due to the estimate saying 58.5Mbps :(.
Other considerations I thought of, but unsure about, were either to contact the moderator team on the BT Business forum, very much like BT residential users do on their own forum, or to move to a different ISP such as Plusnet as it would likely reset by doing that anyway (that is, when my contract ends)?
-
I wonder if the newer ECI modems are less likely to have interleaving/banding applied when coupled with a HG Dslam then a hg modem?
-
is ASBOKID actually making/editing the ADSL driver in these firmwares?
-
Hehe! Way out of my depth, Snadge. There are probably just a few dozen people around the world who understand DSP and DSL enough to do that. Though talking of driver development, John Crispin, the Lantiq maintainer on the OpenWRT project has just re-written the PTM and MEI drivers for the Lantiq platform. So hopefully very soon they will be in 'trunk' [1]
cheers, a
[1] https://dev.openwrt.org/wiki/GetSource
-
Hehe! Way out of my depth, Snadge. There are probably just a few dozen people around the world who understand DSP and DSL enough to do that. Though talking of driver development, John Crispin, the Lantiq maintainer on the OpenWRT project has just re-written the PTM and MEI drivers for the Lantiq platform. So hopefully very soon they will be in 'trunk' [1]
cheers, a
[1] https://dev.openwrt.org/wiki/GetSource
so is it possible that what BIOHEAD (above) is seeing is coincidence? if the DSL driver is still the same then his speeds going back up couldnt be related to a new firmware - am I right in saying that?
cheers
-
Sorry, I got confused. I thought we were talking about the ECI with its Lantiq System-on-Chip.
So far as I know, Biohead has swapped the Broadcom DSL hardware driver or "BLOB" in his Huawei HG612.
The standard HG612 firmware has this driver:
Broadcom DSL Version A2pv6C030b
Built on 01/06/2010 16:31:25
This can be swapped for the latest "35m" BLOB:
Broadcom DSL Version A2pv6C035m
Built on 03/06/2012 17:48:07
Exactly what is different between these two drivers isn't publicly disclosed. Although the driver changelog was published on a Chinese forum but the details were subsequently airbrushed, perhaps at the request of Broadcom.
cheers, a
-
Yep. It could be related to the level of consumption of Shreddies for breakfast. :lol:
See another thread elsewhere! ;);D
-
@ asbo - oh i see, so it was a new firmware edited by you that had a new ADSL driver in it (compared to one he was running)
-
The file system of the firmware was rebuilt with the old BLOB replaced by the newer 35m one. And then it was packaged up with the original Linux kernel into a Broadcom firmware image. Not much to it really. [1]
cheers, a
[1] http://huaweihg612hacking.wordpress.com/2013/03/26/firmware-with-the-newest-hardware-driver-blog/
-
in my opinion the answer is yes however the eci also doesnt seem to hold sync as well as the hg (its less agressive).
I am guessing the error count with the eci based on red specks on tbb graphs, with an eci in the red specs are signficantly lower.
Also when I use a fritz 3370 which has the same chipset as the eci modem the error counts that reports is extremely low compared to the hg and that got me back to a fast path profile very quick.
past issues I had before BT did something to my line where I used to get bursts of errors 1-4am only ever happened on the hg modem.
yes I am on a ECI dslam.
-
in my opinion the answer is yes however the eci also doesnt seem to hold sync as well as the hg (its less agressive).
I am guessing the error count with the eci based on red specks on tbb graphs, with an eci in the red specs are signficantly lower.
Also when I use a fritz 3370 which has the same chipset as the eci modem the error counts that reports is extremely low compared to the hg and that got me back to a fast path profile very quick.
past issues I had before BT did something to my line where I used to get bursts of errors 1-4am only ever happened on the hg modem.
yes I am on a ECI dslam.
I've always wondered if the Fritz!Box 3370 has the same customisability that the 7390 has when it comes to adjusting (offset) 'Target SNRM' or modifying the configuration via console, 'MaxDownstreamRate' and 'MaxUpstreamRate'. I was curious today about another thing so I asked CCLonline store if the 3370 was compatible with BT's FTTC service, they said no, seems they know nothing about it I guess (as you're using it, or did do, without any problem).
-
in my opinion the answer is yes however the eci also doesnt seem to hold sync as well as the hg (its less agressive).
I am guessing the error count with the eci based on red specks on tbb graphs, with an eci in the red specs are signficantly lower.
Also when I use a fritz 3370 which has the same chipset as the eci modem the error counts that reports is extremely low compared to the hg and that got me back to a fast path profile very quick.
past issues I had before BT did something to my line where I used to get bursts of errors 1-4am only ever happened on the hg modem.
yes I am on a ECI dslam.
when you say TBB graph your not on about the ping graph you can set up are ya? - because the red "packet loss" results on those are unreliable (I think anyway), it can show small amounts of packet loss when in fact your not getting any, its just not receiving the return ping which can happen for various reasons... busy router or dropped packet, i get them all the time yet if I do pings (100 pings per second for 30 seconds) I get no packet loss at all... so I don't trust those graphs for packet loss, also when you use your connection those graphs will show as a slow connection (as they should)...especially when downloading.. then Ive seen loads of noobs on forums thinking they have problems with their connection using those graphs as evidence, when infact there is nothing wrong... did you download during those hours>? yes.. well thats why..lol
-
Testing by 'ping' is pretty meaningless and, yes, I agree that those TBB ping graphs are highly misleading. :-X
But that's TBB for you! :P
-
in my opinion the answer is yes however the eci also doesnt seem to hold sync as well as the hg (its less agressive).
I am guessing the error count with the eci based on red specks on tbb graphs, with an eci in the red specs are signficantly lower.
Also when I use a fritz 3370 which has the same chipset as the eci modem the error counts that reports is extremely low compared to the hg and that got me back to a fast path profile very quick.
past issues I had before BT did something to my line where I used to get bursts of errors 1-4am only ever happened on the hg modem.
yes I am on a ECI dslam.
I've always wondered if the Fritz!Box 3370 has the same customisability that the 7390 has when it comes to adjusting (offset) 'Target SNRM' or modifying the configuration via console, 'MaxDownstreamRate' and 'MaxUpstreamRate'. I was curious today about another thing so I asked CCLonline store if the 3370 was compatible with BT's FTTC service, they said no, seems they know nothing about it I guess (as you're using it, or did do, without any problem).
it actually has more, in the GUI there is an extra variable can adjust.
the fritz 7390 uses some unknown chipset that doesnt match either HG or ECI dslams the fritz 3370 uses same chipset as ECI dslams and its a newer gen than the one in the 7390.
-
in my opinion the answer is yes however the eci also doesnt seem to hold sync as well as the hg (its less agressive).
I am guessing the error count with the eci based on red specks on tbb graphs, with an eci in the red specs are signficantly lower.
Also when I use a fritz 3370 which has the same chipset as the eci modem the error counts that reports is extremely low compared to the hg and that got me back to a fast path profile very quick.
past issues I had before BT did something to my line where I used to get bursts of errors 1-4am only ever happened on the hg modem.
yes I am on a ECI dslam.
when you say TBB graph your not on about the ping graph you can set up are ya? - because the red "packet loss" results on those are unreliable (I think anyway), it can show small amounts of packet loss when in fact your not getting any, its just not receiving the return ping which can happen for various reasons... busy router or dropped packet, i get them all the time yet if I do pings (100 pings per second for 30 seconds) I get no packet loss at all... so I don't trust those graphs for packet loss, also when you use your connection those graphs will show as a slow connection (as they should)...especially when downloading.. then Ive seen loads of noobs on forums thinking they have problems with their connection using those graphs as evidence, when infact there is nothing wrong... did you download during those hours>? yes.. well thats why..lol
I wouldnt say they unreliable, I find it a very good diagnostics tool.
a red speck means a momentary small amount of packetloss at that exact moment the data was collected. TCP itself has algorithms to adapt to packet loss conditions so seeing red specks doesnt mean there should be throughput issues.
Its defenitly not some random one off event either, it was very repeatable, HG in more red specks, ECI in less red specks, Fritz 3370 in no red specks. Also when interleaved no matter which device I had no red specks.
-
Testing by 'ping' is pretty meaningless and, yes, I agree that those TBB ping graphs are highly misleading. :-X
But that's TBB for you! :P
thats why network admins do a lot of diagnostics by ping, its most defenitly not useless ;)
I manage 100s of servers and they all have advanced ping monitoring to help diagnose network problems. Pretty much every major DC has some kind of ping monitoring.
-
Then we have a difference of opinion.
-
Then we have a difference of opinion.
the only comment I will make is that obviously the tbb graphs may have issues with packetloss caused by the tbb side or transit/peering issues. eg. it might be wise to treat packetloss shown during peak hours with caution as they could be caused by network congestion, this is dependent on the isp as well of course as some isps are more prone to this than others.
-
Then we have a difference of opinion.
the only comment I will make is that obviously the tbb graphs may have issues with packetloss caused by the tbb side or transit/peering issues. eg. it might be wise to treat packetloss shown during peak hours with caution as they could be caused by network congestion, this is dependent on the isp as well of course as some isps are more prone to this than others.
I may consider buying a 3370 then, was trying to find a screenshot of the mentioned page but unable to find one sadly. Thanks, it's interesting that there's no packet loss at all on TBB graph when using a 3370 on an ECI, if I read your earlier post correctly.
-
Then we have a difference of opinion.
the only comment I will make is that obviously the tbb graphs may have issues with packetloss caused by the tbb side or transit/peering issues. eg. it might be wise to treat packetloss shown during peak hours with caution as they could be caused by network congestion, this is dependent on the isp as well of course as some isps are more prone to this than others.
I may consider buying a 3370 then, was trying to find a screenshot of the mentioned page but unable to find one sadly. Thanks, it's interesting that there's no packet loss at all on TBB graph when using a 3370 on an ECI, if I read your earlier post correctly.
Yes finding info on the 3370 is hard, as it seems most people with a fritz just go for the premium 3790 modem, but the 3370 is newer gen and does have a better dsl chipset.
The 3370 can do all the adjustments the 7390 can however I have yet to find a way to get telnet access, so be warned on that. So the only way to alter values not in the gui is to changed a backed up config file and then upload it.
also since the 3370 ships with new firmware, there is no bridge mode, fritz removed that feature on newer firmwares. Bridge mode is probably still possible but only via manual configuration isntead of a simple tickbox.
I dont actively use the tuning, I just tried it once to settle a tbb argument. I am also currently usign the hg612, I probably would be using the fritz if I got the bridge mode working.
-
Yes finding info on the 3370 is hard, as it seems most people with a fritz just go for the premium 3790 modem, but the 3370 is newer gen and does have a better dsl chipset.
The 3370 can do all the adjustments the 7390 can however I have yet to find a way to get telnet access, so be warned on that. So the only way to alter values not in the gui is to changed a backed up config file and then upload it.
also since the 3370 ships with new firmware, there is no bridge mode, fritz removed that feature on newer firmwares. Bridge mode is probably still possible but only via manual configuration isntead of a simple tickbox.
I dont actively use the tuning, I just tried it once to settle a tbb argument. I am also currently usign the hg612, I probably would be using the fritz if I got the bridge mode working.
I see, well the 7390 is what I had last year, but sold it on as I preferred using the HG612 and also found my 7390 to occasionally 'crash' and reboot itself. I'll have to do some further reading before I consider whether or not to buy one as bridge mode is also important to me. I think I found something about telnet in that you have to flash it from the web interface with a small script that tells telnet to start up. If interested I'll send the link here (if I can find it again that is).
-
@ BKat hmmm I wouldnt say using ping is meaningless :) - as your probably aware, when testing for packet loss over ones local network (home->router->msan->ISP-->host) it can tell you whether or not your ISP is having congestion problems in the exchange or network route they use to that host, if my host (BBC) reports poor results (which it never does) then I would expand the test to other hosts to ensure its my ISP/exchange....for that reason I think its a good tool to use? it gives you an idea of the latency you have, i know connecting to different websites and servers can yield different results but at least it informs you of your 'local' network anyway.
still not convinced about TBB packet loss results.. because they test at 1 ping per second which isnt very rigorous and it ALWAYS says I have small amounts of packet loss... I dont think I have, someone was just asking me about this last week on Sky Forums, concerned their TBB graphed showed packet loss, I asked them to use HRping to some degree and it reported zero packet loss, the graphs are only any good if you do NOT use your connection, because if you do it will show up on the graph, one has to already be knowledgeable enough to know this..otherwise Joe Bloggs goes screaming onto the ISP forum saying they have congestion lol
-
Let me just say that I am not too enamoured by certain persons and certain implementations of utilities at TBB. The TBB ping tester and its graphs are of no significance or real relevance. I don't want to say any more on the subject. :no:
Remember, when a core or an edge or a service router is heavily loaded, it will drop any ICMP Echo Request/Echo Reply packets and just concentrate is its 'proper task'.
[Edited for a spelling error.]
-
Let me just say that I am not too enamoured by certain persons and certain implementations of utilities at TBB. The TBB ping tester and it graphs are of no significance or real relevance. I don't want to say any more on the subject. :no:
Remember, when a core or an edge or a service router is heavily loaded, it will drop any ICMP Echo Request/Echo Reply packets and just concentrate is its 'proper task'.
I agree with you on that - hence me getting packet loss results when I dont have packet loss :)
-
In many years of using tbb, its alerted to me to many problems. If I have a line problem 95% of the time I know about it from looking at the tbb graph.
eg. how did I know I had a line fault from 2-4am when I am asleep, I see say 300k CRC errors for the day in the modem, but how do I know the time? the big red splodge on the tbb graph is how.
snadge if the graph shows packet loss then you getting packet loss. but you also have to know how to use this kind of data, and understand that its measuring your connection between tbb and yourself. Having a 2nd graph hosted elsewhere such as http://fruk.net/index.php?fruk=f8lure can be useful to collaborate results.
Occasionally things can go wrong. eg. occasionally I have seen packetloss show on all tbb graphs for a given isp due to a congested peering link, but when that happens its a case of simply discarding that set of data.
To say tbb graphs are near enough useless is a very strong statement to make which I disagree with.
-
eg. how did I know I had a line fault from 2-4am when I am asleep, I see say 300k CRC errors for the day in the modem, but how do I know the time? the big red splodge on the tbb graph is how.
You could (possibly do) use either of Bald_Eagle_1's or Roseway's excellent tools, either of which will give you far more useful information. :) They won't tell you about other causes of packet loss out there in the network, but from your example above, you seem to be diagnosing line errors from noting the delays caused by packet retransmission or loss.
Each to their own :), but I would bet most people would need to have a perfect (near error-free) line first, before nneding to look out to the network for other causes - which do of course exist, including ISP's dropping packets because of congestion.
-
eg. how did I know I had a line fault from 2-4am when I am asleep, I see say 300k CRC errors for the day in the modem, but how do I know the time? the big red splodge on the tbb graph is how.
You could (possibly do) use either of Bald_Eagle_1's or Roseway's excellent tools, either of which will give you far more useful information. :) They won't tell you about other causes of packet loss out there in the network, but from your example above, you seem to be diagnosing line errors from noting the delays caused by packet retransmission or loss.
Each to their own :), but I would bet most people would need to have a perfect (near error-free) line first, before nneding to look out to the network for other causes - which do of course exist, including ISP's dropping packets because of congestion.
yes I do run those tools and that also would have confirmed and it probably did.
But regardless it shows tbb graphs (or any other 3rd party graphs) are not useless. Remote ping monitoring is a big thing in the industry, noone said its perfect but its widely used as its useful..
there is also several tools made for diagnostic purposes that are based on pinging such as mtr and pathping.
-
But regardless it shows tbb graphs (or any other 3rd party graphs) are not useless. Remote ping monitoring is a big thing in the industry, noone said its perfect but its widely used as its useful..
Very few things are fully useless, but all a ping test tells you at best is that there may be some sort of issue to investigate. The fact that everybody 'does it' - a big thing in the industry - does not necessarily mean that it's as useful as people believe, it's just what 'everybody' does. Some people 'in the industry' believe that Windows 8 is a good thing too. ;D Nobody's saying you shouldn't use it - some of us just don't think it's as good a diagnostic tool as you do. As I said, though, each to their own. :friends:
-
well yeah, the hg612 plotter also requires a pc to be on running it, initially I wasnt running it. whilst remote ping graphs tend to only need the router on. there is pros and cons, but I just wanted to counter the argument that its useless.
a ping plotter isnt designed to give a full diagnosis, but I have found it useful for evaluating line error rate performance on both adsl and vdsl.