Print

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

[Weaver]

I think I've mentioned before that my old faithful Netgear DG834v3 has a habit of connecting to BT Wholsale initially - after (re)boot - with a really high upstream sync rate, but less than a day later it will reconnect with a much lower, more plausible-looking number, and then stick with that long term.

The 'really high' first time US sync rate is typically well above 448k, the ceiling [?] that you can can rise by paying extra for BTW IPstream Max _Premium_ - as here. The other day 544k was the initial US figure and this dropped to something like 352k after a reconnect (while powered up and running all the time, not rebooted) which mysteriously happened less than 24 hours afterwards.

US SNR margin is 5-7dB typically.

I wonder what on earth that might be all about?

It's hardly a problem, and doesn't cause any apparent problems. Assuming it's just a quirk in [who-knows-what?].

[roseway]

It's pretty unusual for the upstream connection speed to be anything other than 448 kbps unless you're on the premium service which provides 832 kbps. So your figures suggest to me that you're on the premium service but your line is affected by low frequency interference which limits the upstream speed.

I presume that you've done all the necessary things to optimise your own setup (if you haven't, then I suggest that you do). Any audible noise on the phone would indicate a possible line fault, which you should report as a voice fault. And finally, I suppose that the rather old router could be the cause, so it would be worth trying a different one if you can.

[Weaver]

@roseway
> unless you're on the premium service which provides 832 kbps.

Which I am (an extra £10)

DSL modem again this morning has picked 544k US sync rate: at 7dB SNRM US, 15.5dB attn US. (And DS: 62dB attn, sync 2496k, 5-6dB SNRM.)

It's the high US numbers that I find suprising, not the low ones. But I suppose 15.5 dB attn US isn't _so_ bad so it makes sense what you say about LF interference, if that's sporadic perhaps. It seems LF doesn't mind propagating down this ~6km long line, as you'd expect. So an LF noise source

I initially thought maybe it's ripple in the DSL router's own cheap PSU, but that wouldn't come and go, surely, as the DC brick into the DSL router is on a mains filtering unit [Belkin PureAV range], into a UPS.

Perhaps its mains nearer civilisation?

[Weaver]

In fact, I should have asked if the sync rate is really "too high" for 15dB attn, rather than just assuming. Maybe that's just as it should be, and as Roseway suggests something is mucking things up, but you have to wait a while for an episode of interference.

One interesting thing is an insight into the workings of BTW DLM - the _US_ 'instability' doesn't affect the _DS_ IP profile or sync rate, which is a very good thing indeed.

US sync will probably drop back down from the current 544k to ~350k or even ~250k later on today, and I think the US SNRM will end up nearer 9dB from experience.

[Weaver]

One thing I don't understand, is why the extra low BINS aren't getting used. Which bins are the 'extra' ones that get you up to 832k US sync as opposed to 448k?

It seems criminal not to make them available to all users. Cynical marketing I suppose, but that's not good.

[roseway]

To try to answer your last question first, there aren't really any unused low frequency tones which could be used. If you look at Kitz's table of ADSL tones and the explanations which follow, you'll see that all tones are accounted for, even those which aren't used for data transmission.

Concerning your upstream attenuation, this is a very unlikely figure when the downstream attenuation is 62 dB. I would say that this is almost certainly misreporting by the router, and may well be the result of the LF interference which I postulated. If you're happy that your own setup is as good as it can be, then I would certainly consider trying a different router. A 2-Wire 2700HG might be a good choice on such a line.

[waltergmw]

@ Weaver,

Are the extra low bins not the first 3 kHz used for the voice part of the line ?

Kind regards,
Walter

[Weaver]

> Are the extra low bins not the first 3 kHz used for the voice part of the line ?

I'll have to dig around in one of my ADSL tomes. In that case I wonder if phones might make a difference because of inaccurate frequency division, possibly under varying complex load, or else straight audio band interference from the phone, as that would explain why you can get away with the initial high US sync for a while, until the first phone call say half a day later.

[Weaver]

And in fact mid morning, it dropped US sync down to 352k (from 544k).


