Anyone Using an Asus DSL-AC68U

BoBeB · 3 Apr 2015 at 20:36

I can add my story to the tale of woes experienced with the DSL-AC68U.
Zen Internet via the BT Openreach modem to ASA 5505, connected for weeks without any drop outs.
Plug in the DSL-AC68U and after the initial sync giving me same speed within a couple of days I`ve lost 10mbps download speed / synch speed.
I`ve Tried the following.
- Set "Stability Adjustment (VDSL)" to 9 dB.
- Set "Rx AGC GAIN Adjustment (VDSL)" to Stable.
- updating firmware and even put the beta firmware as recomended by Paul Lee@ASUS.
-ESNP - Enhanced Sudden Noise Protection (VDSL). Set to Stable to enable it, and with following settings configured.
- Set "Stability Adjustment (VDSL)" to 12 dB.
- Set "Rx AGC GAIN Adjustment (VDSL)" to Stable.
It was after setting the ESNP where I noticed I had changed from fastpath to Interleaved, my max attainable download dropped to 40mbps from 60mbps, my ping increased to sites and my son started complaining about Fifa 15 being laggy online...
I`ve gone back to the BT openreach box on the wall and enabled dual wan mode until this can get sorted, or I lose patience and contact Amazon and tell them that the box is not fit for purpose.

Ixel · 3 Apr 2015 at 21:00

From previous firmware before ESNP, DLM might've seen too many errors or re-syncs in a timeframe and just coincidentally happened to end up on interleaving.

My ESNP experience, when set as stable, is positive. No rediculously high FEC errors anymore, and my brief test on forcing fastpath resulted in similar results to the HG612. I'm just waiting for DLM to return me to fastpath as I'm now within the thresholds defined by the DLM profile, my caution counter is probably quite high at the moment. Once fastpath returns my pings will drop from around 18ms to 8ms and the downstream sync rate should ideally be on the 80Mbps limit.

When G.INP arrives it will very likely eliminate virtually all CRC errors on the line, BT are supposed to now be in the process of rolling it out to the ECI cabinets over the next three months.

Final note, with ESNP you shouldn't need to have stability adjustment at something high such as 12 dB, at least I didn't here anyway, maybe your situation is somehow different.

bitsNbobs · 4 Apr 2015 at 04:15

ViRuS2k said:
0.7 is the norm and i have been just as low as that for months and stayed on fastpath
also his max rate is over 80mb down and he has some snr to spare so to me the only thing that can happen to his DLM is a kick up to 79999 sync on download.

Down rates do not enter into the equation on UPSTREAM attenuation.
0.7db is also not normal, at best that figure should be around 2-3db at its lowest you may even get around 1.5db if lucky. (which looking at your last couple of posts of stats is what your stats state for the UPSTREAM ATTENUATION). Im also curious now if this is an LINE attenuation figure or a SIGNAL attenuation figure thats being reported. As in some of your stats its fluctuated quite considerably and you have a good line, it should be reporting LINE attenuation rather than SIGNAL. (SIGNAL would be an ongoing constantly or as near as constantly changing figure).

HaydnExport said:
attenuation is noise on the line , the lower the better, mine is 0.1

NO just NO. 0.1db is far from normal, something is wrong be it either the device reporting incorrectly or general setup if you are seeing figures consistently below 1db. Even more so when the SNR figures are a larger number. To get a 0.1db figure your copper bit of the line would have to have basically ZERO resistance, attenuation is a loss figure..... Sorry but the laws of physics forbid it being 0db, you wouldnt get that even with the cabinet in your house. Yes it being as near to 0db is good to a degree, is 0.1db or even 0.7db in any way likely to be accurate, NO IMPOSSIBLE.

This could also explain the now well discussed FEC abnormality some still see IF THIS FIGURE IS SIGNAL RATHER THAN LINE ATTENUATION.
Signal RATHER THAN LINE (which it should be reporting) attenuation is a calculation which is the difference between the power transmitted at the FAR END and the power received at the near end. Signal attenuation is based an average of the frequency bins actually in use. Again relating to tones and AGAIN what i think the issue is with the Asus and have done for months.

DIABLO said:
Attenuation is the amount of resistance the signal is getting from the lines.

SNR is the one related to noise on the line.

Yep, well nope, but close enough (simple way to explain it) for this little bit of conversation without a full on education for some

(its actually a ratio of signal power to the noise power measurement in decibels of the Signal strength on the line. The higher or rather nearer your SNR is, to the attenuation the better (on a line with no issues or silly high attenuation, as there is less Noise).

Ideally you want both the SNR and Attenuation figures to be as close to each other as possible without being overly high or low (a high and useless figure would be over 60db a low figure FOR BOTH not just one or the other would be 10db.... Not that anyone will ever see anything like that).

Any one figure that is significantly higher or lower than the other will affect a connection. A good connection for FTTC will have around typically have around 15-20db difference between the 2 sets of figures.

IE look at the DIFFERENCE in figures/db on your downstream SNR and attenuation, do the same for the Upstream, add them both together and if you have a good line its likely to be around a total of 15-20db give or take 5db. Which is also the figure you will typically see if you add the attenuation and SNR together from either the downstream or the upstream but not normally both. IF it is anything significantly different (like double or half) then either your line is naff or the stats the device are feeding the eyeballs are bunkum.... Ah electricity, noise, resistance, signal and simple maths... wonderful things the laws of physics are

HaydnExport · 4 Apr 2015 at 10:23

I'm pretty close to my cabinet , my upstream attenuation is 0.1 and downstream is 7.8. Ive finally seen a positive change on new firmware, banded changed from 27899 to 29999, still massively interleaved and way away from getting back to 68mb plus throughput but it's a start , so far so good team asus !

mjgr33n · 4 Apr 2015 at 10:46

HaydnExport said:
I'm pretty close to my cabinet , my upstream attenuation is 0.1 and downstream is 7.8. Ive finally seen a positive change on new firmware, banded changed from 27899 to 29999, still massively interleaved and way away from getting back to 68mb plus throughput but it's a start , so far so good team asus !

Yeah, my Line Attenuation Up is 0.4 dB and am only ~50m from the cabinet. Line Attenuation Down is about 5.3 dB and luckily get rock solid stats and connection, even better now they enabled G.INP.

michty_me · 4 Apr 2015 at 11:07

Here is one for all you switched on cookies. I've always used ECI modems until a few days ago when I tried an HG612 modem I bought earlier last year (To match my cab) My sync speed went from 60.1Mbps to 65Mbps.
I was seeing some weird stats so it was suggested to update to the latest firmware which I did as I didn't realise I was on an old one. Sync speed now went up to 66.9Mbps.

Someone on Kitz has said that ECI modems are causing issues once G.INP is applied with some people not being able to sync at all, Others are losing sync speed and gaining latency. I'm not sure if it is just hearsay.

Since switching to the HG612, I've gained nearly 7Mbps sync, Ping times have returned to normal and I'm still on interleaved with a 9.1dB SNRM so hopefully more to come. In 24hrs, I have not had one CRC/ES/SES error at all too. so things are looking up!

bitsNbobs · 4 Apr 2015 at 17:06

HaydnExport said:
I'm pretty close to my cabinet , my upstream attenuation is 0.1 and downstream is 7.8. Ive finally seen a positive change on new firmware, banded changed from 27899 to 29999, still massively interleaved and way away from getting back to 68mb plus throughput but it's a start , so far so good team asus !

mjgr33n said:
Yeah, my Line Attenuation Up is 0.4 dB and am only ~50m from the cabinet. Line Attenuation Down is about 5.3 dB and luckily get rock solid stats and connection, even better now they enabled G.INP.

Stats like those especialy the first person make no sense with stats like that and being "close" to the cabinet that line should be running at top speed all the time, DLM should not even enter the equation ever if figures like that were true never mind banding a line. Can anyone confirm or deny attenuation figures fluctuate? Typically they should not unless...
A) The line has some type of issue
B) The device is measuring SIGNAL attenuation rather than LINE attenuation.

michty_me said:
Here is one for all you switched on cookies. I've always used ECI modems until a few days ago when I tried an HG612 modem I bought earlier last year (To match my cab) My sync speed went from 60.1Mbps to 65Mbps.
I was seeing some weird stats so it was suggested to update to the latest firmware which I did as I didn't realise I was on an old one. Sync speed now went up to 66.9Mbps.

Someone on Kitz has said that ECI modems are causing issues once G.INP is applied with some people not being able to sync at all, Others are losing sync speed and gaining latency. I'm not sure if it is just hearsay.

Since switching to the HG612, I've gained nearly 7Mbps sync, Ping times have returned to normal and I'm still on interleaved with a 9.1dB SNRM so hopefully more to come. In 24hrs, I have not had one CRC/ES/SES error at all too. so things are looking up!

This could be the issue and why some are now seeing weird attenuation figures, the ASUS uses a different chipset compared to the ECI and Huawei so i wonder if G.INP on the device is not being interpreted correctly. Either way something is now wrong with some of the weird figures now being reported. Personally i still say its bit loading and/or a tones issue they still have not sorted.

michty_me · 4 Apr 2015 at 19:10

I was kind of hoping you would comment to be honest. I believe BT are advising engineers of issues with ECI modems going by a few threads I've read. So far I'm liking the roll out of G.INP anyway. It has helped my line tremendously!

HaydnExport · 4 Apr 2015 at 19:53

my line was banded because of the asus !! no matter how good my line is with it disconnecting every hour , dlm .

mjgr33n · 4 Apr 2015 at 20:19

bitsNbobs said:
Stats like those especialy the first person make no sense with stats like that and being "close" to the cabinet that line should be running at top speed all the time, DLM should not even enter the equation ever if figures like that were true never mind banding a line. Can anyone confirm or deny attenuation figures fluctuate? Typically they should not unless...
A) The line has some type of issue
B) The device is measuring SIGNAL attenuation rather than LINE attenuation.

This could be the issue and why some are now seeing weird attenuation figures, the ASUS uses a different chipset compared to the ECI and Huawei so i wonder if G.INP on the device is not being interpreted correctly. Either way something is now wrong with some of the weird figures now being reported. Personally i still say its bit loading and/or a tones issue they still have not sorted.

My line attenuation used to be, before G.INP was applied -

Line Attenuation Down
5.3 dB
Line Attenuation Up
8.3 dB

Afterwards -

Line Attenuation Down
5.3 dB
Line Attenuation Up
0.4 dB

Once I saw my Line Attenuation Down at 5.4 dB though, other than that it has never changed in 3 months.

I don't understand what you mean by top speed as my line is running at top speed, it cannot get any higher, lines are limited to 80 down and 20 up, the max rate it said it is capable of is 100 down and nearly 40 up, how can it be any higher on an asynchronous set-up? I once set UPBO to disabled to test for a few minutes months ago and got a data up of over 60Mb/s up so my line is pretty much perfect. So I assume you mean the other guy.

If you need any other stats from my router let me know.

bitsNbobs · 5 Apr 2015 at 00:21

michty_me said:
I was kind of hoping you would comment to be honest. I believe BT are advising engineers of issues with ECI modems going by a few threads I've read. So far I'm liking the roll out of G.INP anyway. It has helped my line tremendously!

ECI modems have issues because they are not meant to be using G.INP yet, Huawei ones work fine as the chipset matches the cabinets which have G.INP setup (IE broadcomm) The Asus is neither infineon/lantiq or broadcom for the modem side of things but is Mediatek based, so how it will perform with G.INP enabled or if G.INP even functions correct on the device is basically a lottery.

HaydnExport said:
my line was banded because of the asus !! no matter how good my line is with it disconnecting every hour , dlm .

As stated stats like you reported of 0.1db must be wrong. AS i also stated for the other user with 0.7db being reported im shocked its remained stable for 3 days for them. Something is still clearly wrong or being interpretted wrong on the device.

mjgr33n said:
My line attenuation used to be, before G.INP was applied -

Line Attenuation Down
5.3 dB
Line Attenuation Up
8.3 dB

Afterwards -

Line Attenuation Down
5.3 dB
Line Attenuation Up
0.4 dB

Once I saw my Line Attenuation Down at 5.4 dB though, other than that it has never changed in 3 months.

I don't understand what you mean by top speed as my line is running at top speed, it cannot get any higher, lines are limited to 80 down and 20 up, the max rate it said it is capable of is 100 down and nearly 40 up, how can it be any higher on an asynchronous set-up? I once set UPBO to disabled to test for a few minutes months ago and got a data up of over 60Mb/s up so my line is pretty much perfect. So I assume you mean the other guy.

If you need any other stats from my router let me know.

Please re-read the post you are referencing...
http://forums.overclockers.co.uk/showpost.php?p=27869818&postcount=1807
the comment about TOP speed was clearly aimed at HaydnExport not yourself.

AS for your stats and being on G.INP something is most definitely wrong for the UP attenuation to change so much but the down attenuation to basically not change at all. That makes no sense at all, something is not being read right by the device. Its almost like its using upstream frequency to stabilise the downstream for some reason. I would not be shocked if the latest beta firmware has the tone algorithm re-written/tweaked and now G.INP is showing up the new tweak they have made does not like it. The device is far from fixed, someone on full fastpath with no INP set would be able to confirm this hence why i asked ixel way earlier into this debate here.... http://forums.overclockers.co.uk/showpost.php?p=27845665&postcount=1732
to give that a check in a few weeks once he has finished his current testing.

I spotted something iffy way before the next 4 pages of the thread came along

babis3g · 5 Apr 2015 at 03:40

its a long page ... but i can see customers with Zen as well will not report G.INP or will have blank info for some modems/lines and the company seems worried
http://forums.thinkbroadband.com/fibre/4399541-ginp-and-eci-modem-problem.html#Post4399541

andy66 · 5 Apr 2015 at 09:08

One way that Line Attenuation Up gets miss-reported (in the hope that this helps increase understanding and assuming the DSL-AC68U behaves the same as the DSL-N66U):

It is observed that the reported "Line Attenuation Up" is changed by using the "Tx Power Control (VDSL)".
Setting "Tx Power Control (VDSL)" to -3dB has a side effect of increasing reported "Line Attenuation Up" by 3dB.

And my supposition of how this is happening is:
Setting "Tx Power Control (VDSL)" to -3dB makes the modem's actual TxPowerUp 3dB less than the notional level it would otherwise have been.
When "Line Attenuation Up" is calculated (I don't know by when end), by comparing TxPowerUp with the resulting RxPowerUp, it is the notional value that gets used in the calculation.

The effect of "Tx Power Control (VDSL)" on the reported "POWER Up" is more complicated - it does not just simply reduce by 3 when "Tx Power Control (VDSL)" is set to -3.
I suspect that the resulting apparently higher attenuation line has a countering effect of increasing the TxPower that the negotiation determines the line needs. Either that, or it's simply the notional TxPowerUp that gets reported.

mjgr33n · 5 Apr 2015 at 12:09

bitsNbobs said:
Please re-read the post you are referencing...
http://forums.overclockers.co.uk/showpost.php?p=27869818&postcount=1807
the comment about TOP speed was clearly aimed at HaydnExport not yourself.

AS for your stats and being on G.INP something is most definitely wrong for the UP attenuation to change so much but the down attenuation to basically not change at all. That makes no sense at all, something is not being read right by the device. Its almost like its using upstream frequency to stabilise the downstream for some reason. I would not be shocked if the latest beta firmware has the tone algorithm re-written/tweaked and now G.INP is showing up the new tweak they have made does not like it. The device is far from fixed, someone on full fastpath with no INP set would be able to confirm this hence why i asked ixel way earlier into this debate here.... http://forums.overclockers.co.uk/showpost.php?p=27845665&postcount=1732
to give that a check in a few weeks once he has finished his current testing.

I spotted something iffy way before the next 4 pages of the thread came along

I did re-read, you quoted both of us and said especially first person, you did not preclude myself at that point by saying especially, but then I went on to say I assume you meant the other guy anyway, so hardly clear, hence the clarification needed by myself. You should have just not quoted myself if you did not want a response.

If you are going to nit pick everything people say I can do the same thing to everything you state as well to the point it becomes annoying for you to read also. But I am not trying to provoke an argument, just want to provide some form of useful information, you are acting like an expert on this router so please tell me what other information or tests you think can be performed to get meaningful information from it or please tell me what is bad about it stating 0.4db Line Attenuation UP when it is so stable?

I am willing to do the odd occasional thing to test as long as it does not require more than one change per 48 hours in any settings on the modem side of the router.

My line is and always has been incredibly stable, only time had an issue was when I played around with the settings for an entire day testing things and then the next day I got hit by DLM and got knocked down in speed and got interleaved, took only 48 hours for it to pop back up to full speed and fastpath, but don't really feel like playing too much around after that

FYI am using stable ASUS DSL-AC68U Firmware version 3.0.0.4.376_2187 not the beta firmware. Only thing have not mentioned before is I am using Mk3 Faceplate that had to fit myself, used to use ADSL Nation Master socket when I was on Zen ADSL.

When the next official firmware comes out I will try that and see if the Attenuation figures change at all.

One thing I really would like is a more detailed stats page rather than having to telnet into the router for more information. Also would like to not have a blank DSL modulation (Opmode) entry.

My latest info_adsl.txt (if it is of any use) -

Code:

fwVer= FwVer:5.5.1.127_B_A60901 H

lineState=up
Opmode=
SNRMarginDown=7.3 dB
AttenDown=5.3 dB
SNRMarginUp=16.1 dB
AttenUp=0.4 dB
DataRateDown=79998 kbps
DataRateUp=19999 kbps
WanListMode=1
FECDown=1433
FECUp=3716
CRCDown=0
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=4 days,  1:49, 24 secs
ADSLActiveTime=0 min, 17 secs
PowerDown=12.2 dbm
PowerUp=-4.5 dbm
ATURID=26005443434e0000
ATUCID=b5004244434da485
AttainUp=36824
AttainDown=103796
ShowtimeStart=17
TotalStart=85
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus

HaydnExport · 5 Apr 2015 at 12:32

moving on... Ive been put back on fastpath , ping down to 19 , it has been 12 before so still wiggle room i think, and im also still banded 29999, but things are improving fast !

Ixel · 5 Apr 2015 at 13:14

Beware the router can still say fastpath on the stats UI page when it's actually not fastpath, hence why your ping might still be higher than expected.

Regarding line attenuation, on the HG612 quite some time ago I have a screenshot of my pbParams data, clearly the ASUS is measuring the U0 attenuation (either line or signal, not sure which). However it might be calculating it a little lower than it should actually be.

Obviously altering the DSL settings such as the transmit power offset will effect this. Another interesting fact is that if I reduce my offset too much (e.g. to get an ideal attainable near to the 20Mbps upstream sync rate limit) it will cause downstream error statistics to be worse, such as increased errored seconds, severely errored seconds, FEC errors and/or CRC errors. So far the best setting that works for me appears to be +1 dB on the transmit power offset.

My current DSL settings: http://i.imgur.com/2MoReXp.png

Code:

near-end path0 fec:     666233
near-end path0 crc:     28
near-end fec sec:       5797
near-end err sec:       10
near-end ses sec:       0
near-end los sec:       0
near-end ua  sec:       0

far-end path0 fec:      589
far-end path0 crc:      94
far-end fec sec:        144
far-end err sec:        88
far-end ses sec:        0
far-end los sec:        0
far-end ua  sec:        0

Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=8.5 dB
AttenDown=10.3 dB
SNRMarginUp=12.6 dB
AttenUp=0.1 dB
DataRateDown=62681 kbps
DataRateUp=20000 kbps
ADSLUpTime=2 days,  6:18, 50 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=11.1 dbm
PowerUp=5.8 dbm
AttainUp=30249
AttainDown=104492
InterleaveDepth=1747
AdslStandard=VDSL2
AdslType=ANNEX_B

That's currently an average of around 12,000 FEC errors an hour, when I increased transmit power offset to +3 dB the FEC errors were almost continuously counting on the downstream. Reducing it to -5 dB also produced more FEC errors and CRC errors on the downstream. A setting of 0 dB (or default) resulted in a slightly higher rate of FEC errors compared to +1 dB at the moment. I'm leaving the settings as they are now and will wait for G.INP.

Final note, G.INP will mask the stability problems on older firmware, so while ESNP is not required I imagine G.INP will be a bit more active without ESNP (provided the line previously suffered stability problems with the ASUS before G.INP was enabled on the line).

Oh, I also believe bitswapping on VDSL2 is working. I initially synced with around a 7 dB SNRM on the downstream, and it's currently 8.5 dB. No noticeable activity at the cabinet/PCP recently either.

mjgr33n · 5 Apr 2015 at 14:56

HaydnExport said:
moving on... Ive been put back on fastpath , ping down to 19 , it has been 12 before so still wiggle room i think, and im also still banded 29999, but things are improving fast !

What do you use to ping? google.com or bbc.co.uk?

Using the routers Network Analysis page I get the following -

Code:

PING www.google.com (216.58.209.228): 56 data bytes
64 bytes from 216.58.209.228: seq=0 ttl=55 time=11.255 ms
64 bytes from 216.58.209.228: seq=1 ttl=55 time=10.549 ms
64 bytes from 216.58.209.228: seq=2 ttl=55 time=10.859 ms
64 bytes from 216.58.209.228: seq=3 ttl=55 time=10.737 ms
64 bytes from 216.58.209.228: seq=4 ttl=55 time=10.935 ms

--- www.google.com ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 10.549/10.867/11.255 ms

cuke2u · 5 Apr 2015 at 17:59

Tracert through a command promt, or just ping a site..

HaydnExport · 5 Apr 2015 at 18:45

by cmd to bbc.co.uk , it was on 35 yesterday so im definitely on a less interleaving depth

babis3g · 5 Apr 2015 at 18:59

Ixel said:
Beware the router can still say fastpath on the stats UI page when it's actually not fastpath, hence why your ping might still be higher than expected.

Regarding line attenuation, on the HG612 quite some time ago I have a screenshot of my pbParams data, clearly the ASUS is measuring the U0 attenuation (either line or signal, not sure which). However it might be calculating it a little lower than it should actually be.

Obviously altering the DSL settings such as the transmit power offset will effect this. Another interesting fact is that if I reduce my offset too much (e.g. to get an ideal attainable near to the 20Mbps upstream sync rate limit) it will cause downstream error statistics to be worse, such as increased errored seconds, severely errored seconds, FEC errors and/or CRC errors. So far the best setting that works for me appears to be +1 dB on the transmit power offset.

My current DSL settings: http://i.imgur.com/2MoReXp.png

Code:

near-end path0 fec: 666233 near-end path0 crc: 28 near-end fec sec: 5797 near-end err sec: 10 near-end ses sec: 0 near-end los sec: 0 near-end ua sec: 0 far-end path0 fec: 589 far-end path0 crc: 94 far-end fec sec: 144 far-end err sec: 88 far-end ses sec: 0 far-end los sec: 0 far-end ua sec: 0 Opmode=ITU G.993.2(VDSL2) SNRMarginDown=8.5 dB AttenDown=10.3 dB SNRMarginUp=12.6 dB AttenUp=0.1 dB DataRateDown=62681 kbps DataRateUp=20000 kbps ADSLUpTime=2 days, 6:18, 50 secs ADSLActiveTime=0 min, 19 secs PowerDown=11.1 dbm PowerUp=5.8 dbm AttainUp=30249 AttainDown=104492 InterleaveDepth=1747 AdslStandard=VDSL2 AdslType=ANNEX_B

That's currently an average of around 12,000 FEC errors an hour, when I increased transmit power offset to +3 dB the FEC errors were almost continuously counting on the downstream. Reducing it to -5 dB also produced more FEC errors and CRC errors on the downstream. A setting of 0 dB (or default) resulted in a slightly higher rate of FEC errors compared to +1 dB at the moment. I'm leaving the settings as they are now and will wait for G.INP.

Final note, G.INP will mask the stability problems on older firmware, so while ESNP is not required I imagine G.INP will be a bit more active without ESNP (provided the line previously suffered stability problems with the ASUS before G.INP was enabled on the line).

Oh, I also believe bitswapping on VDSL2 is working. I initially synced with around a 7 dB SNRM on the downstream, and it's currently 8.5 dB. No noticeable activity at the cabinet/PCP recently either.

Hopefully Mr Jim @ Asus will take a look at the power transmit

Perhaps the AGC has something to do?

Have you tried what is best with transmit power for you line and play with AGC Gain?
(perhaps same settings as your screen shoot but change the AGC?)