Print

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

[Weaver]

Burakkucat was kind enough to give me some help and guidance with getting hold of a Huawei SmartAX MT882 modem for testing purposes. After an eternity of delay, I managed to recruit a volunteer to plug one in for me and configured it using Burakkucat's tips.

In Burakkucat's notes I think it was suggested to set the modem up to use RFC 2684 section 6.2 (VC-MUX for 'bridged protocols'). This is PPPoEoA over ADSL2 in my case. I chickened out and chose RFC 2684 sec 5.2=LLC+bridged-PDUs, because if I recall correctly VC-MUX + PPPoEoA doesn't work with BT kit, for some reason, and you have to use LLC instead. (Although PPPoA VC-MUX works, which is what all sensible ADSL users use if they have a single-box modem-router or the smart Draytek Vigor modems which convert PPPoEoE to PPPoA over DSL.)

Is this correct, or has anyone ever managed to get VC-MUX going with PPPoEoA (Draytek users are banned for cheating) on ADSL1/2/2+ ? I can of course soon try it, but that means getting my volunteer to pull all the kit apart again and she might grumble at the prospect.

Of course Burakkucat might be able to do the right thing himself by using TalkTalk DSLAMs. Clearly being able to use VC-MUX is fantastic because it saves eight bytes of overhead and if my arithmetic is correct that means that it fits an 1500 byte IP PDU plus overheads into an exact number of ATM cells, so saving a whole cell, which means that for MTU=1500 it is 3% faster than my stupid choice of RFC2684-LLC-for-bridged-PDUs. A completely free lunch. This inefficiency could of course be fixed by using a reduced MTU.

[Weaver]

These are the stats I got out of the modem using its web UI over an initial quiet hour or so of uptime with little or no traffic unfortunately

System Information

Item   Description
Product Name   SmartAX MT882
Physical Address   00:1D:6A:FC:B9:C7
Software Release   V200R002B021 Opal
Firmware Release   E.37.5.5
Release Date   (2006-05-12)
Batch ID   RCC1P3.021.E37555
System Up Time   1:6:33
ADSL   Description
ADSL Status    Showtime/Data
DSL Up Time   1:5:52
Data Path   Interleaved
Standard   ADSL2
Bandwidth Down/Up(kbps)   3122/512
SNR Margin Down/Up(dB)   3.0/6.0
Attenuation Down/Up(dB)   63.0/40.0
CRC Down/Up   46838/1345
FEC Down/Up   6775010/52963
HEC Down/Up   94414/1739

A few points:

* Impressive downstream sync rate: 3104 kbps seen on one run, 3055 kbps currently. This is a real throughput increase of 300kbps, and that's after taking overheads out the difference in sync rates is larger. A PPP downstream real throughput increase of more than 12% (on one modem)

* A huge number of HEC errors appear within the first 20s or so, but the number never seems to go up much, although it was not really doing during that time. Don’t know whether or not idle cells count. Can't draw any conclusions from this unless we thrash it with some real data. I don't know whether this is something to worry about or not. Looking at it pessimistically you could suggest that it is ultra-aggressive and less reliable. The problem is that I don't get any error stats any more, goodness knows why not. I used to get HEC error counts and so on from AA (presumably via BT).

* The downstream attenuation is a a bit better than with the DLinks - by 3-4dB

* SNMR downstream fluctuates between 2.5 and 3dB, it’s as if it’s quantized to those levels, cant really have such a low res though. It is at that level after about 45 mins, from a downstream target of 3dB. It does not seem to drop instantly.

Can I upgrade the firmware?

[Weaver]

Ouch. Suddenly the penny drops. A speed test using speedof.me gives an incredible 0.3 Mbps downstream / 1.15 Mbps upstream. Well the upstream is a fantastic result anyway, 30% overall improvement from just _one modem_ alone, but downstream real throughput reduced by 95% is not so clever. I don't know exactly what is going on but I assume that it is a horrific error rate. For some reason though I am not seeing a lot of CQM packet loss on clueless though.

I could retest with the downstream target SNRM pushed up to 6dB to see if that might fix things, but that if that then worked properly it would probably throw just away all the downstream speed advantages gained, although I might be left with the upstream gains.