Sanity check : It's at 7dB US SNRM right now a few hours later, so it certainly hasn't been using a target SNR margin that is way too high (over-conservative). Nor does it show an initial figure below 6dB US target SNRM ever.


Meanwhile DS sync rate has stayed roughly where it was.

Just very odd. I'm thinking it's either a (i) change in the general environmental noise spectrum, or (ii) it's to do with phones, or (iii) it's a quirk of the DG834v3. It doesn't happen with lines capped at 448k US.

I can check (ii) out by removing the phone for a day. I can also try a different microfilter, one of the two ADSL Nation models instead of the BT 'Pressac' type I'm fond of (clarity.it).

But of the three (i) makes the most sense to me now, as for (ii) and (iii) I would assume I would see a rather higher US SNRM. The US SNR doesn't change when I call say the speaking clock, nor when I remove the phone.

[kitz]

Would be a good idea if you could get a graph of your bit loading, so see how the line is being utilised + loaded.

If certain upstream tones arent being utilised it would suggest some sort of interference at those tones, but it could just be down to length of the line...  which in your case is likely.

It should be borne in mind, that many of the upstream tones are 'capped' to prevent cross-talk between upstream/downstream on Annex_A and Annex_M., using something called power cut back.   Its also applied to some of the lower upstream channels to prevent x-talk between dsl and telephony.   This is why on a perfect line you will often see an inverted 'U' shape on the upstream bit loading graph... and also on the lower downstream tones.

Upstream and downstream tones are kept separate.  By going on premium, it doesnt give you access to more tones, it just increases a cap set on the BTw network which allows you to make use of more upstream speed - if your line can handle it. 
Its only when you go utilise Annex_M that the upstream tones are shifted., by taking away some of the "usual downstream" ones.

Youre  pushing your upstream speed to the maximum now, which is why its seems a bit more unsettled.
Theres probably far more bit swapping going on..  and over time its probable that because of the bitswapping more tones perhaps are being marked by your router as unusable until you do a full resync at a time of the day when the line is at its optimum.

If it continues then it may be that the line may work best capped at 448 upstream.  Just like some lines have to have their downstream capped at say 500k or 1Mb to maintain stability.
Even the LLU providers have this profile because some longer lines do start to struggle if you push the upstream too high so they will cap the upstream to around 448 to prevent this.

Annex_M is not recommended on long lines for a similar reason and you will sometimes find that the amount of increased upstream gained is less than what is taken away from the downstream.

[Weaver]

> By going on premium, it doesnt give you access to more tones, it just increases a cap set on the BTw network

I assumed that it couldn't give you more than a certain number of tones in the sense that the downstream-upstream split is in a different place, as that would cause crosstalk problems with other peoples' DS.

I'll post up the bits per bin stats thing.

[Weaver]

This is an "after" - after US sync rate drops to something more modest..

My favourite, faithful DG834v3

# cat avsar_bit_allocation_table

AR7 DSL Modem US Bit Allocation:
00 00 00 00 00 00 00 06 04 02 04 04 04 05 05 05
05 05 06 06 05 05 06 06 07 07 07 07 07 05 05 00

AR7 DSL Modem DS Bit Allocation:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 07 08 09 0a 0a 0b 0b 0b 0b 0b 0a 0a 0b
0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a
00 0a 09 09 09 09 09 09 09 09 09 09 09 09 09 09
09 08 08 09 09 08 08 08 08 08 07 05 07 07 07 07
07 07 07 07 07 07 07 07 07 06 06 06 05 05 05 05
05 05 05 05 05 05 05 04 05 04 04 04 04 04 04 04
04 04 04 02 02 02 02 02 00 00 02 02 00 02 02 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
#

# cat avsar_modem_stats

