Print

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

[sevenlayermuddle]

Quick reply I will have to mull over your suggestion fully...  But I think the dlm should be more than used to having a < situation.   People who physically turn off their routers, people buy new routers, people reset routers etc.

Fair point I think, though I still have a niggling doubt that I can't quite get my head around.

Would certainly be an interesting experiment.   Yes it could go wrong, but with you being on adsl rather than vdsl, if worse comes to worst you could approach your ISP for a dlm reset.

I don't have hight confidence in that possibility.  I won't name & shame my ISP again, but the only support is by Indian help centre and the last time I asked them for a DLM reset it took several weeks and a formal complaint to the UK parent even just to get them to understand the request. And then they seemed to do the wrong thing.

  I will think about this some more today.

Well I think you've talked me back into it already, but I'll hold fire for a day or so to see what other comments may arise.

I may in any case benefit from some assistance in writing the Linux script that does the resets, shellscripting has never been my strong point.   I'd imaging a wget from the 'reset' URL every so often would do the trick, and that's easy enough in a while loop with a sleep, but not sure how to handle the router's sign-on dialogue?  I can't help thinking such knowledge must already exist on these forums, if the right contributors happen to read this and feel inclined to assist… hint... hint...       

[roseway]

if the right contributors happen to read this and feel inclined to assist… hint... hint...

I can't help with shell scripting, but DSLstats has the "Custom commands" feature which gives the possibility to send any CLI commands you like to the modem/router at specified intervals.

[Edit] I think that the command is adsl info --reset

"--reset   -   Clears all statistic counters in ADSL driver"

[sevenlayermuddle]

if the right contributors happen to read this and feel inclined to assist… hint... hint...

I can't help with shell scripting, but DSLstats has the "Custom commands" feature which gives the possibility to send any CLI commands you like to the modem/router at specified intervals.

[Edit] I think that the command is adsl info --reset

"--reset   -   Clears all statistic counters in ADSL driver"

I suspected one of the right people would respond   

Thanks!

This may, then, be the catalyst for me to install DSLstats.

But with these comments you have also inspired me with another alternative, far less bother than my server-based script,  which is to simply telnet into the router, open a shell, and write the loop from the command line. 

It is running now as proof of concept, with telnet session from the MAC, but I still need to find a way of preventing the telnet from closing when the MAC power-saver kicks in.  The server itself is headless, so telnetting from the server barely helps.  But  I already have an idea for that and am working on it...

[sevenlayermuddle]

It is running now as proof of concept, with telnet session from the MAC

And I have to say it's fun to watch. 

I concurrently set up a GUI window to the stats and just watched.   Eventually, after two or three minutes, 'RS correctable Errors' clocked up 4 on the downstream.  Then a few seconds later before I'd really been able to focus, when the GUI refreshed again, they'd gone, vanished, back to zero!   

Anyways its on hold now while I think about the issue of telnet & power savers, and just in case any more comments come in that convince me it's a bad idea.

[kitz]

Well I thought about it a bit more as I was driving somewhere yesterday, and couldnt really think of another reason of why not to try it.

In fact even before I'd seen erics reply I'd even already jumped to the conclusion of if this comes off, I could perhaps see dslstats being an ideal tool to assist with this. 

As I was racing down a dual carriage way, my mind was already racing ahead at certain possibilities..  ie gather the stat counters, save to log, clear stat counters.  gather stat counters, add to log total, clear stat counters.  haha sorry eric.

Yep I'd go for it 7LM..  please do let us know..  Im really interested in this.

[kitz]

On fastpath with no interleaving I think a CRC often causes a re-transmit and not an FEC.

Correct *

* ignoring that PhyR can do some fancy stuff.

My guess is that it may mean that the dlm is then not aware of the rate of error correction that occurs without a re-transmit of a packet.

My guess would be that the DLM (for downstream at least) doesnt monitor re-transmits at all, and relies on stat counters.

I doubt it would monitor FECs, CRCs perhaps - but even then i wouldnt think it measure re-transmits as thats done at a higher level on the stack such as ARQ.  Im pretty sure how it works is that the router will identify an error from the check sum, adds to the counter, then its up to one of the TCP/IP protocols to handle the actual repeat request.  The MSAN at the other end has access to any counters, but unless Im missing something I dont think it would or could keep track of protocols such as ARQ from the far end.   Obviously upstream is a different matter as in the event of an upstream error, then the DSLAM will be sending the re-request.  Off the top of my head I cant think of a way the dslam could know whether any downstream packets is a re-request or not.

