Is this DLM in action?

My upstream speed with BT seems to be moving around a lot. The IP stays the same but my Billion 8800NL R2 says the link connection has been reset. I've not got the complete log for the last rest 3 days ago. Here are some stats from TB speedtest.

Date Down HTTPx6 Down HTTPx1 Upstream IP Address ISP
Thu 09/09/2021 17:15 47.67 Mbps 46.96 Mbps 7.41 Mbps 86.139.252.XXX BT
Fri 03/09/2021 16:05 46.20 Mbps 45.44 Mbps 3.80 Mbps 86.139.252.XXX BT
Tue 24/08/2021 07:31 45.30 Mbps 44.85 Mbps 7.11 Mbps 86.139.252.XXX BT
Mon 23/08/2021 07:56 45.41 Mbps 44.26 Mbps 7.35 Mbps 86.190.195.YYY BT
Sun 22/08/2021 13:17 47.36 Mbps 48.35 Mbps 8.26 Mbps 86.139.254.ZZ BT

Thanks

Paul

We would need to see the line stats from the Billion.

It wouldn't even require line stats from each of the disconnections.
Just a single set of stats from the Billion would be enough to tell if the upstream was under any DLM limitations or of it was just a variable sync rate.

It's impossible to tell from a speed test if it's DLM related or not.

Thanks j0hn83

These are the stats

Model Name BiPAC 8800NL R2
Host Name home.gateway
System Up-Time 30D 16H 10M 35S
Date/Time Fri Sep 10 19:49:48 2021
Software Version 2.52.d15


Line Rate - Upstream (Kbps) 8595
Line Rate - Downstream (Kbps) 53451
Default Gateway / IPv4 Address ppp1.1 (DSL) / 86.139.252.xxx
Connection Time 4 Day(s) 19:14:25


Downstream Upstream
Line Coding (Trellis) On On
SNR Margin (dB) 3.3 6.1
Attenuation (dB) 21.4 0.0
Output Power (dBm) 12.3 6.3
Attainable Rate (Kbps) 54725 8595

Rate (Kbps) 53451 8595

