Print

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

[Bald_Eagle1]

That's for all 4095 tones!!! Oh, and  BTW when I said HG622, I really meant HG612 with the new blob!  Sorry!  I had swapped out the 612 for the 622 earlier today, but I was having some difficulties with Paul's stats on the 622, so decided to flash the new blob onto the 612 instead and use that.

I haven't actually tried my programs on the HG622.
Is there any indication in the various error logs as to where things go wrong?

Someone in another forum seemed to suggest it is possibly at the logging in stage.

So, not the 622, but the 612 with the new blob.  But it seems that the new blob doesn't record bitloadings changes between syncs.  Has anybody else seen this, or am I just  (don't answer that either!  )

I can also confirm from my own previous testing that bitloading data remains static between resyncs when using the new BLOB.

[roseway]

I had an issue with Bit Swap per minute graph not continuing to be logged after a loss of sync..? all other graphs were logged and captured

If that situation still exists, could you take a manual note of the values in the Bitswap: line of the Connection stats over a few samples. I just want to be sure that the new blob version is reporting sensible values. Assuming that this is the case (it probably is) then I suspect that the program has failed to notice the re-sync (which would have reset the bitswap totals) and is still thinking that it's seeing a negative change in the bitswap totals, which it converts to zeroes.

also, i think it would be great if the app can save screenshot captures into folders for each day... I can imagine it getting pretty messy in there after even a few days of logging - I intend to leave this running for a bit so will have to do some manual house-keeping hehe

That's a good suggestion - I've put it on the todo list.

Elsewhere you mentioned a discrepancy in the reported interleave values - could you please copy the Connection stats output to me so that I can see what's actually being reported by the router.

[les-70]

Someone in another forum seemed to suggest it is possibly at the logging in stage.

   I have not tried the graphing scrips with the HG622 but I did try the SRNRM tweak files with it.  Those needed all three login files to be edited to end in just <0d>  i.e. cr,  also the final exit used needed to done with a file using just the <0D> ending.   I don't know how rs-w does it , maybe it always uses just cr endings.

[c6em]

Can putting the snapshot graphs into separate daily folders be an option rather than a non changeable default please.

Reason being.
If I have a fault/REIN occurance and am wanting to rapidly compare graphs of say SNR from day to day the very last thing I want is to have to jump back up/down to/from between directories for every stored day to find the file in the list and load each one up for viewing.
The last time I did have this situation I wanted them all in the same directory all next to each other so I could click on each one to view it rapidly.

Seperate daily directories does indeed make sense and is a good idea if you are running the program daily for archiving and record keeping purposes of your line's performance.

[ZeeGy]

This is just a quick bugfix version to deal with the issue a few users have reported concerning negative values in the "per minute" graphs, leading to a program crash when logarithmic scaling is selected for the FEC graph.

http://rsux.plainroad.me.uk

Roseway, I would like to thank you for your continued development of this application. it is getting better and better on every release. I cannot thank you enough.

I do however have one request / section. I am very cautious about the levels of interleaving on my modem, and I want to try and monitor this as much as I can. How easy it to either
a.) plot this on a seperate chart
b.) dump this to another seperate text file so that I can run my own stats on it.


Many thanks in advance.

[ColinS]

I haven't actually tried my programs on the HG622.
Is there any indication in the various error logs as to where things go wrong?
Someone in another forum seemed to suggest it is possibly at the logging in stage.

My difficulties were simply that your package is now so essential to me, I didn't want to use the new box in anger until I knew that it would be properly monitored by it.  I wasn't sure if you had one of Asbokid's new boxes, but checking to see if the package and it were compatable was the first thing I did with it!    :clap2:

Yes, that was Les-70 here on Kitz.  It accepts the username OK, but fails to properly recognise the password.  He suggested ensuring the loginx.txt files were terminated with solely a <CR> rather than <CR LF> or <OD> rather than <0D 0A>.  I didn't want to bother you about that, so I've PM him as I've tried various combinations now without success, but it was gettting rather late! 

The other thing was that becuase I saw quickly that problem (using set_hg612_date_and_time manually), I tried a quick snapshot, but it seems to 'hang' after #3 in the harvesting sequence.  As I said, I know you're very busy just now, so I will work at it and collate more evidence (if I can do that 'offline') before letting you know, as it's not so easy for me to try to fix now it's coded! 

I can also confirm from my own previous testing that bitloading data remains static between resyncs when using the new BLOB.

