Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Blackeagle]

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

Code: [Select]

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.

[burakkucat]

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?

[roseway]

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.

[roseway]

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.

Code: [Select]

  //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;


[Blackeagle]

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.

[custard]

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

Code: [Select]

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.

Code: [Select]

# /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.

[Blackeagle]

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.

[Ixel]

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.

[Blackeagle]

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.

[Ixel]

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 .

[custard]

nDirection, 0=downstream, 1= upstream.

I'm seeing this the other way round.

Code: [Select]

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