[kitzuser87430]

How can your speedtest result be greater than than the upstream sync??

Something is amiss.

Ian

[jaydub]

Simple; speedof.me doesn't give reliable results.

Sent from my EVA-L09 using Tapatalk

[ejs]

I assumed the 1.15 Mbps upstream speedtest result was by using all 3 of Weaver's lines.

[burakkucat]

I think I have provided a copy of the configuration file that had been saved from the SmartAX MT882 that I have stored in The Grotto. (I seem to recall setting the MTU to 9712, the maximum that the device would allow.)

My suggestion is to just upload the configuration file to the device and use it, as is. After a day (or so), see how it is performing. Its far too "early days" to start "over-thinking" its configuration.

[Weaver]

Ejs is correct. The normal three-line upstream value is 0.88, sometimes a little higher.

Recap: I've found that speedof.me accords well with the downstream rate limiter values in the AA logs and with theory if you down-convert sync rates by multiplying by the factor needed to convert IP PDU MTU into ATM bytes, it is what it is, and it is always higher than all other speed testers, which we have discussed before, but this could be a matter of their chosen definitions as well as testing methodology and good availability. I have found that the ookla one for example varies quite a bit between their test server sites, which in my mind is not good. It also depends on what you are trying to measure, the whole of the path through the internet at one extreme, which is very arbitrary and at the other extreme just your line, or as near to it as possible. I am trying for the latter, or the combination of my modem plus line plus ISP, in other words, the bottleneck, the bit I can currently do nothing about. I'm under no illusions about the relationship between speedof.me and other speed testers. But my feeling is that you should always go for the highest numbers because then there is nothing bogus limiting the result, nor any alien traffic. Obviously that logic does not necessarily carry over to the case of comparison between testers, it is more to do with serial comparison, up I can't see how it hurts too much.

[Weaver]

@Burakkucat - I did indeed do just that, I firstly uploaded your config file. But I think I may have made a mess of something somehow, maybe I had to do some other kind of 'commit' operation afterwards, because the ATM-related settings didn't look correct to me and did not look like your screenshots. VPI / VCI was expected to be 0 / 38 and if memory serves the web UI showed 35 and was not showing up as pure bridge, so I must have screwed something up. I discovered belatedly that I had to keep hitting “save all” or similar after making changes as well as some hitting some other UI control ('submit' or 'enter' or some such) in settings pages, so had to hit two different kinds of 'commit'. Maybe that is where I went wrong.

But anyway, I went through the entire web UI from end to end and compared what I actually had with the complete selection of screenshots that Burakkucat had provided.

Kitizens, Burakkucat's generous help with this project has been above and beyond the call. His claws were worn down taking dozens of screenshots and saving a config file for me.

I need to try again and recheck that the settings are exactly as Burakkucat provided, with the possible exception of the RFC2684/LLC thing if it turns out that I really have to do this and I am not just being pessimistic. Can anyone confirm that PPPoEoA VC-MUX doesn't work with 21CN by consulting the great times if standard lore? (21CN as in my case. Would be interesting to know about 20CN too.)

Perhaps someone else who is on PPPoEoA (i.e. not on VDSL2) could check the VC-MUX vs LLC thing quickly for me? There are at least three tests - BT 20CN, BT 21CN and various LLU ADSL options. I'm assuming that this only depends on the DSLAM? Is that correct? - and not on anything further upstream as well? But I don't know why I am thinking that, who knows.

I will try it myself when I can recruit my cheerful volunteer hopefully tomorrow. I need a means of paying my test assistant suitably for her modem-swapping efforts.

I can set the DLinks to VC-MUX if I end up going back to them. I didn't realise that it would be such a big deal in terms of efficiency, I had never done the arithmetic before. (See the Wikipedia article on PPPoE, the section on PPPoEoA overheads over DSL, will need to adjust the figure given for RFC2684 LLC overhead and change it from 10 bytes to 2 bytes [I think] for VC-MUX-bridged-PDUs.)

I also ought to retest with just the one new modem going in case of some screw-up of some kind and anyway it will be a lot easier to see what is going on.