OK, so it was late, as I've said  but I did work it out (eventually) for myself.  As we've said before, bitswaping is a good thing, but the fact that Eric shows us where and how often it is occurring is another useful tool in our armoury to learn about how our line is performing, and I've found it helpful. I'm therefore not (yet) sure whether losing that ability is balanced by the potential increase in achievable rates (which can't be used) or the reduction in ES/CRCs,which were not high anyway considering I am still on fastpath. It certainly will be for other people   But I haven't made up my mind yet.  I'll try to keep up in future! 

[EDIT] note to Eric, it is because of how useful the things you do in RS-? are that when there's a change in something, it's immediately obvious, even if it takes me a bit to catch upon why.   :clap2:

[roseway]

I have not tried the graphing scrips with the HG622 but I did try the SRNRM tweak files with it.  Those needed all three login files to be edited to end in just <0d>  i.e. cr,  also the final exit used needed to done with a file using just the <0D> ending.   I don't know how rs-w does it , maybe it always uses just cr endings.

In most cases rs-ux/w assumes Unix line endings (0a) for logging in, but I recently found that Thomson/Technicolor routers expect Windows line endings (0d0a), so I had to change the setting for that particular range of routers.

[roseway]

Can putting the snapshot graphs into separate daily folders be an option rather than a non changeable default please.

Yes, I'll make it an option.

[roseway]

Roseway, I would like to thank you for your continued development of this application. it is getting better and better on every release. I cannot thank you enough.

I do however have one request / section. I am very cautious about the levels of interleaving on my modem, and I want to try and monitor this as much as I can. How easy it to either
a.) plot this on a seperate chart
b.) dump this to another seperate text file so that I can run my own stats on it.

Thank you for your comments.

I'm surprised that your interleaving levels change often enough to be worth plotting. Normally these values will only change when there's a re-sync. I can certainly dump the values to a text file periodically. What frequency and what format for the text file would be useful to you?

[roseway]

[EDIT] note to Eric, it is because of how useful the things you do in RS-? are that when there's a change in something, it's immediately obvious, even if it takes me a bit to catch upon why.

I would certainly prefer issues like this to be reported, even if it does subsequently turn out that the source of the issue is elsewhere.

[ColinS]

In most cases rs-ux/w assumes Unix line endings (0a) for logging in, but I recently found that Thomson/Technicolor routers expect Windows line endings (0d0a), so I had to change the setting for that particular range of routers.

As does the HG612 it seems, as this is what Paul, like you, has done for the username/password/sh/exit responses.  This is working fine for the 612 irrespective of which blob is in use.  However, it appears, atm, that the HG622 has some issue with <0D 0A> at the password prompt i.e. it is happy with that for the username response, and indeed if you do the whole thing from a Windows telnet session (which seems to imply Windows endings), but complains that it doesn't recognise the password reply.  As it then takes the next 2 inputs sh/exit? as other password attempts, it seems that it is the line termination at that point that is sus.  I have tried a <0D> ending (on the assumption for the moment that Paul's compiled v1.0 is still using the .txt files in the app directory  ), but without success.  But I really need to retest slooowly. 
Perhaps my assumption is simply wrong

[ZeeGy]

Roseway, I would like to thank you for your continued development of this application. it is getting better and better on every release. I cannot thank you enough.

I do however have one request / section. I am very cautious about the levels of interleaving on my modem, and I want to try and monitor this as much as I can. How easy it to either
a.) plot this on a seperate chart
b.) dump this to another seperate text file so that I can run my own stats on it.

Thank you for your comments.

I'm surprised that your interleaving levels change often enough to be worth plotting. Normally these values will only change when there's a re-sync. I can certainly dump the values to a text file periodically. What frequency and what format for the text file would be useful to you?

Daily would be ample, agreed it rarely changes, but it would be usefull to plot them on say, a monthly chart to help track any interleaving issues.

[ZeeGy]

Roseway, I would like to thank you for your continued development of this application. it is getting better and better on every release. I cannot thank you enough.

I do however have one request / section. I am very cautious about the levels of interleaving on my modem, and I want to try and monitor this as much as I can. How easy it to either
a.) plot this on a seperate chart
b.) dump this to another seperate text file so that I can run my own stats on it.

Thank you for your comments.

I'm surprised that your interleaving levels change often enough to be worth plotting. Normally these values will only change when there's a re-sync. I can certainly dump the values to a text file periodically. What frequency and what format for the text file would be useful to you?

Daily would be ample, agreed it rarely changes, but it would be usefull to plot them on say, a monthly chart to help track any interleaving issues.

Actually, you can scrap that. I have created a batch file, that telnets into the router once a day, does a xdslcmd info --show and exports to a text file of the days date. so now, I can go through my logs pull out the values I am after.

[les-70]

I have not tried the graphing scrips with the HG622 but I did try the SRNRM tweak files with it.  Those needed all three login files to be edited to end in just <0d>  i.e. cr,  also the final exit used needed to done with a file using just the <0D> ending.   I don't know how rs-w does it , maybe it always uses just cr endings.

In most cases rs-ux/w assumes Unix line endings (0a) for logging in, but I recently found that Thomson/Technicolor routers expect Windows line endings (0d0a), so I had to change the setting for that particular range of routers.

  Just to confirm that at login and at ATP level (for shell and exit) I find the HG622 needs either 0a or 0d, but since it responds to both  --NOT both.  I probably used 0d rather than 0a due to not thinking linux!

[roseway]

Actually, you can scrap that. I have created a batch file, that telnets into the router once a day, does a xdslcmd info --show and exports to a text file of the days date. so now, I can go through my logs pull out the values I am after.

OK, thanks, I'll cross that one off the list.