Print

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

[Weaver]

> 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.

I will try and isolate where I have gone wrong. Was out of action all day Sunday.

[Weaver]

Anyone else who has one, what firmware version numbers do you have? (I see several, for different software components - rather confusing.)

Anyone have any idea where I could download software from?

[Weaver]

On reflection, it is so very weird that the upstream was so very good. Wonder what on earth was going on.

[Weaver]

I have now repeated the test with the exact Burakkucat config, complete with RFC2684-VC-MUX setting - so that is different from yesterday. Same disastrous result. Throughput is ~50kbps downstream measured on speed tester. In addition, I tried the modem in isolation as opposed to being teamed up with two dlinks, but couldn't even complete a speed-tester run.

Sol things I could still try

• LLC again - seeing as someone else, AA user Farnz on IRC, told me today that in his opinion PPPoEoA VC-MUX is 'unreliable' but didn't go into more detail. I presume he meant 'on BT' because we know it works for Burakkucat on TT LLU.
• MTU 1508 or 1500 instead of the current huge value
• 6dB SNRM - for the sake of science - but that probably defeats the point of using these devices

I could of course ask someone else to test this modem, but I'm not sure what that would prove. Disappointing as this device has real potential.

[NEXUS2345]

For the record I am on BT Wholesale kit using VC-MUX with PPPoEoA on my HG612 and have not had an issue with it. Nor have I heard of others having issues with VC-MUX on 21CN BTW kit.

[Weaver]

Thanks very much to nexus2345. That means you just gave me 3% more speed for free! I don't know why Farnz was of this opinion. And I have no idea why I thought it didn't work. Is there a chance that it doesn't work on 20CN? I suspect that I must have tried it many years ago as I would have found the greater efficiency irresistible.

[Weaver]

I suspect that this means that I will have to close this experiment as an extremely mysterious failure. I just do not understand what is going on at all. Can I ask, are these the only possibilities?

• Burakkucat's DSLAM is different to mine
• I have a one-off duff modem
• Something relating to routers and PPPoE behaviour - difference between me and Burakkucat
• Something relating to routers and MTU - difference between me and Burakkucat
• The unit doesnt like running at such low downstream SNRM in my setup - 2.5 - 3.0 dB

I haven't collected enough data to work out exactly what is causing the crazy speedtest result. If I say packet loss then I'm just simply guessing. At least this time around I knew it was not something to do with refusal to play nicely alongside other modem models, because I did test it in isolation.

Anyway, at least I should get a lovely gift of 3% extra speed from the DLink modems from now on then, so something worthwhile has come out of it.

Many thanks once again to Burakkucat for his extremely generous help.

[burakkucat]

Interrogating my ZyXEL VMG1312-B10D, it reports the MSAN's line-card chipset as follows --

$ xdslctl info --vendor
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason:   8000
Last initialization procedure status:   0
Max:   Upstream rate = 952 Kbps, Downstream rate = 6036 Kbps
Bearer:   0, Upstream rate = 960 Kbps, Downstream rate = 5120 Kbps

ChipSet Vendor Id:   IFTN:0x71c8
ChipSet VersionNumber:   0x71c8
ChipSet SerialNumber:   
$

When I last experimented with a MT882, the device was using the same configuration file that I provided to Weaver. All the MT882 did was to convert from G.992.3, ATM, VC-MUX 0/38, to Ethernet frames and the converse. The MT882 was connected, via a standard Ethernet patch cable, to my laptop computer. The computer had its WiFi (physically) switched off and provided a firewall, whilst also acting as a PPP client.

During the test, which lasted a number of hours whilst I was here, active in the forum, I noticed no abnormalities of any kind. The one thing I did not do was to run a throughput speed-test. However the synchronisation speed was typical for my circuit. (See below.)

[Weaver]

I immediately noticed a huge number of hecs and other errors, 90000 within the first minute or so. Then after that the number never went up, but this was while I was just sitting watching it in the web UI and no real internet traffic could have been happening. Other than that the stats all looked good, in fact very encouraging. And I did try RFC2684 LLC as well the first time round, out of fear and ignorance, so VC-MUX plus my DSLAM cannot be blamed. I'm simply at a loss. The first config that I used was just based on my own opinions and what I normally do plus comparison with Burakkucat’s screenshots. So there can be no possibility that the problem is solely based on something peculiar in Burakkucat's config choices as I would have done the same any way.

If anyone has any intelligent suggestions? I don't know how to make a modem ridiculously slow - well there are perhaps too many ways. Unfortunately I don't see a running count of hecs delivered by clueless any more but the hugs error rate I saw in the first few tens of seconds would definitely fit. Actually now I remember the HEC count remained at zero for a few seconds, but that could just be down to the rate at which the UI updated, although I think it was zero across more than one update, then after say ten seconds or so it suddenly jumped to this high value and it was as if it was all just a delta function.

[Weaver]

Does anyone else have one of these devices?