Kitz Forum
Broadband Related => Broadband Hardware => Topic started by: Blackeagle on April 02, 2014, 09:56:26 AM
-
Having obtained an adaptor to unlock these, I dug one out of the cupboard where it has lain unused for the best part of two years, and within ten minutes it was unlocked. As BT originally fitted one of these, I know it's meant to match the DSLAM and therefore I was curious to know whether any improvement would be seen on my line. As regular kitizens may remember, my line from the DP to the CAB is 100% Aluminium :( Errors abound, and it won't support much above the 40/2 its currently running at.
Anyway, the modem was duly installed, along with a Tenda 5 port switch (which was extremely badly received !) to allow access when online (Thanks custard for pointing that out). Stats were grabbed using eDMT as I was disappointed to find most of the ECI's stats page was not filled out. Initial readings appeared very similar to the HG612, although sync speed was slightly less.
Further testing indicated that the ECI was not susceptible to a sudden SNRM drop when turning on my plasma TV. The HG612 loses at least 0.5dB when it's turned on and this does not return until the set is switched off. Both modems were located in the same place, powered from the same socket and used the same xDSL cable from the frontplate. The test was carried out several times to ensure accurate results.
All however, was not rosy in the eyrie. During a subsequent attempt to refresh the HTML page of the modem, it became apparent that connectivity had been lost. A telnet session was established, which connected OK, but attempts to send a command via the pipe failed, with no return of the Alpha # prompt. Terminating the session proved to be the only way out. Rebooting would have cured this, however it was decided to leave things as they were as net connectivity was fine.
Sometime during the night (as I found upon rising), internet connectivity had been lost. Little LED's indicated a session was established, but no DNS resolution was possible and pings to google's DNS servers failed. The HG533 was rebooted as this acts as the gateway, and although reliable, has been known to fall over once or twice in the past. Didn't help :no:
At this point I should have checked the switch, but instead I rebooted the ECI. When this didn't restore connectivity, I rebooted the switch, which did !!
This morning I awake to the same situation of no connectivity. The wife was incandescent !!!! She listens to the radio online via XBMC as VHF and DAB reception here can be rather poor at times. As she cannot listen to her favourite breakfast show, I get an ear bashing !!
This time I reboot both the HG533 and the Tenda switch but to no avail. Http connectivity to the ECI does not work, and telnet produces similar results of logging in but 'piped' commands failing.
The result of this is that the HG612 is once again responsible for connectivity. Looking at the stats, I can see that in the two days the ECI was online, interleaving has fallen from 1380 to 849, SNRM is around 1dB better for downstream, at ~7.2dB, although I put this down to syncing at around 8.30am.
The ECI, for me at any rate, just seems to be too 'flaky', falling over at the slightest opportunity. Of course, it may just be that the modem has a slight fault and as I'm not quite yet prepared to give up, I have another one that can be unlocked and pressed into service to see if it is any better behaved. Two days of dodgy connectivity did not give me a chance to formulate an accurate opinion of which router may perform better and I would like to be able to leave the ECI online for at least a week. Sadly, this particular router won't be online anytime soon.
(Blackeagle apologises for the length and rambling nature of this post!! It is somewhat longer than I originally intended :-[)
-
Interesting read.
>> I can see that in the two days the ECI was online, interleaving has fallen from 1380 to 849,
Which implies the DLM thinks your line is more stable with the ECI, despite the losses in connectivity.
Out of interest, did you happen to notice the amount of errors generated whilst using the ECI modem? Just wondering if the fact that the Huawei's SNRm dips whilst the TV is on if this is causing an increase in errors.... and in due course how the DLM would react to any errors.
I notice you say you have another ECI to try, so it would be interesting to see how that performs too and/or if it was just that eci that was flaky :/
-
DLM seems stable, even with the high error counts I get. Over a 31 day period, my line stats didn't alter at all, so DLM doesn't seem to be reacting to them. I am currently unsure whether DLM brought down the interleaving with the ECI connected, or whether it was the 8.30am sync :-\ Further testing is definitely needed, although it's unlikely to be this week.
I have already unlocked the second ECI (and marked the case) so as to be able to test with it.
You can see clearly in the attached grab the TV being on, then turned off, then on again for about 5 minutes. If it turns out that the ECI does not exhibit this behaviour, then if I can get it to stay connected reliably, it'll probably stay.
I would need to do something about the graphing though. eDMT is OK but I've got so used to dslstats now :)
-
I've found that telnet has a tendancy to become unresponsive to some commands with both the ECI/I and ECI/r. Eventually I could not login which was only fixed via a reboot or serial access to restart telnet.
I had been using the ECI/r recently when this happened so I opened up the lid while still been connected to internet and was able to send the a telnet restart command.
In the ECI/r thread Asbokid talks about disabling BTagent to stop the freezing.
Otherwise wires may need to be permanently connected to UART and tunnelled out the case until a simpler solution is found.
I had an increased sync of 2.5mb with both ECI's over the HG612.
Unfortunately I have damaged my ECI/r and have reverted back to the hg612 for now.
-
Yes, I did see the reference to killing the btAgent stuff. I tried that after the first reboot, in the hopes that it would help but sadly, it didn't. I'm not thrilled at the thought of having to leave it serially linked all the time, but I guess it's an option. When I lost http access, but still had telnet, I tried killing the httpd daemon and restarting it, but it didn't help.
Perhaps the flakiness of connectivity is a reason for BT to lock down the router? Certainly, I'm not full of confidence with it now!!
Perhaps I will run it offline for a bit, see if there is a pattern to locking it up.
-
Perhaps the flakiness of connectivity is a reason for BT to lock down the router? Certainly, I'm not full of confidence with it now!!
In all honesty, I think it was nothing more than a means to disable any "fiddling", thus providing a consistent CPE functionality across the entire installed end-user base which, in turn, would allow statistics to be remotely harvested allowing the (then) new product to be analysed "across the board".
Perhaps I will run it offline for a bit, see if there is a pattern to locking it up.
That would be a good experiment as, whatever your findings may be, the result will add to the knowledge base for the device.
-
I've now run the ECI/i for around 48hrs offline. During this time, a simple script has been running to grab each of the modem's http pages every 10 seconds. This has not produced any loss in connectivity with the ECI and both telnet and http access are available.
The vast majority of this test has been with the m/board out of the case. I can't shake the suspicion that heat may be involved , therefore the board has been replaced into the case, and the test continues !!
I would have suspected the other unit to be faulty, were it not for other kitizens mentioning similar loss of connectivity. To further prove/disprove this theory, the same tests will be conducted with the modem online in both its standard state and with some form of cooling (yet to be fully devised ::)) in place.
-
Cooling devised !!!!
A 55mm 12Vdc 4000RPM fan has been mounted, with the aid of blu-tack above the Lantiq SoC, and wired directly to the incoming 12Vdc. No current issues as the fan is rated 0.15A and the router 1.25A. The PSU currently connected can supply upwards of 5A :)
A slight modification had to be made to the lid as there is a plastic peg which was fouling on the fan. This was removed. A VDSL2 outage is scheduled in the eyrie for around 9AM tomorrow for a changeover of modem.
If the ECI/i shows the same line improvements as the last one, and the cooling proves effective in providing stable access, then it will likely remain. Time will tell !!
-
Blackeagle - I've now connected to the ECI/I semi permanently via UART.
I'm finding I can knock out the telnet on demand by overloading it with multiple commands. I am then able to restart telnet via the serial but this seems to then knockout the serial connection. :no:
So if I then overload telnet again I have lost both serial and telnet which can only be regained via a reboot...
-
Blackeagle - I've now connected to the ECI/I semi permanently via UART.
I'm finding I can knock out the telnet on demand by overloading it with multiple commands. I am then able to restart telnet via the serial but this seems to then knockout the serial connection. :no:
So if I then overload telnet again I have lost both serial and telnet which can only be regained via a reboot...
Hmmm, yeah. I think this could be due to limited memory. I doubt there is much error checking going on and I think it would be easy to overflow a buffer or stack by sending commands too fast.
My ECI has now been in circuit for 24 hrs. Currently I have both http and telnet access.
I'm working on some software to get stats off it in near real time, much like DSLstats etc. Currently it's collecting stats every 10 seconds although I have had to write a bit of error handling, as the ECI has a habit of returning spurious data occasionally (or maybe its my code ???).
Currently it's only grabbing downstream stats, but it is only a matter of setting a flag to get the upstream details. I also need to add graphing as its only updating text labels at the moment but that shouldn't be too difficult.
Currently its Windoze only :o I know, I know, but it's much easier to design a nice, polished UI in Redmond based software than it is in Linux. It should run under Wine anyway but I haven't tested that yet.
It's probably not going to be as polished as Eric's offering, but I doubt DSLstats will ever support the ECI. eDMT is fine, but it's only a snapshot, and you have to OK numerous pop up windows each time you refresh the data. I wanted something that could graph in realtime, hence this attempt.
Initial findings vs the HG612 indicate that the ECI consistently reports DS figures for band 2, although at a line attenuation 0f ~73dB the band is not in use. The 612 however, reports no figures for this band. Of course it's firmware could be written to ignore unused bands completely, but it's still nice to have a figure.
Sync is very slightly down. 39992 vs 39997, but interleaving is (I think) slightly lower.
Compared to the first ECI/i that I tried, this one has proved so far to be more stable. :)
-
You should be able to check your interleaving level on the webpage or via the telnet commands
Alpha # echo "g997csg 0 0" > /tmp/pipe/dsl_cpe0_cmd
Alpha # cat /tmp/pipe/dsl_cpe0_ack
nReturn=0 nChannel=0 nDirection=0 ActualDataRate=19992000 PreviousDataRate=20000000 ActualInterleaveDelay=950 ActualImpulseNoiseProtection=26
Alpha # echo "g997csg 0 1" > /tmp/pipe/dsl_cpe0_cmd
Alpha # cat /tmp/pipe/dsl_cpe0_ack
nReturn=0 nChannel=0 nDirection=1 ActualDataRate=59504000 PreviousDataRate=67212000 ActualInterleaveDelay=975 ActualImpulseNoiseProtection=30
I've had interleaving switched on last night after multiple reboots while testing yesterday.
I also found on one occasion when a piped command failed that I lost webpage access. I was able to regain this by simply killing the pid associated with the piped command.
It would be great if you could develop a program. :thumbs:
-
my telnet also dies on the unlocked ECI I have, at the time asboguy was around but he couldnt repeat it so was no fix suggested.
I also had processes chewing up 100% cpu on my ECI as well. So the modem didnt seem too healthy, although I believe it did lower error rates on my line.
A way to get a modem with the same chipset as the ECI is get a fritzbox 3370, but sadly they removed the bridge mode function (was in very early firmwares). Bridge mode can be done via telnet but getting into telnet on the 3370 is tough due to it usually been done on the voip ports that exist on the 7390. Not to mention the fritz 3370 is very expensive for what it is.
-
You should be able to check your interleaving level on the webpage or via the telnet commands
It would be great if you could develop a program. :thumbs:
Yeah, I know what my interleaving currently is, in fact my monitor reports it. What I meant was I'm not sure how the ms value the ECI reports equates with the value reported by a Broadcom chipset, as it reports an interleave depth. If the values equate directly (i.e. the Broadcom chipset reports a millisecond value) then its definitely lower.
Currently, all the data I'm grabbing is downstream only, but adding Upstream isn't difficult. I can just add a flag to the code and pass it into each data gathering routine.
I've noticed (and wonder if you could confirm this), that the max attainable rate doesn't appear to change, either from the telnet info, or the webpage.
Currently, I've only written code to graph SNRM, but I think it's relatively easy to graph the static stuff like QLN so that will be added last. I'm also not graphing the band plan SNRM's, just the average although I guess I could add it as an option as I'm getting the data anyway.
Occasionally, the ECI sends bad data. This is currently handled by just reporting the issue in the status bar - it doesn't stop the sampling.
Planned graphs are :-
- SNRM - Already working for D/S
- Speed - Everyone graphs this!! Easy to add.
- Bitloading - Bit(sic) of work to do here to parse the output.
- CRC errors - Need to figure out how to get them !!
- FEC errors - Same as above
- QLN - Know how to get this, just need to write some code as a one shot deal
- Gain - Know how to get this too - does this change with time ?
Feel free to suggest other stats to graph. Gonna try and work a bit on this over the weekend.
Will post a screenshot when I get the chance ;)
-
I don't think I've seen the max attainable change in real time but i'll keep an eye on it to confirm.
Try this for interleave depth
Alpha # echo " g997fpsg 0 0" > /tmp/pipe/dsl_cpe0_cmd
Alpha # cat /tmp/pipe/dsl_cpe0_ack
nReturn=0 nChannel=0 nDirection=0 nNFEC=96 nRFEC=16 nLSYMB=6072 nINTLVDEPTH=253 nINTLVBLOCK=96 nLPATH=0
Alpha # echo " g997fpsg 0 1" > /tmp/pipe/dsl_cpe0_cmd
Alpha # cat /tmp/pipe/dsl_cpe0_ack
nReturn=0 nChannel=0 nDirection=1 nNFEC=85 nRFEC=16 nLSYMB=18342 nINTLVDEPTH=863 nINTLVBLOCK=85 nLPATH=0
Do you want 15min stats for CRC/FEC? otherwise there is daily, showtime or total?
I suppose you could add in ES aswell...
That program looks to be coming on great!!
-
Will need to compare your averages with DSLSTATS and HG612_Modem stats and you may need some Beta testers to hand the best ones already have a spanner in there hands ready to poke it. :D
-
Cheers Custard, wasn't aware of that particular command !!
Must have had a re-sync during the night, judging from the stats :( That never happened with the HG612 :no: I could probably get the stats better by triggering a re-connect, but I'm not going to just yet.
Added some code to the monitor to graph upstream SNRm and added a legend to the top right. In case anyone was wondering, the number in the status bar next to the router address is just a counter that ticks seconds. It's there purely so I know the program hasn't crashed and won't be in any releases.
Next bit to write I think will be the static graphs. I'll give that a shot today.
Beta testers will be most welcome, once I get to a stage where I can release something. There is a bit of a way to go yet !!
***** EDIT *****
Got the bitloading working. The ECI doesn't seem to want to return the Hlog data though :no:
-
I've got your codes for the fec/crc/es for 24hrs. If you need they can be changed to 15mins or showtime if you want.
Alpha # echo " pmdpc1dg 0 0 0" > /tmp/pipe/dsl_cpe0_cmd
e/dsl_cpe0_aAlpha # cat /tmp/pipe/dsl_cpe0_ack
nReturn=0 nChannel=0 nDirection=0 nHistoryInterval=0 nElapsedTime=45247 bValid=1
nHEC=0 nTotalCells=0 nUserTotalCells=0 nIBE=0 nTxUserTotalCells=0 nTxIBE=0 nCRC
_P=0 nCRCP_P=0 nCV_P=0 nCVP_P=0
Alpha # echo " pmdpc1dg 0 1 0" > /tmp/pipe/dsl_cpe0_cmd
Alpha # cat /tmp/pipe/dsl_cpe0_ack
nReturn=0 nChannel=0 nDirection=1 nHistoryInterval=0 nElapsedTime=45360 bValid=1
nHEC=0 nTotalCells=0 nUserTotalCells=0 nIBE=0 nTxUserTotalCells=0 nTxIBE=0 nCRC
_P=0 nCRCP_P=0 nCV_P=0 nCVP_P=0
Alpha # echo " pmcc1dg 0 0 0" > /tmp/pipe/dsl_cpe0_cmd
ackAlpha # cat /tmp/pipe/dsl_cpe0_ack
nReturn=0 nChannel=0 nDirection=0 nHistoryInterval=0 nElapsedTime=56619 bValid=1
nCodeViolations=0 nFEC=4294967277
Alpha # echo " pmcc1dg 0 1 0" > /tmp/pipe/dsl_cpe0_cmd
Alpha # cat /tmp/pipe/dsl_cpe0_ack
nReturn=0 nChannel=0 nDirection=1 nHistoryInterval=0 nElapsedTime=56656 bValid=1
nCodeViolations=0 nFEC=116
Alpha # echo " pmlsc1dg 0 0 " > /tmp/pipe/dsl_cpe0_cmd
Alpha # cat /tmp/pipe/dsl_cpe0_ack
nReturn=0 nDirection=0 nHistoryInterval=0 nElapsedTime=57624 bValid=1 nES=0 nSES
=0 nLOSS=0 nUAS=33 nLOFS=0
Alpha # echo " pmlsc1dg 1 0 " > /tmp/pipe/dsl_cpe0_cmd
Alpha # cat /tmp/pipe/dsl_cpe0_ack
nReturn=0 nDirection=1 nHistoryInterval=0 nElapsedTime=57655 bValid=1 nES=0 nSES
=0 nLOSS=0 nUAS=33 nLOFS=0
On the point you raised about detecting when your resync occurred:
I have been using the ECI in bridge mode but recently changed it over to dynamic IP to see if it would still connect. After a few minutes it did still connect with the router staying in bridge mode.
With the ECI in bridge mode I was finding the log on the webpage was not been populated past "system started" but now I have the log showing when a resync occurred although the times are not right.
Dec 31 16:01:54 , DHCP: Client receive ACK from 10.160.170.229,IP=30.114.98.126,Lease time=2419200.
Dec 31 16:01:52 , DHCP: Client send REQUEST to server 10.160.170.229request IP=30.114.98.126.
Dec 31 16:01:52 , DHCP: Client receive OFFER from 10.160.170.229.
Dec 31 16:01:52 , DHCP: Client send DISCOVER.
Dec 31 16:01:20 , DHCP: Client send DISCOVER.
Dec 31 16:01:04 , DHCP: Client send DISCOVER.
Dec 31 16:00:56 , DHCP: Client send DISCOVER.
Dec 31 16:00:52 , DHCP: Client send DISCOVER.
*************** , System started.
Alternatively you could send one of the telnet codes for showtime which would provide the number of seconds since the last resync.
With regards to the graphs you are producing you may need to reverse tx power for upstream and downstream.
Lastly earlier in the thread you commented on the piped commands not working sometimes. I've found I can fix this on occasions by killing the pid for last "cat pipe" command in the same way as when webpage access is lost.
Keep up the good work!!
-
I'll bear in mind the reversal of Tx & Rx power.
Graphing the errors is gonna be fun I think - not exactly sure how that's going to turn out, but we shall see.
I have had zero luck in getting the modem to return any data for the delta stuff. It just doesn't want to return Hlin, Hlog,or QLN which is a shame as I'd have really liked those graphs :(
My webpage log isn't empty, theres 5 pages of stuff in there. As you noted, the time and date are wrong so I presume that the ECI doesn't contact an NTP server. Possibly I'll look into this at some point. I'll have a better idea of times of re-sync's (if I get any more) when I've added the speed graphing. I'm already retrieving the value's so adding the graph is pretty trivial. Most likely it'll be done by tonight :)
On the subject of graphs, because I've used zedgraph to handle the drawing, you get some nice features as standard. The graphs are all 'zoomable' with a scroll wheel, and right clicking brings up a menu where you can reset the zoom, save the graph and turn on 'show point data'. The latter shows the values as you mouse over the graph, so for instance, I zoomed in the bitloading graph, and can tell you that the first tone loaded is tone 10 and its loaded with 2 bits.
I attach a snapshot of the graph zoomed in.
Regarding 'stuck commands'. Fortunately, the monitor hasn't really had this issue. Occasionally it will pop up a status message of 'bad data returned' but this is more to do with timing than anything. Trying to read from the modem before the command has finished completing. Getting the bitloading puzzled me a bit at first as it just wouldn't get the downstream data. I thought at first the command wasn't working correctly, or I had parsed the data wrongly, but it was actually that I hadn't made the read buffer large enough. :-[
Unless you have more success than me with getting QLN & Hlog to work, then we won't be getting those graphs :no:
-
Graphing the errors is gonna be fun I think - not exactly sure how that's going to turn out, but we shall see.
I thought there might be some difficulty with these. Maybe you will need to set it up to pull data at 15min intervals for them. You can always use the previous 15mins (history interval =1) so that you get the full interval stats.
I have had zero luck in getting the modem to return any data for the delta stuff. It just doesn't want to return Hlin, Hlog,or QLN which is a shame as I'd have really liked those graphs :(
Unless you have more success than me with getting QLN & Hlog to work, then we won't be getting those graphs :no:
I seemed to recall having an output of these commands a while ago. After searching my computer I realised the codes worked on the ECI/r not the ECI/I.
I've had a go with testing them again and unfortunately I can only report the same results as yourself. :(
Actually on that point I have another ECI/r being delivered to me next week so I was hoping you could still add in QLN and Hlog for use on it. :fingers:
-
As long as the command is the same, and the data returned is in the same format as the bitloading data, then yes, I can write the code to do the graphs. I won't be able to test it though obviously but as long as the format returned is the same, my guess is it should work.
I could add an option, either a check box on the main screen, or a drop down options menu to select either the ECI/I or the /R so as not to set up graphs that one version can't use.
Looking at my code, a lot of stuff is repeated e.g. send a command, read the response, parse the response. This is bad programming as it could all be handled by one routine so a major re-write is in the offing !! The re-write though will be a side-by-side development. Code will be added to the current program (as it works pretty well) and then ported to the re-write. This will make my development branch pretty untidy and probably quite large, but the release version should be much more compact and more stable because of this. I've also figured out a better way of parsing the returned data that should work regardless of whether the read buffer contains 'command, data, command prompt' or 'data, command prompt' (which occurs quite a lot !! Grrrr )
If you can post attachments containing the results of QLN & Hlog from the /r then I can use that to make sure the code works. I'll just grab the data from the file rather than the ECI whilst testing.
Downstream speed is now being graphed. I'm not too bothered personally about upstream as mine is capped at 2M, but i'll include it at some point as I know various people have had upstream issues.
Because bitloading changes over time, I'm going to change the code to pull the data each sample cycle instead of just snapshot it at the beginning.
Thought - I can get 'gain' easily enough and graph it. Does this also change over time or is it like Hlog, QLN and a one time deal ? - Perhaps I'll graph it anyways to find out !!
On the subject of 'sample cycles', it's currently hard-coded at 15 secs. I reckon it could go lower to around 10s maybe even 5. The problem here is that there needs to be a delay between sending a command (eg cat /var/tmp/pipe/tell_me) and reading the result. Currently i'm delaying by 1/4sec but thats probably far too long and 20ms is likely enough. If I can get it that low, with no loss of stability, then I can make some options for the sample time. Thats in the future though.
-
I've attached the output for QLN. It may need some work to get the figures into graphs!!
I don't have anything for Hlog. Hopefully someone else can post this using:
echo "g997dhlogg 1 1" > /tmp/pipe/dsl_cpe0_cmd
cat /tmp/pipe/dsl_cpe0_ackOtherwise i'll get onto it once I have unlocked the eci/r.
You asked whether I noticed any variation in max attainable. The web GUI show that upstream is changing in real-time.
-
I've attached the output for QLN. It may need some work to get the figures into graphs!!
You asked whether I noticed any variation in max attainable. The web GUI show that upstream is changing in real-time.
Its not too bad actually to get that data into a graph. The formatting is the same as the bitloading data, except the bitloading data is hex and the QLN is decimal. Those errors though, were they returned by the ECI? If yes, is it consistent ?
Regarding Max Attainable .......... Err, it not changing at all in the program was an elementary error on my part :-[ I only realised after I added code to graph the downstream speed. At first the graph showed nothing, owing to me not calling that routine on each pass. That's now fixed.
Might not get much written today, as a large bottle of white is calling to me !!!
-
You should be able to check your interleaving level on the webpage or via the telnet commands
Alpha # echo "g997csg 0 0" > /tmp/pipe/dsl_cpe0_cmd
Alpha # cat /tmp/pipe/dsl_cpe0_ack
nReturn=0 nChannel=0 nDirection=0 ActualDataRate=19992000 PreviousDataRate=20000000 ActualInterleaveDelay=950 ActualImpulseNoiseProtection=26
Alpha # echo "g997csg 0 1" > /tmp/pipe/dsl_cpe0_cmd
Alpha # cat /tmp/pipe/dsl_cpe0_ack
nReturn=0 nChannel=0 nDirection=1 ActualDataRate=59504000 PreviousDataRate=67212000 ActualInterleaveDelay=975 ActualImpulseNoiseProtection=30
I've had interleaving switched on last night after multiple reboots while testing yesterday.
Early this morning after 24hrs on interleaving DLM has switched me back to fastpath. The sync is about 2.5mb higher than the hg612.
Alpha # echo "g997csg 0 0" > /tmp/pipe/dsl_cpe0_cmd ; cat /tmp/pipe/dsl_cpe0_ack ; echo "g997csg 0 1" > /tmp/pipe/dsl_cpe0_cmd ; cat /tmp/pipe/dsl_cpe0_ack
nReturn=0 nChannel=0 nDirection=0 ActualDataRate=20000000 PreviousDataRate=19992000 ActualInterleaveDelay=0 ActualImpulseNoiseProtection=0
nReturn=0 nChannel=0 nDirection=1 ActualDataRate=68292000 PreviousDataRate=59280000 ActualInterleaveDelay=0 ActualImpulseNoiseProtection=0
-
Its not too bad actually to get that data into a graph. The formatting is the same as the bitloading data, except the bitloading data is hex and the QLN is decimal. Those errors though, were they returned by the ECI? If yes, is it consistent ?
I only have one output so I'm not sure about the errors, but I've just had a look in the eci/r thread and Asbokid had the QLN and Hlog data using a different command and I don't see any syntax errors. Actually he posted some useful info on how to calculate the actual numbers aswell.
http://forum.kitz.co.uk/index.php?topic=11818.75
http://forum.kitz.co.uk/index.php?topic=11818.90
Reading through the thread again I've also noticed how to place multiple commands on one line so I don't have to send multiple calls and risk losing telnet. :graduate:
Enjoy your poison!!
-
OK, can't just plot the data returned 'as is' but that's not gonna be a problem. Asbokid was using a shell script there to send the command. Is this a standard thing on the /R or is it a quick script he knocked up ?
I've already added a 'check box' for the R model to my program. If the shell script is standard on that model, then based on that check box being ticked or not, I can format the telnet command accordingly, and miss out the 'cat' part. I also noticed btagent_arc_version getstat. That could come in useful!!
-
I'm pretty sure that that commands we are sending out to the ECI/I will work on the the ECI/r so you may not need to change them.
I think the shell script used by Asbokid was always there in the ECI/r - http://forum.kitz.co.uk/index.php?topic=11818.msg231616#msg231616.
-
That script also exists on the /i, just in a different location.
Took the data that you supplied for QLN and came up with the graph attached. Does that look about right ? I still have to write the routine to actually get the data, but it's virtually the same as bitloading.
Have altered the graphing slightly so that it scrolls a bit better. I'm still unsure exactly how I'm going to approach graphing the errors, but I'll have a bash at it probably tomorrow now. Might just have to end up grabbing a sample every 15 minutes although I don't feel thats necessarily the way to go. Hmmm..........
-
I tried searching for an equivalent script in the ECI/I but could not find it. Would you mind elaborating on where this can be found? The ls tmp/pipe does not show it for me. Are you able to extract QLN/Hlog from there?
The graph looks right from the data given. It looks like nothing is being reported for upstream frequencies and it also reports less information than the HG612. I've attached my QLN from the hg612 for comparison.
You may consider multiplying the tone number by 8 to bring it in line with the other stats programs rather than reporting tone bands. Alternatively you could report it as actual frequencies with spacing of [4.3125KHz x 8].
When I receive my ECI/r i'll see if I can locate the upstream values.
With regards to the error graphs I don't think they will be accurate on the ECI/I as I keep on seeing the odd very large values every now and then. Is this the same for you?
If you don't want to go for the 15min intervals then the other option I have thought about would be to pull the current 15min values and divide that by the elapsed seconds to give you a per second value (or you could have a per min value). This way it does not matter if the data is pulled more frequently than 15 mins.
Hopefully the producers of the other stats programs will see this thread and provide some pointers on how they set up the error graphs.
-
The script lives in a different place, but is present. The directory is /ifx/vdsl2, so ...
Alpha # ls /ifx/vdsl2
xdslrc.sh ifx_mei_cpe_drv_init.sh drv_ifxos.ko
xcpe_hw.bin ifx_load_ifxos_drv.sh drv_dsl_cpe_api.ko
vdsl.scr ifx_load_dsl_cpe_api.sh bringup_vdsl.sh
inst_drv_cpe_api.sh ifx_cpe_control_init.sh S19setext.sh
inst_driver.sh dsl_cpe_pipe.sh S19setext.ori
Alpha #
If you change to that directory (cd /ifx/vdsl2) you can see what each script does with cat <name of script>. So for example
Alpha # cd /ifx/vdsl2
Alpha # cat dsl_cpe_pipe.sh
#!/bin/sh
pipe_no=0
# use specified pipe no
case "$1" in
0|1|2)
pipe_no=$1; shift; ;;
esac
#echo "Call dsl_pipe with $*"
##echo $* > /tmp/pipe/dsl_cpe${pipe_no}_cmd
##result=`cat /tmp/pipe/dsl_cpe${pipe_no}_ack`
echo "$*" > /tmp/pipe/dsl_cpe0_cmd
result=`cat /tmp/pipe/dsl_cpe0_ack`
echo "$result"
Alpha # cat ifx_cpe_control_init.sh
#!/bin/sh /etc/rc.common
# Copyright (C) 2010 OpenWrt.org
bindir=/ifx/vdsl2
fwdir=/ifx/vdsl2
initdir=/ifx/vdsl2
AUTOBOOT_ADSL=""
AUTOBOOT_VDSL=""
NOTIFICATION_SCRIPT=""
FW_XDSL=""
FW_FOUND=0
START_API=1
if [ -e ${bindir}/adsl.scr ]; then
AUTOBOOT_ADSL="-a ${bindir}/adsl.scr"
fi
if [ -e ${bindir}/vdsl.scr ]; then
AUTOBOOT_VDSL="-A ${bindir}/vdsl.scr"
fi
if [ -e ${initdir}/xdslrc.sh ]; then
NOTIFICATION_SCRIPT="-n ${initdir}/xdslrc.sh"
fi
if [ -e ${fwdir}/xcpe_hw.bin ]; then
FW_XDSL="-f ${fwdir}/xcpe_hw.bin"
FW_FOUND=1
fi
##########################################################################
# start dsl cpe control application with appropriate options
if [ ${FW_FOUND} = 0 -o ${START_API} = 0]; then
echo "ERROR: No firmware binary avaialable within '${fwdir}'"
echo "or API start blocked manually."
echo "NO API started!!!"
else
/usr/sbin/dsl_cpe_control -i ${FW_XDSL} ${AUTOBOOT_VDSL} ${AUTOBOOT_ADSL} ${NOTIFICATION_SCRIPT} -t &
PS=`ps`
echo $PS | grep -q dsl_cpe_control && {
# workaround for nfs: allow write to pipes for non-root
while [ ! -e /tmp/pipe/dsl_cpe1_ack ] ; do sleep 1; done
chmod a+w /tmp/pipe/dsl_*
}
echo $PS | grep -q dsl_cpe_control || {
echo "Start of dsl_cpe_control failed!!!"
false
}
fi
Alpha #
Note the OpenWrt ref in the second script!!
Regarding the QLN tones. Multiplying to get the tone number is easy enough. Is the HG612 also returning an average for 8 tones ? Actually, thinking about it, you could have the graph displayed either way. I could easily put in an option for that. In fact, as things develop, I'm getting an increasing need for a 'settings screen'. I've already got some logging of what the program is doing, going to a disk file. Option to turn that on or off would be good. I could log the actual data too, as currently, when the graphs of SNR and speed scroll, the data is simply dropped.
Error values. Yeah I get stupidly high values that disappear quite quickly, in both U/S and D/S. My initial thinking on this is that its similar to some netgear routers, where passing the GUI a negative number produces a stupidly high result. I'll start getting some error stats today and just see what happens. If telnet returns the same odd values, I could at least check for that, and skip apparent "bad" values.
***Edited to add updated QLN graph ***
*** Edited again to add Gain Graph ***
Note Gain does change in real time, and that graph is showing gain in a downstream band I'm not currently able to use.
-
Good find on the script!
So the data can be called using a single command similar to the eci/r although that route still does not provide QLN/Hlog data.
Thanks for letting me know how to inspect the scripts.
Looking at my plink log part of which is attached, it seems that the Hg612 reports individual tones for downstream and 8 tone averages for upstream. Hlog is 8 tone averages.
My telnet data is showing the abnormally high error rates aswell.
I'm still waiting for the eci/r to turn up...
-
My ECI/r turned up yesterday. I soldered up and synced in just after midnight. To my surprise the sync has jumped up another 3mb. This is better than I have ever seen on my line even with my old ECI/r.
QLN, Hlog and btagent_arc_version getstat are attached.
The getstat command reports there are 2 sets of data for QLN but I still cannot locate upstream.
-
Thanks Custard, that's very useful.
Hopefully I'll have some time over the weekend to implement some more features. Currently, the biggest issue I have is that I cannot guarantee that the response read back from the router will actually be what it's meant to be, or indeed, in the case of a 'hanging' cat /var/........ that there will be any response. I've added a check for 'nLineState=0x801' being returned, which I've found is usually indicative of a hung 'cat' command. Program now pops up a message box informing the user that there is probably a hanging command which will need manually killing, and then exits. I've also implemented a timeout for the read routine to try to eliminate a 'no response' situation. This still needs testing though.
That btagent_arc_version command on the /r returns a nice amount of data in a format that can easily be parsed, so I'll definitely be using that.
I'm aiming to have a stable enough version for you to test with within the week.
-
Can't wait for the program Blackeagle!
Don't know whether using the straight shell commands would be a better idea so as not to have the hung 'cat' processes. Have you tried that?
Telnet on the ECI/r has just stopped working and there was no hung commands at the time. I've just disabled BTAgent and re-enabled telnet via serial...
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.smileyvault.com%2Falbums%2Fforum%2Fsmileyvault-offtopic.gif&hash=552640aeb649ffa60c200720b8b00197dc46ed31) (http://www.smileyvault.com/)You seem well versed in programming. Can you provide any pointers on how I would go about installing a script to disable and re-enable telnet every few hrs? :)
-
Interesting question actually !!
The command to find and kill the telnet process would be kill `ps | grep [t]elnetd | cut -f3 -d' '`
What this does, is it evaluates the commands between the `` which find the process id, and then return that to kill, which kills it. ps shows the running processes. This is piped with | to grep. That means the output of ps is the input for the grep command which searches for a line containing telnetd and returns that line. The [t] bit stops it returning its own process as otherwise we would get two lines. The output of grep is sent (piped) to the cut command which uses a space as a delimiter (-d' ') and returns the third field (-f3) which is the pid (process id).
To restart we just need to type telnetd
Luckily, the ECI has a sleep command, so the full line would be kill `ps | grep [t]elnetd | cut -f3 -d' '` && sleep 2 && telnetd & which will kill telnet, and restart it two seconds later.
We can write a script that uses this line, then sleeps for a period of time and then repeats, thus restarting telnet after a specified period.
#!/bin/sh
while true
do
kill `ps | grep [t]elnetd | cut -f3 -d' '`
sleep 2
telnetd
sleep 14400
done
There is a problem though :( The router's filesystem is read-only, so it's impossible to create a script. It is possible though to write the entire thing on one line ;)
while true;do kill `ps | grep [t]elnetd | cut -f3 -d' '`; sleep 2; telnetd; sleep 14400; done
I have tested this, and it works. You can adjust the timing by altering the second sleep command as required. The duration is in seconds so 14400 = 4 hours. You will be logged out immediately on executing the line obviously. A reboot will necessitate re-entering the line.
-
Have enjoyed this thread immensely.
Do remember Asbo highlighting this with the eci/r if it means anything. (not really my area) :-[
# Enable Telnet Daemon
TELNETD_PID=`ps | grep telnetd | grep -v grep |
if [ "$TELNETD_PID" != "" ]; then
kill -9 $TELNETD_PID
fi
util_hkr_mgr msleep 500
/usr/sbin/telnetd 2>&1 &
util_hkr_mgr msleep 500
TELNETD_PID=`ps | grep telnetd | grep -v grep | cut -b 1-5`
echo "Start telnet service (pid :$TELNETD_PID)" > /dev/console
else
echo "Usage : $0 0/1" > /dev/console
exit 1
fi
I'll see if I can find the reference again.
Thanks guys
-
Hi HighBeta, glad you are enjoying it. The code you posted looks to me like a built in script on the ECI.
The grep telnetd | grep -v grep bit means search for a line containing the text telnetd
As it stands, this will return 2 lines. One will be the actual telnetd process, the other will be the 'grep telnetd' process. The grep -v grep part means 'search for lines containing grep, and return the ones that don't'.(Normally grep searches for the text supplied and returns matching lines. The -v flag tells it to invert this and return lines that don't match).
This will clearly just return the line containing the actual telnetd process.
IMHO grep [t]elnetd is a neater solution, requiring just the one command. I'm not exactly clear as to why this works, I just know it does. Others with more Linux experience than me may be able to clarify why it just returns the one line (.....thinks B*cat or Roseway).
-
Yes its part of built in script - I think Asbo was pointing it might be the issue causing the lock ups (?)
I can seem to find the post- A lot of his image pics have expired unfortunately. {I keep looking thought)
Shame Luci web* can not be easy put on with all the openwrt stuff on there.
Back to lurking now :-[ and let the heavy weight linux guys show how its done ;)
*Luci's finnally been patched for dsl control
http://luci.subsignal.org/trac/ticket/620
-
Can't really see that causing lock up's, but anythings possible !!
I think Asbo ultimately decided it was BTAgent causing lock ups of telnet, and killing the btagent processes restored telnet access.
Luci web. Whats that ?? OpenWrt implementation ??
-
Wow Blackeagle. Didn't take you long to work that command out! Thank you
There is a problem though :( The router's filesystem is read-only, so it's impossible to create a script. It is possible though to write the entire thing on one line ;)
Haha, that will save me having to enter each line individually.
I should make you aware that peeps on the ECI/r thread were actually writing to flash as its untouched software would not allow shell access via UART. The idea was to interrupt the boot sequence and use the VR9 switch. I have just checked and this is available on the ECI/I aswell.
http://forum.kitz.co.uk/index.php?topic=11818.msg258001#msg258001
So maybe you might still find a way to add it in permanently! ;)
That problem I reported of losing telnet earlier may have actually not occurred.
At the time I was running EDMT for the stats and it was working great.
But what I have found is that I lose telnet access while it is connected, and I lose EDMT access when telnet is connected. So all that may mean is that only one telnet process at a time will work on the ECI/r.
-
@Blackeagle - I'm having some difficulty getting the telnet command to work on the ECI/r. I've put the command in but the kill command does not seem to locate the right PID. The log does show that the process is attempting to work though. Also once I restart telnet I cannot see any sign of the grep process in the log.
Nb: I changed the sleep times for testing puposes.
IFX CPE login: admin
Password:
BusyBox v1.00 (2012.05.25-03:37+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.
# ps
PID Uid VmSize Stat Command
1 root 440 S init
2 root SWN [ksoftirqd/0]
3 root SW [watchdog/0]
4 root SW< [events/0]
5 root SW< [khelper]
6 root SW< [kthread]
26 root SW< [kblockd/0]
39 root SW [pdflush]
40 root SW [pdflush]
41 root SW< [kswapd0]
42 root SW< [aio/0]
76 root SW [mtdblockd]
1329 root 592 S /opt/lantiq/bin/dsl_cpe_control -i05_01_04_00_04_01_0
1330 root 592 S /opt/lantiq/bin/dsl_cpe_control -i05_01_04_00_04_01_0
1332 root 592 S /opt/lantiq/bin/dsl_cpe_control -i05_01_04_00_04_01_0
1335 root 592 S /opt/lantiq/bin/dsl_cpe_control -i05_01_04_00_04_01_0
1336 root 592 S /opt/lantiq/bin/dsl_cpe_control -i05_01_04_00_04_01_0
1364 root SW [autbtex]
1365 root SW [pmex_ne]
1366 root SW [pmex_fe]
2100 root 368 S /sbin/syslogd -s 8 -b 2 -l 8
3196 root 348 S /usr/sbin/util_hkr_mgrd
3487 root SW< [cfmEntry]
3488 root SW< [cfmT]
3489 root SW< [cfmC]
3490 root SW< [cfmL]
3491 root SW< [cfmP]
3520 root 328 S /sbin/watchdog -t 90 /dev/ifx_wdt
3525 root SWN [jffs2_gcd_mtd3]
3530 root 472 S -sh
4150 root 336 S /usr/sbin/telnetd
4154 root 468 S -sh
4965 root 212 S udhcpc -i br0.301
5293 root 468 S -sh
5294 root 448 R ps
# while true
> do
> kill `ps | grep [t]elnetd | cut -f3 -d' '`
> sleep 30
> telnetd
> sleep 30
> done
kill: 8: Illegal number: root
telnetd: bind: Address already in use
kill: 8: Illegal number: root
telnetd: bind: Address already in use
kill: 8: Illegal number: root
telnetd: bind: Address already in use
kill: 8: Illegal number: root
telnetd: bind: Address already in use
kill: 8: Illegal number: root
And after restarting telnet:
IFX CPE login: admin
Password:
BusyBox v1.00 (2012.05.25-03:37+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.
# ps
PID Uid VmSize Stat Command
1 root 440 S init
2 root SWN [ksoftirqd/0]
3 root SW [watchdog/0]
4 root SW< [events/0]
5 root SW< [khelper]
6 root SW< [kthread]
26 root SW< [kblockd/0]
39 root SW [pdflush]
40 root SW [pdflush]
41 root SW< [kswapd0]
42 root SW< [aio/0]
76 root SW [mtdblockd]
1329 root 592 S /opt/lantiq/bin/dsl_cpe_control -i05_01_04_00_04_01_0
1330 root 592 S /opt/lantiq/bin/dsl_cpe_control -i05_01_04_00_04_01_0
1332 root 592 S /opt/lantiq/bin/dsl_cpe_control -i05_01_04_00_04_01_0
1335 root 592 S /opt/lantiq/bin/dsl_cpe_control -i05_01_04_00_04_01_0
1336 root 592 S /opt/lantiq/bin/dsl_cpe_control -i05_01_04_00_04_01_0
1364 root SW [autbtex]
1365 root SW [pmex_ne]
1366 root SW [pmex_fe]
2100 root 368 S /sbin/syslogd -s 8 -b 2 -l 8
3196 root 348 S /usr/sbin/util_hkr_mgrd
3487 root SW< [cfmEntry]
3488 root SW< [cfmT]
3489 root SW< [cfmC]
3490 root SW< [cfmL]
3491 root SW< [cfmP]
3520 root 328 S /sbin/watchdog -t 90 /dev/ifx_wdt
3525 root SWN [jffs2_gcd_mtd3]
3530 root 472 S -sh
4150 root 336 S /usr/sbin/telnetd
4154 root 468 S -sh
4965 root 212 S udhcpc -i br0.301
5338 root 468 S -sh
5339 root 448 R ps
#
-
OK, the easiest way to debug this is to just type in this part grep [t]elnetd | cut -f3 -d' ' and see what that returns. If you get a blank line, or a number that isn't the PID of telnetd, then the cut part of the command may need adjusting. Normally, I would have cut field 2 (-f2) to return the pid, but this wasn't returning it on my ECI/i and -f3 did.
You won't see the grep process listed under ps. What you should see I think is /bin/sh which will be the shell instance running the infinite loop. You would only see grep if it was actually running when you type ps.
Only one telnet connection is a little limiting :(
-
Just a comment (no criticism is implied) but this thread's subject line refers to the V-2FUb/I (the original ECI CPE provided by Openreach), yet the latter posts of this thread are all related to the V-2FUb/r . . . :-X
-
Just a comment (no criticism is implied) but this thread's subject line refers to the V-2FUb/I (the original ECI CPE provided by Openreach), yet the latter posts of this thread are all related to the V-2FUb/r . . . :-X
That does appear to be the case :-[
However, the monitor in development is being designed for the ECI/i, with additions available for those using the ECI/r.
As a completely on topic remark, I make the following observations.
The ECI/i is a horrible piece of rubbish compared to the HG612. Certainly on my line this has proved to be the case, in spite of the fact my DSLAM is also Infineon. Sync speed is 5Mbps less than the HG612 and interleaving appears to be much higher at 2125ms. The only positive I have noticed, is that at some points, the ECI is able to utilise the D2 band. My HG612 completely ignores this band, having as it does an attenuation of 74dB. The ECI only sometimes manages to use it, reporting an SNR figure of 64dB when not in use
All things being equal, once the development of the monitor is over, I think I shall be switching back to the HG612. I've seen other posts by people saying their ECI's are better on their lines, but sadly that hasn't been my experience to date.
-
I to found the ECI/I the least capable of out of the crop of openreach cpe units when paired to an ECI Msan. {ECI/r v2 the most} On the other hand other users have reported the opposite.
Thanks for the continued development & useful scrips Blackeagle :)
-
Sorry burakkucat, didn't mean for the thread to veer off topic. :-[
@Bleackeagle - I had a go with changing the telnet commands from f3 to f2 with no joy. I ending up rebooting after multiple attempts at trying to get it to work and then finally losing serial access aswell.
After the reboot I found I could use eDMT and telnet simultaneously....I think i'll leave that testing for now and open a new thread posing the question again in the future if needed.
I'm sorry to hear that the ECI/I is not working for you. Would you not consider trying the ECI/r?
Let me know if you need to test anything further on the ECI/r or the offline ECI/I before the beta test release.
-
I'm sorry to hear that the ECI/I is not working for you. Would you not consider trying the ECI/r?
Definitely, if I had one !! I think the ECI/r may well perform better on my line (which is prone to errors) but much testing with the /i has revealed it (in my case) to not perform as well as the HG612.
I've always been a bit of a fan of Broadcom chipsets (except for wireless, where I have found Atheros to be superior) and unfortunately, my testing so far has only borne this out.
From another point of view, its annoying that the ECI/i is a bit haphazard in what it returns to my program, although I must admit, this could well be down to my code :-[
In pseudo code what happens is the following
Send a command to router
send 'cat' command
wait 50ms
read responseso if we send eg "g997bang 0 1 > /tmp/pipe/dsl_cpe0_cmd"
and then "cat /tmp/pipe/dsl_cpe0_ack", we would expect the response to be the output from the 'cat' command. This isn't the case however. Sometimes the response includes the first command, the second command, and the data. Sometimes it includes the second command (the 'cat') and the data, sometimes just the data. I have half an idea that this may be down to the telnet library I am using, and as such I am seriously considering scrapping that code and writing from scratch. At the end of the day, for what data I need to get, telnet is just a socket on port 23. I don't see a need to handle some of the more fancy stuff that telnet supports, just basic communication.
Currently my program does its best to avoid these issues. If unexpected or missing data is returned then its just ignored and the program continues. This can make some of the graphs scruffy though, which is why I'd like to avoid it at all if possible. As my code stands at present, the only things that stop the program are either incorrect router details (in that it cannot obtain a connection), or the router closing the telnet session.
Another option is to make the program multi-threaded. This would make the GUI separate from the reading routines, which would run in another thread. I don't have any experience of doing this however, although some searching reveals it's probably not that difficult to implement. A benefit of doing it this way would be that the GUI would be far more 'snappier'.
Finally, regarding the large error figures returned in both a telnet session and the http GUI.
I still think this could be due to overflow. As far as I can ascertain, all the high values start 429496xxxx which in Hex would be FFFFxxxx. I'm hoping B*cat or 4c amongst others may have a comment to make regarding this.
-
Finally, regarding the large error figures returned in both a telnet session and the http GUI.
I still think this could be due to overflow. As far as I can ascertain, all the high values start 429496xxxx which in Hex would be FFFFxxxx. I'm hoping B*cat or 4c amongst others may have a comment to make regarding this.
I suspect that you are correct and it is, indeed, overflow.
Depending upon what you wish to present, perhaps either Bald Eagle1, Ronski or Eric might be able to suggest a means to provide sensible values?
-
Another option is to make the program multi-threaded. This would make the GUI separate from the reading routines, which would run in another thread. I don't have any experience of doing this however, although some searching reveals it's probably not that difficult to implement. A benefit of doing it this way would be that the GUI would be far more 'snappier'.
Yes, that's what I do with DSLstats, and it made an enormous difference to the responsiveness of the program. Doing it in practice proved to be a fair bit easier than various tutorials made it seem.
-
Depending upon what you wish to present, perhaps either Bald Eagle1, Ronski or Eric might be able to suggest a means to provide sensible values?
I could certainly make some suggestions. After each sample is taken, I compare the new values with the previous ones, and take appropriate action depending on those comparisons. Here's the section of code in DSLstats which processes CRC values. 'Up' and 'Down' are the new upstream and downstream CRC totals as read from the modem. 'CRCup' and 'CRCdown' are the totals as read in the previous sample. The rest is probably fairly self explanatory.
//Process CRC values
procedure ProcessCRC(Up, Down: Extended);
begin
RouterErrors.CRCdown := Round(Down);
RouterErrors.CRCup := Round(Up);
if TNow <> OldT then Multiplier := 60 / SecondsBetween(TNow, OldT)
else Multiplier := 1;
NUp := 0; //Set both values to zero initially
NDown := 0;
if (CRCup > 0) or (CRCdown > 0) then //Don't process if both previous values were zero
begin
if (Down >= CRCDown) and (Up >= CRCup) then //Normal situation
begin
NUp := (Up - CRCUp) * Multiplier;
NDown := (Down - CRCDown) * Multiplier;
ErrorArray[ErrorDays].CRCdown := ErrorArray[ErrorDays].CRCdown + Round(Down - CRCdown);
ErrorArray[ErrorDays].CRCup := ErrorArray[ErrorDays].CRCup + Round(Up - CRCup);
end
else if (Down = 0) and (Up = 0) then //Treat as missed sample
begin
WasPaused := True;
NUp := 0;
NDown := 0;
end
else if (Down >= CRCdown) or (Up >= CRCup) then //Treat as a blip or a value wraparound
begin
if Up < CRCup then //CRCup has blipped or wrapped around
begin
NUp := 0;
NDown := (Down - CRCdown) * Multiplier;
ErrorArray[ErrorDays].CRCdown := ErrorArray[ErrorDays].CRCdown + Round(Down - CRCdown);
end
else begin //CRCdown has blipped or wrapped around
NUp := (Up - CRCUp) * Multiplier;
NDown := 0;
ErrorArray[ErrorDays].CRCup := ErrorArray[ErrorDays].CRCup + Round(Up - CRCup);
end;
end
else begin //Treat as resync/reboot
NUp := 0;
NDown := 0;
end;
CRCchart.AddXY(TNow, NUp, NDown, WasPaused);
CheckAlerts(atCRC, NDown, NUp);
end;
CRCdown := Round(Down);
CRCup := Round(Up);
ErrorArray[ErrorDays].TD := TNow;
end;
-
Thank you b*cat for confirming that. :)
And thank you Eric for that piece of code, and the insight into how DSLstats works. Thinking about it, comparing to the previous values is definitely the way to go. B'eagle shudders at the sight of Pascal !!! Many many moons have passed since I last wrote in Delphi, probably Delphi 4. As I recall, it was an extremely flexible package.
Regarding multi-threading. I have the source code for eDMT, which is multi-threaded and it doesn't look like it would be too difficult to implement it. Of course it's always easier reading someone else's code than writing one's own. eDMT is written in Mono, which is pretty much c# and uses the same zedgraph charting library that I am using. The telnet library though is completely different, so I might have a look at that, although eDMT also suffers from the ECI returning bad data if you keep hitting the refresh button.
-
From another point of view, its annoying that the ECI/i is a bit haphazard in what it returns to my program, although I must admit, this could well be down to my code :-[
In pseudo code what happens is the following
Send a command to router
send 'cat' command
wait 50ms
read responseso if we send eg "g997bang 0 1 > /tmp/pipe/dsl_cpe0_cmd"
and then "cat /tmp/pipe/dsl_cpe0_ack", we would expect the response to be the output from the 'cat' command. This isn't the case however. Sometimes the response includes the first command, the second command, and the data. Sometimes it includes the second command (the 'cat') and the data, sometimes just the data. I have half an idea that this may be down to the telnet library I am using, and as such I am seriously considering scrapping that code and writing from scratch. At the end of the day, for what data I need to get, telnet is just a socket on port 23. I don't see a need to handle some of the more fancy stuff that telnet supports, just basic communication.
Sorry Blackeagle, I asked earlier in the thread but I don't know whether you tried using the single line commands instead of using 'echo' and 'cat'. I have yet to see any hung commands or variable responses on the ECI/r with it although I probably haven't sent many commands through.
# /opt/lantiq/bin/dsl_cpe_pipe.sh pmdpctg 0 0; /opt/lantiq/bin/dsl_cpe_pipe.sh pmcctg 0 0; /opt/lantiq/bin/dsl_cpe_pipe.sh pmlsctg 0;
/opt/lantiq/bin/dsl_cpe_pipe.sh pmdpctg 0 1 ; /opt/lantiq/bin/dsl_cpe_pipe.sh pmcctg 0 1; /opt/lantiq/bin/dsl_cpe_pipe.sh pmlsctg 1
nReturn=0 nChannel=0 nDirection=0 nElapsedTime=79862 bValid=1 nHEC=0 nTotalCells=0 nUserTotalCells=0 nIBE=0 nTxUserTotalCells=0 nTxIBE=0 nCRC_P=7 nCRCP_P=0 nCV_P=280 nCVP_P=0
nReturn=0 nChannel=0 nDirection=0 nElapsedTime=79862 bValid=1 nCodeViolations=1 nFEC=4294967294
nReturn=0 nDirection=0 nElapsedTime=79862 bValid=1 nES=1 nSES=0 nLOSS=0 nUAS=51 nLOFS=0
nReturn=0 nChannel=0 nDirection=1 nElapsedTime=79862 bValid=1 nHEC=0 nTotalCells=0 nUserTotalCells=0 nIBE=0 nTxUserTotalCells=0 nTxIBE=0 nCRC_P=0 nCRCP_P=0 nCV_P=0 nCVP_P=0
nReturn=0 nChannel=0 nDirection=1 nElapsedTime=79862 bValid=1 nCodeViolations=0 nFEC=0
nReturn=0 nDirection=1 nElapsedTime=79862 bValid=1 nES=0 nSES=0 nLOSS=0 nUAS=51 nLOFS=0
#
The only time today that I have had telnet hanging was when I was using eDMT and one of the commands must have hung causing the piped commands to fail. This time I did not see any hung cat process. so I sent a cat command via telnet and I was given a response for the bit loading even though I had not sent an echo command. After this eDMT began working again.
Seems to me that the echo and cat commands using pipe are the cause of these issues.
-
Seems to me that the echo and cat commands using pipe are the cause of these issues.
Personally, I don't see the difference between doing it that way, and using the shell script on the router, which in itself, only does the same thing. I think its more likely to be just the sheer amount of processing the router is being asked to do that results in the odd 'stuck' command. I'm sending 20+ commands to it, 5ms apart, every 15 secs.
Not had much time to work on this due to family commitments over the holiday, but I have re-written part of the sampling routine to be asynchronous. This has made the GUI more responsive. I've also written some code that attempts to detect a 'hung' cat process and kill it. I've also written a bit to detect the opposite, which is what custard referred to when you have (presumably) sent the 'cat' command too fast and need to do it again. This is harder to reliably detect however.
I've also added an FEC graph, for both upstream & downstream. It appears to work reasonably well, although I am still unsure about the handling of the unfeasibly large numbers sometimes returned. I've noted that when these values appear, they still count upwards for a period of time. Telnet and http access both return the same value, as noted earlier in the thread.
For the programmers that may read this, what I have currently done is, because the number is larger than a 32bit integer and because I feel that its an overflow somewhere, read the value as a 64 bit integer, and then just cast it to 32 bit. This just throws away the top 32 bits. I am still left with a very large value however, as witnessed in the short period of graphing attached. To try and gain a better understanding of when the router trips to these values, I'm going to attempt to sample the errors every second and write them to a file. Hopefully I can find a pattern or at least work out the last sensible value returned.
-
Seems to me that the echo and cat commands using pipe are the cause of these issues.
Personally, I don't see the difference between doing it that way, and using the shell script on the router, which in itself, only does the same thing. I think its more likely to be just the sheer amount of processing the router is being asked to do that results in the odd 'stuck' command. I'm sending 20+ commands to it, 5ms apart, every 15 secs.
Not had much time to work on this due to family commitments over the holiday, but I have re-written part of the sampling routine to be asynchronous. This has made the GUI more responsive. I've also written some code that attempts to detect a 'hung' cat process and kill it. I've also written a bit to detect the opposite, which is what custard referred to when you have (presumably) sent the 'cat' command too fast and need to do it again. This is harder to reliably detect however.
I've also added an FEC graph, for both upstream & downstream. It appears to work reasonably well, although I am still unsure about the handling of the unfeasibly large numbers sometimes returned. I've noted that when these values appear, they still count upwards for a period of time. Telnet and http access both return the same value, as noted earlier in the thread.
For the programmers that may read this, what I have currently done is, because the number is larger than a 32bit integer and because I feel that its an overflow somewhere, read the value as a 64 bit integer, and then just cast it to 32 bit. This just throws away the top 32 bits. I am still left with a very large value however, as witnessed in the short period of graphing attached. To try and gain a better understanding of when the router trips to these values, I'm going to attempt to sample the errors every second and write them to a file. Hopefully I can find a pattern or at least work out the last sensible value returned.
Interesting. I assumed the very unlikely high value was a result of the maximum value of a UInt32 minus whatever has counted so far. I too am trying to figure out what might seem realistic and have written a basic console app in C#.NET which requests these statistics once every second. By doing this I can also roughly count the ES and SES internally in the application :) (as I haven't found ES or SES anywhere else).
The range of a UInt32 is 0 to 4294967295 (or 4,294,967,295).
Oh, one question. nDirection, which number is upstream and which number is downstream?
EDIT: While doing so overnight, it seems this morning I woke up to an immensely laggy connection (like dialup). Pings in the 200ms+ region, speeds diabolical. Power cycled the modem and it's back to normal now. My guess is that the modem didn't like the speed I was sending the commands to it at, or I was just very unlucky.
-
nDirection, 0=downstream, 1= upstream. echo " pmlsc1dg 0 0 " > /tmp/pipe/dsl_cpe0_cmd will give you SES & UAS. pmdpc1dg 0 0 0" > /tmp/pipe/dsl_cpe0_cmd will give you CRC. These are 15 min intervals but you can also do showtime or 24 hrs.
With regard to the 429496xxxxx numbers, I have noted that these count both down and up. This is definitely an issue in trying to graph the data and get something sensible from it.
-
nDirection, 0=downstream, 1= upstream. echo " pmlsc1dg 0 0 " > /tmp/pipe/dsl_cpe0_cmd will give you SES & UAS. pmdpc1dg 0 0 0" > /tmp/pipe/dsl_cpe0_cmd will give you CRC. These are 15 min intervals but you can also do showtime or 24 hrs.
With regard to the 429496xxxxx numbers, I have noted that these count both down and up. This is definitely an issue in trying to graph the data and get something sensible from it.
I see, thanks. That's annoying that they go in both directions :(.
-
nDirection, 0=downstream, 1= upstream.
I'm seeing this the other way round. ???
Alpha # echo "g997csg 0 0" > /tmp/pipe/dsl_cpe0_cmd
Alpha # cat /tmp/pipe/dsl_cpe0_ack
nReturn=0 nChannel=0 nDirection=0 ActualDataRate=19992000 PreviousDataRate=20000000 ActualInterleaveDelay=950 ActualImpulseNoiseProtection=26
Alpha # echo "g997csg 0 1" > /tmp/pipe/dsl_cpe0_cmd
Alpha # cat /tmp/pipe/dsl_cpe0_ack
nReturn=0 nChannel=0 nDirection=1 ActualDataRate=59504000 PreviousDataRate=67212000 ActualInterleaveDelay=975 ActualImpulseNoiseProtection=30