Kitz Forum
Broadband Related => Broadband Hardware => Topic started by: rwm32 on April 08, 2008, 10:35:21 PM
-
My nice new modem is just too keen to sync high. I've got a pretty good line, but it's not quite good enough to hold 8000kbps with an acceptable error rate. I'd like to get it sync'ing around 7400-7600kbps.
I'm trying to lift the SN margin slightly to achieve this, but DTM doesn't work with the TG585v7 firmware, and I can't seem to get any changes to stick when I use telnet and the CLI to make them.
I've ftp'd the user.ini file from the modem onto my PC, edited in the following line, uploaded it back onto the modem and rebooted, in the hope that modemoption1 set to x24 will set the SN margin to around 9dB:
[ adsl.ini ]
adsl config modemoption=240000002000000006000000000000000072
but the SN margin is still 6dB after restart/re-sync, the speed is still 7800-8000, and when I telnet back onto the modem, the CLI command 'adsl debug modemoptioninfo' gives
00:00:00:00:20:00:00:00:06:00:00:00:00:00:00:00:00:72
which is the factory default setting. What has happened to the change I made?
The TG585v7 CLI is supposedly the same as the latest ST585v6 (last of the SpeedTouches).
My line stats: ADSL Max, interleaved, d/s attenuation = 36dB, target SN margin from BT = 6dB, distance from exchange = c.2km. I've had the TG585 hold 8000kbps for long enough to get a BRAS profile of 7000kbps (albeit briefly), but at that speed the FEC rate is astronomic, and the CRC rate is painfully high.
For the sake of completeness, I should add that I've got the modem's environment as clean as I can (plugged into master socket, ADSLNation filter + another filter in series, shielded modem cable, REIN sanitisation through relocation of noise sources) -- just awaiting delivery of a ferrite ring to put on the lead from the AC adaptor (and FWIW, the Thomson AC adaptor puts out hideous amounts of AM noise; fortunately it has a good long cord on the output side). So I think it's unrealistic to hope for a stable, low-error sync at 8000. Getting that speed at all with attenuation of 36dB is marginal anyway.
Sorry for the length of this post, and TIA for any help.
rwm32
-
My first thought was for you to request interleaving be enabled but I see it already is.
Do you hear noise on the phone line? I wonder if you have a "high open" fault.
-
Thank you for the suggestion, but there is no noise on the phone -- and no obvious correspondence with the ADSL error rate and phone on- or off-hook.
I don't usually fib, but the principle of covering all the bases, I did in fact report a (fictional) crackling on the voice line to BT a couple of weeks ago, so they have run a loop test recently.
The only thing I can think of that I haven't already mentioned is that we have two phone lines, one DSL enabled, one not. The voice-only line is primarily for our alarm system, but it also gets used once or twice a week for a dial-up connection into the office -- yeah, I know, but they're switching to a BB/VPN solution in a couple of months -- and very infrequently for old-fashioned fax. I've done a 17070 quiet line test on this line, as well as the ADSL one, and they are both good.
I suppose it's possible that the alarm line could be interfering with the ADSL, though I don't have a clue what could be done about it if so. The lines physically come into the house together from the pole and are wired into a double socket. The ADSL line has only 2 wires connected in the socket; the alarm line has 4 -- but if I cut the extra 2 wires in that socket and the alarm connection goes wrong, I could be looking at call-out charges from BT and the alarm company...
So that takes me back to trying to raise the SN margin to sync consistently at a slightly lower rate.
Last night I forced a re-sync and by chance got 7680 -- the lowest I've experienced on this modem. After just over 10 hours CRC errors = 81, FEC errors = 341,103. The CRC errors were more or less linear, while the FEC errors ran at around 2000/hour, apart from two bursts, in each of which >100,000 clocked up in under 2 mins. Errored seconds = 0.
By way of comparison, when the sync is at 8000, the CRC errors run into at least 100's per hour, while mega-bursts in the FEC count happen more frequently (though the base rate is still around 2000/hour). Errored seconds go up in jumps of up to 10 or so.
Ooops - another lengthy post. Sorry!
-
That's an interesting post rwm32.
I choose to turn my router (585v6) off every night and when I restart in the morning around 8.30 I notice that if I sync at around 4736 (which I did this morning) then my error count if likely to be very low throughout the day. But if I sync at over 4900 which sometimes happens then I see very high FECs especially as evening comes.
In the past I had looked at editing the modemoption string directly as you had tried - but I wasn't as brave as you and only did research and asked questions not wanting to 'upset' my sensitive exchange! The conclusion I came to was that from firmwares that don't allow the modemoption to be tweaked via telnet or DMT the string seems to be redundant.
Even when I rack up loads of FECs after a high sync I haven't lost sync but don't want the DLM to increase my target SNR if it thinks things are getting unstable. So what I sometimes do is re-sync around 3pm when the SNRM is naturally lower which will give me a lower sync with less errors being recorded - but all still within the same IP Profile.
One option for you would be to re-sync later in the day which should mean a slightly lower sync. Then if you are the type of user that leaves their router on 24/7 you should be fine until you have to re-start.
When I was looking into this last year, I remember finding someone (on a Zen forum I think) who had a router (non-Thomson) that they could use a CLI command to 'restrict the maximum data rate' which had the desired affect for them and is what I was trying to find. If I could 'force' my router to sync at no more than 4736 my IP Profile would be safe and my error rate low - I guess this is what you are after as well.
I believe your ISP can also 'limit' adsl max but I don't know much about this and how much control they have - they might come in and force you down to 2Mb! Don't know if anyone else here knows what control providers have?
In an ideal world I would put a tweakable firmware on my router - increase the target SNR 1db and look at the modemoption string to see what it was set to. Then go back to the later non-tweakable firmware and edit the user.ini so the modemoption is the same as the tweaked version and see if it takes effect or if the string is ignored. But as adsl max is far too sensitive I don't want to risk messing everything up!
Let us know how you get on - especially if you find a 'maximum data rate' type command...
-
Thank you for the suggestion, but there is no noise on the phone -- and no obvious correspondence with the ADSL error rate and phone on- or off-hook.
I don't usually fib, but the principle of covering all the bases, I did in fact report a (fictional) crackling on the voice line to BT a couple of weeks ago, so they have run a loop test recently.
The only thing I can think of that I haven't already mentioned is that we have two phone lines, one DSL enabled, one not. The voice-only line is primarily for our alarm system, but it also gets used once or twice a week for a dial-up connection into the office -- yeah, I know, but they're switching to a BB/VPN solution in a couple of months -- and very infrequently for old-fashioned fax. I've done a 17070 quiet line test on this line, as well as the ADSL one, and they are both good.
I suppose it's possible that the alarm line could be interfering with the ADSL, though I don't have a clue what could be done about it if so. The lines physically come into the house together from the pole and are wired into a double socket. The ADSL line has only 2 wires connected in the socket; the alarm line has 4 -- but if I cut the extra 2 wires in that socket and the alarm connection goes wrong, I could be looking at call-out charges from BT and the alarm company...
So that takes me back to trying to raise the SN margin to sync consistently at a slightly lower rate.
Last night I forced a re-sync and by chance got 7680 -- the lowest I've experienced on this modem. After just over 10 hours CRC errors = 81, FEC errors = 341,103. The CRC errors were more or less linear, while the FEC errors ran at around 2000/hour, apart from two bursts, in each of which >100,000 clocked up in under 2 mins. Errored seconds = 0.
By way of comparison, when the sync is at 8000, the CRC errors run into at least 100's per hour, while mega-bursts in the FEC count happen more frequently (though the base rate is still around 2000/hour). Errored seconds go up in jumps of up to 10 or so.
Ooops - another lengthy post. Sorry!
rwm32 do me a favour and leave the modem for 72hrs. This will give rambo time to set the line for the new modem. Sometimes by changing the profile on the modem it can have issues with the BT servers.
Also make sure that when running the wizard you remove the password, and if you are using the cli the you type: saveall
before you exit.
-
Many thanks for your responses.
...
In the past I had looked at editing the modemoption string directly as you had tried - but I wasn't as brave as you and only did research and asked questions not wanting to 'upset' my sensitive exchange! The conclusion I came to was that from firmwares that don't allow the modemoption to be tweaked via telnet or DMT the string seems to be redundant.
...
When I was looking into this last year, I remember finding someone (on a Zen forum I think) who had a router (non-Thomson) that they could use a CLI command to 'restrict the maximum data rate' which had the desired affect for them and is what I was trying to find. If I could 'force' my router to sync at no more than 4736 my IP Profile would be safe and my error rate low - I guess this is what you are after as well.
Interesting. I'm wondering whether what I have to do to get 'modemoption' changes to stick is use the 'upgrade' CLI command to load my modified user.ini file. The TG585 firmware is buggy -- 'restoring' a saved configuration file simply results in a return to factory defaults, so that's no good. As I posted, I tried ftp'ing a modified user.ini onto the modem and rebooting, but downloading it again after the restart shows that the mods have disappeared.
I haven't come across anything remotely resembling a 'max sync limit' command in my grapplings with the TG585v7 CLI "reference manual", however -- and as you surmise, I don't want to risk getting a 2meg limit slapped on by an over-enthusiastic CS agent from the ISP!
rwm32 do me a favour and leave the modem for 72hrs. This will give rambo time to set the line for the new modem. Sometimes by changing the profile on the modem it can have issues with the BT servers.
Also make sure that when running the wizard you remove the password, and if you are using the cli the you type: saveall
before you exit.
Yes, I'll leave it alone as you suggest, tho' my itchy fingers now want to try 'upgrade' as mentioned above....
I'm probably being obtuse, but I'm not too sure what you mean by removing the password when running the wizard -- should I simply take the password off the Administrator account?
I did remember to 'saveall'; it triggered a re-sync, so I know it registered -- but still no dice.
thanks again
rwm32
-
... Yes, I'll leave it alone as you suggest, tho' my itchy fingers now want to try 'upgrade' as mentioned above....
I'm probably being obtuse, but I'm not too sure what you mean by removing the password when running the wizard -- should I simply take the password off the Administrator account? ...
If you run the setup wizard which is advisable, it asks you for a username and password. By default the wizard sets the password to the serial number of the modem. You should remove the password and then try the DMT Tool. But again i do suggest you leave it for a few days to settle.
If you don't use the wizard i have seen some issues where by the modem will drop the connection periodically due to a session timeout.
-
Azzaka,
As you are an ISP rep, are you able to say if you can 'limit' a users connection speed to a precise figure?
TIA...
-
Yes, thanks Azzaka. That makes it clear. I hadn't appreciated the 'session timeout' danger of not using the setup wizard -- but fortunately I did in fact use it.
Sadly, DMT won't run on with 7.4.2.6 firmware on the TG585v7... it logs in OK, recognises the firmware rev, puts up a message to say it doesn't like it, then exits. Ho hum.
-
Update: after another night at 7680, the error count still looks good: CRC = 265, FEC = 417,012, uptime just over 34 hours.
I've graphed the bitloading info off the router, in the hope that those with more understanding of these things (i.e. almost everybody) might comment on whether I'm right in thinking this looks OK, with no obvious problems.
TIA
rwm32
Edit: Have just discovered STMT, which would of course have given me the same graph without any of the hassle... Doh!
[attachment deleted by admin]
-
For interest.
Slow start to the working day today.... so I stumbled across this (http://forums.whirlpool.net.au/forum-replies-archive.cfm/862527.html) thread on the Whirlpool forum, which makes me think that I may be barking up a gumtree in trying to set the modemoption registers.
-
If you are reading that like me, then that's what I meant earlier when I said I think the later non-tweakable firmwares may have made modemoptions reduntant...
Or are you pointing something else out?
-
Sorry for any confusion, b4dger -- I was more focused on getting the Oz flavour with 'gumtree' than being clear...
I should have said that the post on W'pool reinforced your view that modemoption doesn't do anything in later firmwares.
While breaking off to write this post, I notice that my line re-sync'd itself up to 8000 (from 7680) just under 2 hours ago -- completely unbidden and without any PPP disconnect. SN margin at the time was steady on 6.5dB; it's now steady on 8dB, with remarkably few errors. Have to wait and see what happens this evening -- but I'm expecting the error rate to soar...
-
Azzaka,
As you are an ISP rep, are you able to say if you can 'limit' a users connection speed to a precise figure?
TIA...
Hi Bud,
Depending on the ISP, they can request that the SNR is set to a certain value which will increase or decrease the Sync speed accordingly. One thing to note however is that the DLM should set this according to your line and also enable interleaving if needed. Hence I suggested that he leave the line for a few days.
Leo
-
Hi Azzaka,
No I didn't mean setting a target SNR, I meant having a 'speed cap' put on your connection.
I know ISPs can limit ADSL MAX but I don't know how much control they have - thought you would know...
-
They can set the limit on DSL, with 2 priviso's:
1) DSL IPStream - Can limit it, depending on the problem.
2) DSL Max - Can be limited by the ISP only if they are on LLU. If the customer is then the ISP can set a profile to limit the speed depending upon the connection and most will lower it according to the errors on the line.
I hope this helps.
Leo
-
Hmmm, sort of...
I think for this discussion we can forget about LLU as a lot of the issues are with IP Profiles ping-ponging around etc :(
"DSL IPStream - Can limit it, depending on the problem"
So can an ISP limit someone's connection to 4672kbps for example, if that helps the customer maintain a more stable connection ?
Thanks...
-
Fixed rate can be limited. If i am not wrong. BT can limit the line speed but only by changing the snr value and or limiting the profile to a fixed rate service.
-
Hmmm...
It's a max line I was interested in.
Don't worry if it's not something you deal with.
-
Thanks for that, Azzaka. Shame that BT only set the SN target in 3dB steps...
Anyway, here's an update on my line, which I was leaving alone at 7680kbps...
- Ran overnight at 7680, SN margin range 6.5 to 5.5dB
- Mid-morning yesterday: re-sync'd from peer to 8000 when the SN margin went up to7.5dB
- Mid-evening yesterday: re-sync'd to 7680 when the SN margin dropped to 5dB
- 5.00 this morning: re-sync'd from peer to 7808 for no obvious reason (SN margin range 5.5 to 6dB for previous several hours)
- mid-morning today: re-sync'd from peer to 8000 for no obvious reason (SN margin range 6 to 6.5dB)
Interpretation of this: I don't have a clue what's going on; just wish I could combine the line stability of the TG585v7 with the DG834v3's tenacity at holding sync with very low SN margins.
Having watched this passively, I have just used ftp to upload a config file (user.ini) with this line in the [ adslpots.ini ] section:
[ adslpots.ini ]
config modemoption=30000000200000000600000000000000
then, having confirmed that the new file was in fact on the modem, I went into the CLI and did
:config load flush = enabled filename = user.ini
Long, long wait. Reboot. Same old story: sync at 8000kbps with 8.5dB SN margin, and :adsl debug modemoptioninfo shows the unmodded settings. So I'm laying this one to rest; life is too short.
However, the huge bursts of 100,000's of FEC errors have not happened since I put a clip-on ferrite toroid on the DC power line into the modem yesterday - though I'm not assuming cause + effect just yet.
All the same... since it was the high error rate that was the original concern, if the ferrite does turn out to have got the errors down to an acceptable level, does it matter if the line re-syncs quietly from time to time? As there's no way the line will hold an IP profile of 7000 but doesn't look like syncing down (to coin a phrase) below the 6500 threshold, the answer is: probably not, unless this will upset the secure VPN to which we're being migrated in a few weeks' time.
Yet another long post -- sorry. But I think that's the end of the saga, at least until the VPN arrives...
Thanks, folks.
rwm32
-
Hmmm...
It's a max line I was interested in.
Don't worry if it's not something you deal with.
BT can cap the line if its DSL MAx, however, if they do then it can cause a lot more issues than not. If you have an SNR of 15db and the line still drops then check for an intermittent fault. I spoke with a colleague to get a second opinion and he agrees that you have an intermittent fault on your line, and this will be worth checking.
-
rwm32,
The only way that your line looks like it will be stable is if the SNR is manually set, or if you have the intermittent fault sorted. The line itself is stable for 2 weeks approx. on an SNR of 9, the moment the SNR is reset to 6 it drops again. The only way to set the SNR manually is if the line becomes very intermittent, and then BTW will set the SNR value accordingly.
-
Interesting you should say that, Azzaka. How we all love that phrase 'intermittent fault'!
However -- and this definitely falls into the 'famous last words' category -- the line's been OK for the last approx 24 hours at 7680kbps. No unforced resyncs; FEC count running at under 1500/hour; CRC at under 20/hr; SN margin 6dB +/- 0.5dB. What's more, the huge bursts of 100,000's/minute in the FEC count have not happened since I put the ferrite toroid on the modem's DC line.
So I'm hoping for the best. As a precaution I thought I'd keep an eye out for a v6 546 or 585 Speedtouch on e-bay -- one which I can put a DMT-compatible firmware on. Then if needs be I could try nudging up the SN target without getting it stuck at a too-high level by BTw.
Thanks, anyway.
rwm32
-
If you have an SNR of 15db and the line still drops then check for an intermittent fault. I spoke with a colleague to get a second opinion and he agrees that you have an intermittent fault on your line, and this will be worth checking.
Hi Azzaka,
You've quoted me but I think your reply may have got mixed up with someone elses???
-
...What's more, the huge bursts of 100,000's/minute in the FEC count have not happened since I put the ferrite toroid on the modem's DC line...
Hi rwm32,
Just for interest where did you get your "ferrite toroid" from, was it one of the ones stocked by Maplin?
In the past I had read about these with conflicting views. As you put yours on at the same time as the change of router - if possible could you try removing it to see if the bursts of noise return? I guess that's the only way to see if this was the actual cure - don't worry if you don't want to remove it for a test.
Thanks.
-
Yup, it was from Maplin.
In fact, I changed the router several days before putting the ferrite toroid thingy on, so it's at least semi-correlated -- though I agree that the proof would lie in removing it. Unfortunately, having investigated, I genuinely can't now tell which side is the clip and which is the hinge and am (perhaps unsurprisingly) reluctant to risk using force to find out. I've put it on a loop of the DC lead (i.e the lead goes through it twice), close to the mains adaptor end.
If my earlier posts are confusing about when the modem got swapped, it's because I had the TG585v7 up & running for a while before the Netgear DG834 .37 firmware was released. I swapped back to the DG834 for a brief trial after flashing it with the new firmware.
Hmm. Dates: I think the TG585 first went on-line in the evening of 28th March. The shielded modem lead and ADSLNation filter came on Sat 5th April, and I spent a happy time re-routing and re-positioning everything that afternoon. The ferrite thingy arrived on 10th April, having been ordered when it became apparent that the weekend's efforts, though very worthwhile in terms of improving reported SN margin and stability, had not got rid of the 100k bursts of FEC count.
I stopped 24hr monitoring on Sat 12th, though continuing during the day. The biggest FEC burst I've recorded since 10th was just over 30k in 5 mins, and the overnight (unmonitored) count hasn't exceeded 100k; the base FEC rate seems to be 500-1500 per hour.
Hope that gives you more of an idea about it all and makes up a little for not getting the definitive 'removal' test.
cheers
rwm32
-
Update 1 --- ferrite toroid:
... I genuinely can't now tell which side is the clip and which is the hinge and am (perhaps unsurprisingly) reluctant to risk using force to find out.
:'( I obviously need new specs. Son took one look and pointed out which the catch side is.
So I did a brief test: within an hour of removal, one mega-burst of 90k in under a minute in the FEC count. With the ferrite on, as I mentioned, the biggest burst was around 30k over a number of minutes. So I'm convinced: the ferrite went back on.
Update 2 --- SN Margin / DMT Tool:
Well, in fact, I put the ferrite thingy on a different DC line. Having had more unsolicited re-sync'ing (up in the morning + down in the evening), I gave in and bought an ST546v6 on e-bay, which arrived today. (Chose that model for the 6.1.4.6 firmware, which although it has the 300s repeat delay on querying the stats built in nevertheless allows DMT Tool tweaking and spectrum SN margin analysis. No WLAN, of course.)
To cut a long story short, upping the SN margin to 8.5dB prevents the modem re-sync'ing up during the day, when RF interference round here is confined to two bands, and keeps the CRC error rate down to around 2/hr in the evening, when RFI tends to make the bottom fall out of a much wider frequency spectrum. Oh, and it lets me sync at 7456, which is just enough to hang on to a 6500kbps bRAS profile. ;D
So sadly the TG585v7 is now back in its box and on the spares shelf, alongside the DG834v3... and the Voyager 210...
And that, I feel, is probably the end of the story.
rwm32
-
Thanks for the updates.
Is this the clip on Ferrite you are using?
http://www.maplin.co.uk/Module.aspx?ModuleNo=32799&criteria=ferrite&doy=17m4
And am I right in thinking you used it between the transformer and router?
Glad to hear your Speedtouch 546 is working well for you with a gentle SNR tweak - just goes to show that BT's 'system' doesn't work well for everyone. It's a shame your new v7 can't be tweaked. For the record you could still use a 585v6 with DMT if you put the right f/w on it.
Don't worry you're not the only one with a cupboard full of routers... :D
-
Yes, that's the right page at Maplin. The one I got is code N89AB (and you do only get one, not the four which the picture suggests). I've put mine on the thin DC lead between the transformer and the router; with care, it's possible to fit two thicknesses of the DC lead into the clip, which prevents it sliding around and is said by some to improve its effectiveness.
546 still looking good this a.m. (famous last words...)
-
I seem to recall reading something late last year where BTw were thinking of abolishing the fixed rate products. Though I cant remember where I read it so I may be dreaming? They still have a lot of dslams that wont support MAX so it could be a while before they do.
I do recall though that some ISPs (eg BTr) dont like putting their customers on fixed rate products
1. the ISP gets charged for moving them over (about £5 + vat) yet to max is free
2. the actual port rental is dearer on a fixed rate product PM than it is for Max (somewhere around 65p per month)
Max itself has a few fixed rate profiles:-
- Max Capped Rate Profile 500
- Max Capped Rate Profile 1000
- Max Capped Rate Profile 2000
If the line is a "cronic flapper" then the DLM can automatically put the line on one of the above profiles in order to increase stability.
Quite often the (IPStream) ISP wont even know whats happened - theres a couple of cases on this forum where this sort of thing has occurred and its sometimes hard to distinguish between a "normal fixed" rate product and a Max capped product (Both will have the 288 upstream, arent rate adaptive and wont have IP profiling).
The ISP cant specifically order a Max Capped product as part of the product set, but iirc has to instead request via the fault process to put a line on Max capped in order to help stabilise a line for eg.
It can also be requested if say for eg the ISP is moving all their residential accounts over to MAX from fixed rate.. and a user is already on a fixed rate product... the ISP knows you are on a long line and can say only get a say a possible 512k sync.. in that circumstance the ISP can request a Max capped 500 to ensure that the line doesnt get clobbered with IPprofiling.
Aside from those profiles though - no theres nothing where an IPStream ISP say could limit a line sync speed to say 4Mb.
As regards using the router to do so - yes Ive seen it myself on one of the routers Ive used. Unfortunately i cant remember which one - but at a guess most likely the SAR110 which has a Globespan chipset- therefore also looking at the likes of the Voyager 205 although dont quote me on that.
-
Some interesting observations rwm32.
Thanks for sharing with us.