B (# of bytes in Mux Data Frame) 227 237
M (# of Mux Data Frames in an RS codeword) 1 1
T (# of Mux Data Frames in an OH sub-frame) 0 33
R (# of redundancy bytes in the RS codeword) 10 16
S (# of data symbols over which the RS code word spans) 0.1357 0.8793
L (# of bits transmitted in each data symbol) 14034 2311
D (interleaver depth) 4 1
I (interleaver block size in bytes) 238 127
N (RS codeword size) 238 254
Delay (msec) 0 0
INP (DMT symbol) 51.00 0.00

OH Frames 0 0
OH Frame Errors 19425 64
RS Words 3591931664 1886902782
RS Correctable Errors 235187720 418
RS Uncorrectable Errors 0 0

HEC Errors 0 0
OCD Errors 0 0
LCD Errors 0 0
Total Cells 3933999135 0
Data Cells 207320472 0
Bit Errors 0 0

Total ES 361 59
Total SES 269 0
Total UAS 401 136

Apologies for the formatting.

Does variable sync rate have a special meaning? 3.80 to 7.41 seems a lot of variance to me.

Regards

Paul

That looks quite a decent connection to me. 600-800 metres from the phone cabinet I expect, and add the distance between the FTTC and phone cabinets.

Given the SNR Margins, the interleave depth and the Delay (msec) I'd say DLM reckons it's a stable line. You are not getting sync speed changes.

Where are you seeing the term "variable sync rate"?

In reply to a post by BarkingMad:

3.80 to 7.41 seems a lot of variance to me.

The 3.80 looks like an outlier which could have been influenced by something outside your control or something within your own network. Outside your control could be glitches anywhere in the network. Within your control the most common cause for an outlier like that is something else using your bandwidth at the same time as the speed test. Was there anything else connected to the network apart from the machine doing the speedtest when the test was run? Anything which has any sort of automated backup to the Cloud or automatic download of updates could have caused a drop if that was running at the same time as the speed test. Was the test run from a machine connected by ethernet cable or WiFi? WiFi interference can also be a problem.

Take out the outlier and as Bob (Pluralist) says the line looks stable for both upward and downward connections. If DLM does kick in it will cause a disconnection and re-connect which re-sets the Connection Time shown in the stats so you can always check if you think you might have had a re-set.

Edited by GonePostal (Sat 11-Sep-21 09:25:17)

@pluralist,

It's around 600 metres to the cabinet. My connection is decent (currently) but sometimes my upload line rate drops. I don't have any saved evidence of the drop, apart from my speed test results - which is not ideal and I can see this is causing confusion. Sorry. I did confirm the line rate in the Billion and they followed the speedtest result dip.

I'm questioning why the upload line rate dips.

The "variable sync rate" term was a comment made by j0hn83

@GonePostal,

Thanks for your reply. I have shown speed test results because I have no other evidence of the line rate being lower. This is not ideal. I have caused confusion. Sorry.

When the line rate rate is lower, the speedtest results are lower. I did check the line rate in the router but I didn't save the evidence.

I'd like to know why my upload line rate dips.

Regards

Paul

The thinkbroadband BQM is an excellent tool for monitoring your connection.

Your Billion router supports it, but you possibly have a dynamic IP address seeing as you are with BT. In which case you should consider a Dynamic DNS service (DDNS) as explained if you click the link on that page for the complete BQM guide.

For help on DDNS you can wait and see if anyone posts here about it, as I have never needed to use one. AIUI it is very simple but there is a charge by the service.

In reply to a post by pluralist:

For help on DDNS you can wait and see if anyone posts here about it, as I have never needed to use one. AIUI it is very simple but there is a charge by the service.

First action is to find out which DDNS services are supported by the Billion router. Then either post the list here for a recommendation, or investigate each one yourself.

Variable upload line rate can point to a line fault, as this is normally affected the most. But, I wouldn't expect it to return to normal levels at any point, more a slower maximum speed (whilst the fault is present) with lower values on some resyncs. I wouldn't worry too much about the error counts, as such (particularly FECs). Just check to see if the line rate changes after a resync. I have had a BT Smart Hub 2 installed for a long time now, just because I used to get obsessed about error counts (the error counts are not visible with the BT SH2, and for a good reason).

Edited by Grimers (Sun 12-Sep-21 20:22:36)

I have had BQM monitoring my line since 24 Aug when the last reset occurred that changed the IP. I've downloaded the XML data and merged (roughly) with my speedtest results

Tue 24/08/2021 07:31 45.30 Mbps 44.85 Mbps 7.11 Mbps 86.139.252.XXX BT

<record timestamp="2021-08-24T06:31:40Z" sent-polls="46" lost-polls="2" min-latency-ns="6951000" ave-latency-ns="7279000" max-latency-ns="7641000" score="201"/>
<record timestamp="2021-08-24T10:53:20Z" sent-polls="100" lost-polls="1" min-latency-ns="6876000" ave-latency-ns="11350000" max-latency-ns="91070000" score="201"/>

<record timestamp="2021-08-27T06:45:00Z" sent-polls="100" lost-polls="1" min-latency-ns="6817000" ave-latency-ns="7700000" max-latency-ns="42560000" score="201"/>

It looks like the line reset at 29 Aug 00:51 based on the number of lost polls, and I'm guessing this is when the up line rate dropped as well.

<record timestamp="2021-08-29T00:51:40Z" sent-polls="100" lost-polls="39" min-latency-ns="6870000" ave-latency-ns="7259000" max-latency-ns="7609000" score="301"/>
<record timestamp="2021-08-29T00:53:20Z" sent-polls="100" lost-polls="29" min-latency-ns="6990000" ave-latency-ns="7393000" max-latency-ns="7880000" score="301"/>

Fri 03/09/2021 16:05 46.20 Mbps 45.44 Mbps 3.80 Mbps 86.139.252.XXX BT

<record timestamp="2021-09-03T15:33:20Z" sent-polls="100" lost-polls="2" min-latency-ns="6945000" ave-latency-ns="16070000" max-latency-ns="88630000" score="201"/>
<record timestamp="2021-09-03T16:16:40Z" sent-polls="100" lost-polls="1" min-latency-ns="6905000" ave-latency-ns="13840000" max-latency-ns="91250000" score="201"/>
<record timestamp="2021-09-03T23:51:40Z" sent-polls="100" lost-polls="1" min-latency-ns="6894000" ave-latency-ns="7443000" max-latency-ns="10630000" score="201"/>

Another reset occurs on 5 Sep and the up line rate increases.

<record timestamp="2021-09-05T23:33:20Z" sent-polls="100" lost-polls="42" min-latency-ns="6855000" ave-latency-ns="7420000" max-latency-ns="11450000" score="301"/>
<record timestamp="2021-09-05T23:35:00Z" sent-polls="100" lost-polls="25" min-latency-ns="6892000" ave-latency-ns="7465000" max-latency-ns="20280000" score="301"/>

Thu 09/09/2021 17:15 47.67 Mbps 46.96 Mbps 7.41 Mbps 86.139.252.XXX BT

Is there anything else to look at in the BQM data?

You really need to be logging the line rates, not BQM data, ideally.

Indeed it is. BQM is polling the link latency at Layer 3 (Network) whereas DLM is operating at a far more basic level down at Layer 1 (Physical).

I've got dslstats monitoring the line. It may capture info to educate the reasons for the next reset. Sods law says this won't happen for weeks.

The low upload rate isn't an issue as such. Just like to know why it happens.

Have you got a phone? If so, is there noise on it?

Yep. Ahh, takes me back to my CompTIA days... The OSI Model...

BT quiet line test is quiet.

I think I need t wait until the next reset. Hopefully the up rate will drop and dslstats will give a clue as to what was happening.

The line did a resync at approx 0030 last night. I've got a new IP and my rates have gone up. These are the highest speeds I have seen. Machine also applied MS patch Tuesday updates so dslstat was not running this morning. Looks like reset was performed before patch reboot so dslstats logs may be preserved. Perhaps it is DLM?

Downstream Upstream
Line Coding (Trellis) On On
SNR Margin (dB) 2.4 5.8
Attenuation (dB) 21.7 0.0
Output Power (dBm) 11.9 7.6
Attainable Rate (Kbps) 54044 10580
Rate (Kbps) 54997 9998
B (# of bytes in Mux Data Frame) 227 79
M (# of Mux Data Frames in an RS codeword) 1 1
T (# of Mux Data Frames in an OH sub-frame) 0 64
R (# of redundancy bytes in the RS codeword) 10 8
S (# of data symbols over which the RS code word spans) 0.1319 0.2542
L (# of bits transmitted in each data symbol) 14440 2769
D (interleaver depth) 4 1
I (interleaver block size in bytes) 238 88
N (RS codeword size) 238 88
Delay (msec) 0 0
INP (DMT symbol) 57.00 0.00
OH Frames 0 0
OH Frame Errors 20008 75
RS Words 766058928 398822278
RS Correctable Errors 23933053 1
RS Uncorrectable Errors 0 0
HEC Errors 0 0
OCD Errors 0 0
LCD Errors 0 0
Total Cells 2667742865 0
Data Cells 2964984 0
Bit Errors 0 0
Total ES 372 70
Total SES 280 0
Total UAS 758 483

Regards

It looks very much like your DSLAM rebooted last night.

You connected before other lines on the cabinet.
As you connected before other lines there is less crosstalk so you sync higher.
When the other lines connected a minute or so later this reduces your SNR Margin below the target.

Next time your line resyncs it should return to its usual rate.

Your line was already on a 3dB SNRM target on the downstream and 6dB on the upstream.
That's already the optimum DLM line profile.
None of the changes in sync posted in this thread have been DLM related.

Thanks j0hn83,

Could you tell me how you deduced your response from the line stats? Or perhaps its more knowledge / experience?

Besides the SNR, Atten, Output Power, Attain Rate and Rate I can see differences in following

B upstream fro 237 to 79
T upstream from 33 to 64
R upstream from 16 to 8
S uptream from 0.2542 to 0.8793
I upsteam from 127 to 88
N upstream from 254 to 88
INP downstream from 51 to 57

I'm hoping my next reset will show a upstream line rate of around 5000 Kbps because this would be related to my original post.

According to the BT Availability Checker I'm currently within the predicted speeds

VDSL Range A (Clean) 57.9 41.5 11.3 7.4
VDSL Range B (Impacted) 56.1 35 11 6.9

Regards

And from those latest stats you are on the 55/10 Openreach product.

Your DLM profile has been the same throughout.

Downstream 3dB Retransmission High - Upstream 6dB Error Protection Off.

The small changes in the upstream stats you quoted is just the amount of RS/FEC used on the upstream.
They don't affect the upstream sync speed.

Login in via Telnet and running "xdslcmd info --stats" will give a bit more detail, particularly the Retx/G.INP framing and error counters.

No idea what caused the low upstream sync you saw in your original post but it was very unlikely to be DLM related. Much more likely to be a line fault or an external factor affecting the line (interference, a crosstalker, etc).

A resync between midnight and 2am resulting in an increase in sync on both the downstream and upstream, accompanied by a drop in SNRM, is almost always the DSLAM rebooting. Sync speeds go back to normal on the next resync.

Thanks j0hn83, pluralist

The line re-synched last night. Downstream has dropped a little but upstream hasn't changed. These are the stats. I struggled to see or make sense of the the Retx/G.INP counters. I xdslcmd wasn't available through telnet so I have shown adsl output

adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 10643 Kbps, Downstream rate = 51144 Kbps
Bearer: 0, Upstream rate = 9998 Kbps, Downstream rate = 51211 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 3.9 6.4
Attn(dB): 21.7 0.0
Pwr(dBm): 12.1 7.6

VDSL2 framing
Bearer 0
MSGc: -6 42
B: 227 79
M: 1 1
T: 0 64
R: 10 8
S: 0.1416 0.2542
L: 13446 2769
D: 4 1
I: 238 88
N: 238 88
Q: 4 0
V: 0 0
RxQueue: 125 0
TxQueue: 25 0
G.INP Framing: 18 0
G.INP lookback: 25 0
RRC bits: 0 24
Bearer 1
MSGc: 122 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 8.0000 0.0000
L: 32 0
D: 1 0
I: 32 0
N: 32 0
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0

Counters
Bearer 0
OHF: 0 2065527
OHFErr: 0 2
RS: 709246056 396539124
RSCorr: 6087906 2
RSUnCorr: 0 0
Bearer 1
OHF: 1569307 0
OHFErr: 0 0
RS: 12553961 0
RSCorr: 2453 0
RSUnCorr: 0 0

Retransmit Counters
rtx_tx: 12537 0
rtx_c: 12442 0
rtx_uc: 0 0

G.INP Counters
LEFTRS: 0 0
minEFTR: 51167 0
errFreeBits: 3223409792 0

Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 2482283815 0
Data Cells: 4406788 0
Drop Cells: 0
Bit Errors: 0 0

Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0

ES: 5254 155
SES: 317 0
UAS: 849 543
AS: 25207

Bearer 0
INP: 56.00 0.00
INPRein: 1.00 0.00
delay: 0 0
PER: 0.00 12.25
OR: 0.01 31.34
AgR: 51323.68 10029.91

Bearer 1
INP: 2.00 0.00
INPRein: 2.00 0.00
delay: 0 0
PER: 16.06 0.01
OR: 63.75 0.01
AgR: 63.75 0.01

Bitswap: 13920/14682 772/775

Total time = 46 days 4 hours 47 min 37 sec
FEC: 3456684499 5874
CRC: 32287 172
ES: 5254 155
SES: 317 0
UAS: 849 543
LOS: 7 0
LOF: 27 0
LOM: 3 0
Retr: 7
FailedRetr: 0
FailedFastRetr: 0
Latest 15 minutes time = 2 min 37 sec
FEC: 38586 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
FailedRetr: 0
FailedFastRetr: 0
Previous 15 minutes time = 15 min 0 sec
FEC: 205249 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: N/A
FailedRetr: N/A
FailedFastRetr: N/A
Latest 1 day time = 4 hours 47 min 37 sec
FEC: 4176796 2
CRC: 0 2
ES: 0 2
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
FailedRetr: 0
FailedFastRetr: 0
Previous 1 day time = 24 hours 0 sec
FEC: 176827717 24
CRC: 11965 9
ES: 4703 9
SES: 34 0
UAS: 91 60
LOS: 2 0
LOF: 9 0
LOM: 0 0
Retr: 2
FailedRetr: 0
FailedFastRetr: 0
Since Link time = 7 hours 5 sec
FEC: 6087906 2
CRC: 0 2
ES: 0 2
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
FailedRetr: 0
FailedFastRetr: 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
>

That looks like DLM wasn't happy with the error rates, (neither was I from your last set of stats but they needed assessing over time so I didn't comment), so it raised the downstream SNR(Margin) to 4db.

With luck it will stabilise there. Watch for it going down over time however, as that could presage a further adjustment. It is normal for it to fluctuate by 0.2 or 0.3 over 24 hours, higher at night.

Openreach has told ISPs new ruling on DLM resetted:

They will not resetted DLM remotely if the line still drop or isn't stable for the last ten days! They will accept DLM resetted if the line was banded and no drop out with remain stable for 10 days or more.

Edited by adslmax (Sun 26-Sep-21 11:52:16)

Thank you pluralist,

Just had a resync just before 1pm. On lunch break so didn't notice it. Not much has changed. I'm very happy with the current rates.

adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 10715 Kbps, Downstream rate = 50991 Kbps
Bearer: 0, Upstream rate = 9995 Kbps, Downstream rate = 51577 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 3.6 6.1
Attn(dB): 21.7 0.0
Pwr(dBm): 12.1 7.6

VDSL2 framing
Bearer 0
MSGc: -6 42
B: 227 79
M: 1 1
T: 0 64
R: 10 6
S: 0.1406 0.2543
L: 13542 2705
D: 4 1
I: 238 86
N: 238 86
Q: 4 0
V: 0 0
RxQueue: 126 0
TxQueue: 21 0
G.INP Framing: 18 0
G.INP lookback: 21 0
RRC bits: 0 24
Bearer 1
MSGc: 122 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 8.0000 0.0000
L: 32 0
D: 1 0
I: 32 0
N: 32 0
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0

Counters
Bearer 0
OHF: 0 295816
OHFErr: 0 0
RS: 102303356 56787199
RSCorr: 910359 0
RSUnCorr: 0 0
Bearer 1
OHF: 224809 0
OHFErr: 0 0
RS: 1797976 0
RSCorr: 773 0
RSUnCorr: 0 0

Retransmit Counters
rtx_tx: 3168 0
rtx_c: 3139 0
rtx_uc: 0 0

G.INP Counters
LEFTRS: 0 0
minEFTR: 51560 0
errFreeBits: 3306090983 0

Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 358116343 0
Data Cells: 3766438 0
Drop Cells: 0
Bit Errors: 0 0

Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0

ES: 5266 165
SES: 327 0
UAS: 1078 762
AS: 3611

Bearer 0
INP: 58.00 0.00
INPRein: 1.00 0.00
delay: 0 0
PER: 0.00 12.25
OR: 0.01 31.33
AgR: 51690.11 10025.95

Bearer 1
INP: 2.00 0.00
INPRein: 2.00 0.00
delay: 0 0
PER: 16.06 0.01
OR: 63.75 0.01
AgR: 63.75 0.01

Bitswap: 932/960 67/67

Total time = 47 days 10 hours 15 min 47 sec
FEC: 3493994237 5910
CRC: 32827 182
ES: 5266 165
SES: 327 0
UAS: 1078 762
LOS: 8 0
LOF: 30 0
LOM: 3 0
Retr: 8
FailedRetr: 0
FailedFastRetr: 0
Latest 15 minutes time = 47 sec
FEC: 12767 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
FailedRetr: 0
FailedFastRetr: 0
Previous 15 minutes time = 15 min 0 sec
FEC: 233653 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: N/A
FailedRetr: N/A
FailedFastRetr: N/A
Latest 1 day time = 10 hours 15 min 47 sec
FEC: 12426309 6
CRC: 536 1
ES: 10 1
SES: 10 0
UAS: 229 219
LOS: 1 0
LOF: 3 0
LOM: 0 0
Retr: 1
FailedRetr: 0
FailedFastRetr: 0
Previous 1 day time = 24 hours 0 sec
FEC: 29060225 32
CRC: 4 11
ES: 2 11
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
FailedRetr: 0
FailedFastRetr: 0
Since Link time = 1 hours 11 sec
FEC: 910359 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
FailedRetr: 0
FailedFastRetr: 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
>

Another resync last night...but not much change.

However, Billion seems to be showing conflicting info....

Summary page says:
Line Rate - Upstream (Kbps) 9995
Line Rate - Downstream (Kbps) 51577
Default Gateway / IPv4 Address ppp1.1 (DSL) / 81.147.xxx.yyy
Connection Time 06:15:02

Logs support connection time

Sep 30 01:33:55 daemon crit syslog: Received valid IP address from server. Connection UP.

But the DSLstats stats page shows :

Status: Showtime
Uptime: 2 days 18 hours 51 min 26 sec

And this is from the --stats command

Since Link time = 2 days 18 hours 51 min 25 sec
FEC: 114522837 57
CRC: 0 19
ES: 0 19
SES: 0 0
UAS: 0 0

Perhaps it was a different type of resync?

The uptime there is the time the router has been powered up, (possibly the time since the connection to the exchange), and the connection time is how long the PPP session has been up. The PPP uptime being reset at each re-sync.

The PPP is the working connection between your router and the ISP's gateway.

My line is stable and currently achieving speeds around 50/10 which matches my BT package

Thanks for all those that gave advice.

Happy new year

Paul