Although we dont know for sure, I really wouldnt be surprised if the DLM didnt actually use CRCs & HECs but more concentrated on ErrSecs or one of the other alarm state counters such as LoF/LoS etc.  Obviously too many CRCs/HECs together will trigger an ErrSec anyhow, which is why Im willing to bet its ErrSecs & alarm states that the DLM takes into consideration.     

[kitz]

ETA

After typing that, I walked away to do something else, but the thought still nagged at me.. and I thought about it some more.   I'm pretty certain that the dslam can NOT know if a downstream packet is a retransmit or not.

At the receiving end a decoder then performs the same calculation on the data in the packet and then compares it to the transmitted CRC code.

The decoder produces the output data only if the codes match indicating that there are no errors. If an error occurs then the decoder signals an erasure (loss of data), and a higher level ARQ then re-requests the data.

http://www.kitz.co.uk/adsl/error_correction.htm

All the router does is in effect monitor for errors, if the checksum isnt right, then adds a number to the stat counter. ARQ asks for the packet again from the remote server, not the DSLAM, hence why the dslam couldnt know if it was a retransmit. Even remote servers dont monitor for re-tranmits, they just dish up the data again. 

7LM - with a nick like yours TCP/IP & protocols is your forte.  Thoughts?

[sevenlayermuddle]

If TCP retransmits then I don't think the DSLAM knows about retransmits, unless it was performing some intense analysis of the passing data which would (1) be too expensive and (2) possibly illegal (snooping). 

But  I also vaguely recall some excitement a few years back about something from Broadcom called PhyR,  for physical layer retransmision.   Supposed to be Especially useful for purely IP applications like that don't benefit from TCP retransmits, such as IPTV.   Not sure what became of that?

Anyway, I am ready to go with my experiment, but will hold fire until tomorrow.  I was still fiddling around with the router yesterday, nailing it to the wall in different places and with the odd reboot, so I want to wait a day to make certain I've not already annoyed DLM

At risk of appearing ungrateful to Eric, whilst the implementation I have settled upon was entirely inspired by his comments, it doesn't require DSLstats

Instead, I have a very trivial shellscript (that's the kind I like) that can reside on either the MAC or the Linux system and contains an 'adsl info --reset >> /dev/null'  and a 'sleep 60' within an infinite while/do/done loop.   The script is provided as input to an rsh incantation, causing it to ask for the password just once and then execute on the router and to continue execution until manually killed, even if the client system goes into power-save and disconnects. 

[roseway]

At risk of appearing ungrateful to Eric,...

Think no more of it.

[sevenlayermuddle]

Ok, just started the experiment, stats are being reset every 60 seconds.   

Currently connected with an untweaked 12dB target at just over 3.5Mbps.   That's is not too ambitious as I sustained close to 5mbps through most of the winter, but just nudges me into the 3Mbps profile range.

I'll update this thread with any observations, but it may be a while.  Pretty much everything I've read about DLM suggests that whilst target increases happen very quickly, target reductions take much longer.  There is evidence that 14 days is the absolute bare minimum, but we'll see...

[kitz]

Good Luck.  Hope it works

[sevenlayermuddle]

24 hours in and no obvious ill effects, ie no reconnects and no margin increase.   Just lovely looking stats with error counters that, when sampled in the GUI, are nearly always exactly zero.



It still may be all pointless of course, the router may be clever enough to just reset the locally reported stats while still reporting cumulative stats to the DSLAM.   Or DLM may notice the other quirks, like the fact my superframe & cell counters etc are infeasibly low...

[Blackeagle]

It still may be all pointless of course, the router may be clever enough to just reset the locally reported stats while still reporting cumulative stats to the DSLAM.   

Should the experiment fail, I think this may well be the most likely reason, however, I feel the experiment is well worth doing if only for the fact that one should always experiment wherever possible 

[kitz]

Or DLM may notice the other quirks, like the fact my superframe & cell counters etc are infeasibly low..

The router could be idle with all PCs switched off

I still think its worth doing too
 

[roseway]

I'm fascinated by this experiment. If it does end up fooling DLM, then I can see a lot of people wanting to try it.