Annex M on Pace 4111n

[bronscon]

I have a sonic.net-provided Pace 4111n and have a few questions about how it handles Annex M.

I just switched my line back to Annex A because when the line is configured for Annex M, the automated system will report that it is using Annex M when it is down, but report it as using Annex A when it comes back up; additionally, the Pace device reports that it is still using G.DMT2+ Annex A and my UCE jumps from -13.6dB (when using Annex A) to +19.6dB. I do, however, see an increase in upstream sync rate, though the drop in downstream sync seems excessive (from just shy of 20mbps to just shy of 12mbps).

Is it normal for a 4111n (and the automated system, when the line is up) to continue reporting Annex A when Annex M is in use? Is a 32dB increase in UCE normal when switching from Annex A to Annex M? This doesn't seem right (and indeed neither of the 2 lines at my office behave in this manner).

My line is pristine, able to just about max out sync rates in both directions on Annex A even at a hair over 4k feet with attenuation of 26.5dB and a 6.3dB noise margin on the downstream, 13.6dB attenuation and 6.1dB margin on the upstream; this line is much cleaner than either of my office lines that perform better on Annex M than this line. Should i be looking at the modem or asking sonic.net to look at the line card? Or should I consider this normal and just deal with it?

[bronscon]

I'd really like to get some input on this, as I'd like to be on Annex M. Should the Pace device still be reporting Annex A when the line is configured for Annex M, or does this indicate a fault with the modem and/or line card? That is to say, should a request a new modem? Ask Sonic.net to have the line card looked at? Neither? Both?