And I ought to see what is going on with MTU. I am using approximately the same huge ~9000 byte MTU that Burakkucat recommended, but not exactly the same value because according to the modem UI the specified value of 9216 was reduced to a lower 'current value'. AA and the Firebrick will limit it to 1500 I suspect, and in any case I can't really play with this until I get rid of the mixture of modems with different MTUs which of course would be a nightmare. I ought to check that some mixed MTU thing is not the source of the performance hell, that would be fixed by testing the Huawei on its own. And of course I could clamp the Huawei at 1500 while it has to play nicely alongside its DLink brethren if this does turn out to be an issue.

So possible causes of performance hell:

• 3dB SNRM - just way too aggressive, huge number of initial HECs
• MTU mixture
• My mistake in my config
• If I get the config exactly the same as Burakkucat had it, is that guaranteed to be a good thing (DSLAMs)? On the legs of my grandmother.
  

Have I forgotten anything?

[burakkucat]

@Burakkucat - I did indeed do just that, I firstly uploaded your config file. But I think I may have made a mess of something somehow, maybe I had to do some other kind of 'commit' operation afterwards, because the ATM-related settings didn't look correct to me and did not look like your screenshots. VPI / VCI was expected to be 0 / 38 and if memory serves the web UI showed 35 and was not showing up as pure bridge, so I must have screwed something up. I discovered belatedly that I had to keep hitting “save all” or similar after making changes as well as some hitting some other UI control ('submit' or 'enter' or some such) in settings pages, so had to hit two different kinds of 'commit'. Maybe that is where I went wrong.

I must admit that the intuitiveness of the GUI interface is somewhat lacking but once one has become familiar with it, it really is quite straightforward.

• Login to the device.
• Select Tools.
• Select Backup & Restore.
• Left click on Browse to find the appropriate file.
• Left click on Upload.
• Left click on Save All.
• Select Save & Reboot.
• Left click on Reboot.

The device should then re-boot, configured to respond at the 192.168.1.254 IPv4 address.

Have I forgotten anything?

A low-flying raven should be disembowelled, its entails scattered, visually considered and then homage paid to your local flock of wild haggis. (Not being a linguist, I am uncertain of the correct plural form of the word "haggis".)

[Weaver]

That is where I went wrong, I did not hit save all after the upload. I will go again tomorrow if my charming assistant is willing.

Got up to waddle to the bathroom this evening, just being upright made me quite nauseous. So al admin is done horizontally.

[Weaver]

@Burakkucat - I take it that you are LLU and can use the good VC-MUX yourself.

[j0hn]

AFAIK there is no plural to the word haggis. It's 1 haggis or 2 haggis. It's quite rare to see more than 1 at a time anyway. They are quite shy and elusive, particularly during the January-February hunting season.
Must say I do love haggis, and have a "burns supper" at least once a fortnight. 

 

[burakkucat]

@Burakkucat - I take it that you are LLU and can use the good VC-MUX yourself.

Yes, you are correct. My CP is TalkTalk and that is the only reason why there is a TT branded Huawei SmartAX MT882 stored in "The Grotto".

The configuration file, which I have given to you, is exactly as how I was using the MT882 for some tests. My laptop computer was the PPP client and was connected, via an Ethernet patch lead, directly to the MT882.

[Weaver]

Haggises -

All the dictionaries have "tageis" pl. "tagaisean". This immediately struck me as an English loan word into Gaelic, albeit possibly old, there are so many similar ones. But I have no evidence for this, it could be the other way around, but the word feels wrong to me, can't put my finger on it. Dwells notes that the word "tageis" also means "scrotum"!

SMO's dictionary has "marag ghallda" for "haggis" - so the haggis is claimed to be a foreign / lowland concept, "gallda" meaning "non-Gaelic". The word "marag" (f.) means a black pudding. So the plural would be "maragan (gallda)".

No day is complete without a gift from Edward Dwelly's stunning dictionary.
    “Cha truagh leam cù is marag m' a amhaich”
     NEG pity with-1SG dog and pudding about 3SG.GEN neck
    “I do not pity a dog with a pudding about its neck.”

As for the true meaning of this seanfhacal, I will have to ask my neighbours.