AR7 DSL Modem Statistics:
--------------------------------
[DSL Modem Stats]
        US Connection Rate:     352     DS Connection Rate:     2496
        DS Line Attenuation:    62      DS Margin:              5
        US Line Attenuation:    31      US Margin:              7
        US Payload :            33468336        DS Payload:             130396656
        US Superframe Cnt :     8128206 DS Superframe Cnt:      8128206
        US Transmit Power :     0       DS Transmit Power:      0
        LOS errors:             0       SEF errors:             0
        Errored Seconds:        0       Severely Err Secs:      0
        Frame mode:             3       Max Frame mode:         0
        Trained Path:           1       US Peak Cell Rate:      830
        Trained Mode:           3       Selected Mode:          1
        ATUC Vendor Code:       54535443        ATUC Revision:  2
        Hybrid Selected:        3       Trellis:                1
        Showtime Count:         2       DS Max Attainable Bit Rate: 2496 kbps
        BitSwap:                1       US Max Attainable Bit Rate:     n/a
        Annex:                  AnxA    psd_mask_qualifier: 0x0000
        Power Management Status: L0     DS HLINSC: 0
        US ACTPSD:              -345    DS ACTPSD: -355
        Total init. errors:     0       Total init. timeouts: 0
        Showtime init. errors:  0       Showtime init. timeouts: 0
        Last showtime init. errors: 0   Last showtime init. timeouts: 0
        ATUC ghsVid:  b5 00 54 53 54 43 00 00
        T1413Vid: 00 00         T1413Rev: 00            VendorRev: 00
        ATUR ghsVid:  b5 00 54 53 54 43 00 00
        T1413Vid: 00 00 T1413Rev: 00    VendorRev: 00

        [Upstream (TX) Interleave path]
        CRC:    25      FEC:    26588   NCD:    0
        LCD:    0       HEC:    1700

        [Downstream (RX) Interleave path]
        CRC:    46      FEC:    1177837 NCD:    0
        LCD:    0       HEC:    0

        [Upstream (TX) Fast path]
        CRC:    0       FEC:    0       NCD:    1
        LCD:    0       HEC:    0

        [Downstream (RX) Fast path]
        CRC:    0       FEC:    0       NCD:    0
        LCD:    0       HEC:    0

[ATM Stats]
        [Upstream/TX]
        Good Cell Cnt:  697257
        Idle Cell Cnt:  114017801

        Tx Packets Dropped Count:       0
        Tx Bad Packets Count:   2

        [Downstream/RX)]
        Good Cell Cnt:  2716597
        Idle Cell Cnt:  810717232
        Bad Hec Cell Cnt:       165
        Overflow Dropped Cell Cnt:      0
        Rx Packets Dropped Count:       0
        Rx Bad Packets Count:   0


[SAR AAL5 Stats]
        Tx PDU's:       265380
        Rx PDU's:       304105
        Tx Total Bytes: 24517338
        Rx Total Bytes: 143642039
        Tx Total Error Counts:  0
        Rx Total Error Counts:  0


[OAM Stats]
        Near End F5 Loop Back Count:    0
        Near End F4 Loop Back Count:    0
        Far End F5 Loop Back Count:     0
        Far End F4 Loop Back Count:     0
        SAR OAM Ping Response Drop Count=0
#

[Weaver]

Doing things in backwards order - That was the "after" and I'll post a "before" later on, next time I happen to see a "high" US sync after booting the router.

[Weaver]

Have failed to actually caputre stats from a "before".

This morning was a perfect example, a high US sync of 576k changed to a more modest (will be long-term) US 384k (was accompanied by an all-time record DS sync rate of 2592k [!] at 4dB DS SNRM now, very sunny, dry).

But the last few attempts at telnetting into the old favourite that is the DG834v3, after the todo=debug trick, the telnet session succeeds, allows you to type in a command or two then the session freezes. It's as if there's some timer. Rebooted, tried again, still no joy. Maybe it's something to do with having to login or must not log into Web UI to supply credentials. Telnetting in worked last week, so must have lost the magic knack at present.

[kitz]

Aside from one upstream tone, cant particularly see anything that would be causing you any problems.  That could have been bitswapped with the tone 2 before it though, so it looks normalish for a long line.  That one tone though would make negligible difference to the overall speed.
You can see an inverted U shape even on that line which will be power cut back via a psd mask thats applied to all lines.

I really cant see anything there that would be causing problems aside from low SNR most likely due to line length.
Longer lines are more susceptible to fluctuations in SNR.  Is there any pattern to time of day.  Could it be the usual 'worse in the evenings' scenario?