I could just ask for a new modem right off the bat, I suppose, but that comes at an expense to Sonic.net, which while it doesn't come from my pocket immediately, would be a contributing factor in any future rate increases. Likewise with the service call to check out the line card. If this is normal behavior for this modem, I'll just live with it, rather than needlessly costing my provider money (if it was AT&T or Comcast, I'd be bleeding them dry like they do to me; but Sonic.net actually doesn't suck so... yeah, there's that).

Anyone?

[dane]

If the IVR system on 611 is reporting that you are on Annex M (upload priority), and you see a jump in upload speed from the typical ~1Mbps to 1.5-2.5Mbps, you're on Annex M. You'll also see a decrease in downstream speed that is likely to be quite substantial - dropping from 20Mbps to 12Mbps isn't unsurprising.

[bronscon]

Thank you for the reply, Dane. My problem is that the IVR reports I'm on Annex M while the modem is resynching, but once the line is up again it begins reporting Annex A (Download Priority), as does my modem.

Presently, the line *is* configured for Annex A, until I get this sorted out, and presently the IVR reports Annex A whether the line is up or down. Under Annex M, however, the IVR reports Annex M when the line is down, Annex A when it is up. I've tested this repeatedly, switching between the two profiles several times during my testing. It's this inconsistency that leads me to believe there is in fact a problem.

Is it normal to see my Uncancelled Echo jump from -13.6dB to +19.6dB as well? The Xyxel device at my office didn't do this when switched to Annex M, according to the rep I spoke to on the phone when making the switch (as the Xyxel doesn't report UCE as far as I'm aware).

[dane]

What are your sync rates displayed in the modem in the two different settings? You mentioned 20Mbps and 12Mbps, but not the upstream rates. Will you reply with the full details?

Not sure about the uncancelled echo change.

[bronscon]

Upstream sync goes from roughly 1.6mbps to about 3mbps as I would expect with Annex M. Some loss of downstream is definitely expected, but I didn't expect 40%.

What's most concerning to me is that the modem still says Annex A and the IVR indicates Annex A when the line comes back up, although it indicates Annex M while the line is in the process of resynching (as well as if I disconnect the line or power down the modem; the IVR reports Annex M any time it is configured as such and the line is down, but Annex A any time the line is up, regardless of configuration). When configured for Annex A, the IVR reports that correctly regardless of whether the line is up or down.

If this is normal behavior, I'll accept that and move on, but if it's not then either my modem is faulty, the line card is faulty, or there is a bug in the IVR.

I'll play with Annex M via the IVR again a little later today and post actual stats in both configurations.

[bronscon]

I have been busy debugging (from the outside) a network issue with my company's hosting provider's network. They installed an intrusion detection system that went haywire and decided my IDE was trying to hack their network... fun stuff... The good news is that I pinpointed the exact issue (I'll leave it for them to find the cause and fix it) and implemented a workable fix for myself in the meantime... that's 14hr I'm not getting back because that particular provider doesn't keep a network engineer on staff or answer tickets during normal business hours...

Back on topic, though... I'll get the actual line stats for Annex A vs Annex M tomorrow evening since I didn't get to it tonight.

I have to say I really do appreciate Sonic.net's support. Every time I've called in they've been helpful and the only time there wasn't an engineer on staff is when I've called at some odd hours. Getting a reply from one of the founders for a tiny issue like this is just awesome!

[bronscon]

Hah, so I couldn't sleep... here's the Annex A and M stats:

Annex A:


Annex M (despite what the Protocol line claims):


You can ignore the downstream output power on the Annex M slide, I took that screenshot before the line settled down and didn't notice it until after I switched back to Annex A. That would normally be 0.0dBm as expected; all other stats are typical, so the slide is still an accurate representation once that downstream output power is taken into consideration.

It's not as drastic as I had recalled; my DS rate takes a roughly 5.25mbps hit rather than the 8mbps hit I was thinking of; however, I had also recalled an upstream sync of near 3mbps, which was also incorrect. I'm questioning whether a 600kbps gain in upstream is worth a 5.25mbps loss in downstream, especially given that "in theory" the upstream and downstream are supposed to exchange 1:1 (according to wiki, at least).

I know that theory and reality are typically vastly different beasts, but coupled with the weirdness in what the IVR and modem report, as far as profile, when configured for Annex M, leads me to believe that a problem does exist somewhere.

From where I'm sitting, one or more of the following is true: I have a faulty modem, I'm on a faulty line card, the Pace firmware has a bug that causes it to report Annex A even though it's configured for Annex M, or the IVR has a bug that causes it to report that a line configured for Annex M is using Annex A when it is up. The last two are easy enough for Sonic.net to test for without a service call; grab a known-working Pace 4111n, wire it up to a known-good line card, configure Annex M; if the modem says Annex A it's a firmware bug, if the IVR says Annex A it's an IVR bug. If One or both of those things doesn't happen, then I'd like to move forward with replacing my modem and/or being moved to a new line card or having the one I'm currently on replaced.

I think that's reasonable; make sure there's a problem before throwing equipment at it, and throw equipment at it if needed. And it's based on sound reasoning that, if everything is working correctly, the modem and IVR should both be reporting Annex M when the line is configured for it; so it's certain that a problem exists, while it's simply unknown, at this point, where that problem happens to reside.

I understand that I'm just one customer and that doing any kind of testing like I'm suggesting is likely viewed as excessive in the light of one single customer. If this happens to be a Pace firmware bug or an IVR bug, however... well then it's not just one customer. And honestly I'd rather see the larger problem get fixed before my little "nothing" issue (seriously, I have a stable and reliable connection, look into the possibility of a firmware or IVR bug before servicing me on this little issue) if such a problem does exist.

[dane]

I'd say there's an issue with the display in the Pace, and the readout by the IVR. I've asked staff to look at both. (On the Pace, we have this issue in another model we are testing, so it's a known bug and is already in the fix list.)

> given that "in theory" the upstream and downstream are supposed to exchange 1:1 (according to wiki, at least).

No, 1:1 (lose 1Mbps down for 1Mbps gain up) is not the case. The drop in downstream you are seeing is typical for Annex M. Generally we see losses of 25% to 50% of the downstream, for gains of 50% to 150% upstream.

[bronscon]

I'm cool with that response. Glad to hear that the firmware thing is a known issue that's already being looked into. The IVR really threw me off the first time I checked the line status and it agreed with the modem. My first thought was that's not even possible since I'm synching several hundred kbps higher than the theoretical max for Annex A.

I'm wondering if that 1:1 I've seen mentioned in several places is referring to percentage rather than bit-for-bit. That does seem to correlate with what I'm seeing, a roughly 31% drop in downstream but just shy of 35% boost in upstream. I'd really like to think that literally every article I've read on Annex A vs Annex M isn't totally wrong; and of course that's based on lab conditions at any rate, so it doesn't really disagree with that you said above, either.

Thanks for the responses; I guess my next step is to upgrade to 2 lines so I can have the upstream I need for work without my wife yelling at me for killing the downstream LOL