dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
15657
share rss forum feed

ConstantineM

join:2011-09-02
San Jose, CA
reply to ConstantineM

Re: AT&T U-verse FTTP speeds, why do they limit fibre to 18/1.5?

I looked more at what people say about U-verse. People mention that watching TV slows down the service. My conclusion: if I really do have 30/3.6, and that's the line limit, AT&T should have absolutely no problems whatsoever getting me onto the 24/3 internet profile, it's going to make my internet faster, and even TV would still continue to work.

(This reminds me of the double standards of Sprint, where only those who were subscribed to 1.5Mbps were (in my opinion fraudulently) provisioned with the inferior 512 service if their line was rated for below the full 1.5 sync, whereas everyone with higher plans was getting their full provisioning, even if it meant synching below their expected maximum rates.)

I'm looking for an AT&T U-verse sales/tech person who could sign me up for 24/3 package, and then I'm looking for a tech person who could do the provisioning. Any help is appreciated. I firmly believe that, apart from the ordering system itself, there is no known technical limitation of why my line cannot deliver faster internet; I kindly demand AT&T honours their price list and provides ability to purchase the internet service advertised.

WhyMe420
Premium
join:2009-04-06
kudos:1
reply to ConstantineM
If, and that's a big if, you were to somehow get 24/3 as an FTTP customer, you would be the first person in known existence on DSLR to be an AT&T U-verse FTTP customer to ever have accomplished such.

In other words, good luck in your quest, you're gonna need it.


ILpt4U
Premium
join:2006-11-12
Lisle, IL
kudos:9
Reviews:
·AT&T U-Verse
said by WhyMe420:

If, and that's a big if, you were to somehow get 24/3 as an FTTP customer, you would be the first person in known existence on DSLR to be an AT&T U-verse FTTP customer to ever have accomplished such.

In other words, good luck in your quest, you're gonna need it.

I echo WhyMe's sentiments, as well as the wishes of success.

I have enough trouble sometimes convincing tech support that FTTP can support 4 HD streams on IPTV, which I know for a fact can be done, but I still get roadblocks when I try to get FTTP customers upgraded to it

I have yet to witness a successful U-Verse FTTP 24/3 Internet customer, but that is not to say it is impossible. Just that to this point it has not been done that I know of, and the times I have attempted it I have been roadblocked.

Good Luck! And May the Force be with You


Um

@sbcglobal.net
You guys are all wrong. FTTPIP U-Verse is a different product, and because of it's smaller footprint it doesn't get the investment to keep up with FTTN. There are changes coming soon. The delay is software related, the hardware is perfectly capable of running the 32 and 55 profiles.


maartena
Elmo
Premium
join:2002-05-10
Orange, CA
kudos:3
said by Um :

You guys are all wrong. FTTPIP U-Verse is a different product, and because of it's smaller footprint it doesn't get the investment to keep up with FTTN. There are changes coming soon. The delay is software related, the hardware is perfectly capable of running the 32 and 55 profiles.

There is a "55" profile? Can you explain more about this profile, and when it will be made available to the public?
--
"I reject your reality and substitute my own!"


Um

@sbcglobal.net
Oops.

WhyMe420
Premium
join:2009-04-06
kudos:1
Yeah yeah, I'll believe it when I see it.


maartena
Elmo
Premium
join:2002-05-10
Orange, CA
kudos:3
reply to Um
said by Um :

Oops.

What, "Oops", it is a highly guarded corporate secret or something?

So there IS a 55-profile. If you are looking for testers, I am @ 800ft. from VRAD according to UVerse Realtime with a maximum rate of 59914.
--
"I reject your reality and substitute my own!"

WhyMe420
Premium
join:2009-04-06
kudos:1
said by maartena:

said by Um :

Oops.

What, "Oops", it is a highly guarded corporate secret or something?

So there IS a 55-profile. If you are looking for testers, I am @ 800ft. from VRAD according to UVerse Realtime with a maximum rate of 59914.

Your line wouldn't be able to handle it as any profile over 80% of line capacity will likely be unstable.

ConstantineM

join:2011-09-02
San Jose, CA
Come on, guys! Proper lines with proper wirings and lack of non-normal interference, which are merely distance-limited, would be totally fine to work at 100% capacity. And, equally, nearby lines running at the max. I'm not familiar with VDSL/VDSL2, but based on my prior ADSL research, and personal experience with having a far-away brand new line that would sync and later show around 100% relative capacity occupation at about 1.2Mbps downstream with ITU G.992.1(G.DMT) with ZyXEL P645ME+ back in 2005 (being finally provisioned against the protocol for the unattainable 1.5), running at full capacity should be totally acceptable in the majority of cases.

All of these xDSL standards have a lot of engineering provisions about keeping the line stable, including automatic speed downgrades if the line becomes less stable, etc etc. All these artificial limits imposed by monopolistic telcos are merely a way to generate more revenue through tiered speeds, and, perhaps, also ensure that the minority of people that'd have problems with higher speeds simply would not get those higher speeds for any potential of having any problems whatsoever.

I'd argue that a crappy non-compliant line that can't be stable at all at 100% would also most certainly lose sync often enough even at 80%, yet a good line would run for days or weeks at a time at 100% (achieving either high speeds should it be nearby the CO or VRAD, or low yet consistent speeds should it be far away).

WhyMe420
Premium
join:2009-04-06
kudos:1
said by ConstantineM:

Come on, guys! Proper lines with proper wirings and lack of non-normal interference, which are merely distance-limited, would be totally fine to work at 100% capacity.

Nope. The VDSL needs FEC overhead in order to reliably keep sync at the profile used. When you use 100% of the line capacity, you almost always run out of reserve bits and usually end up over-committing the amount of bits required for the profile. Thus, line instability.

said by ConstantineM:

I'm not familiar with VDSL/VDSL2, but based on my prior ADSL research

Your post really shows that fact. I would recommend not stating "come on guys!" if you're not familiar with VDSL and wish to make claims against others. ADSL and VDSL are entirely different beasts. VDSL uses much higher frequencies which tend to attenuate a lot easier than ADSL. It's a pretty well-known fact around here by the regulars that 80% or less of the line capacity will be a lot more reliable than greater than 80%.

All the Max Rate is, is a number in which the VDSL modem was able to send a short burst of data through the line. It is by no means an actual indication of your line's capabilities. It is more of an estimate.

ConstantineM

join:2011-09-02
San Jose, CA
Funny you mention it, I was told the very same thing about ADSL and the 80% relative capacity occupation rule by all the regulars of the Sprint / Embarq forum (in fact, they even exercised much more firmness and certainty in the correctness of their rule than your prior post above), so I have no reason to believe that VDSL is any different, since all the sayings are the same, even the magic percentage points of the rule don't differ. (-:

The DSL equipment is obviously designed to withstand normal minor fluctuations of the line, so I'm still firm in my belief that there is no technical reason why lines would be unstable to the point of being unusable if they run at 100% capacity with no artificial limits imposed. ADSL can downgrade the sync speed if needed without loosing the connection at all (my ZyXEL did that flawlessly); I recall that ADSL2 or variants included provisions to reclaim the capacity back should line conditions improve (G.DMT can only go down or resync, but cannot go up without resync). I'm pretty sure VDSL should have similar provisions, being both moderate in the original sync speed, as well as being able to downgrade if the speed cannot be sustained, else VDSL would be fundamentally broken as a standalone protocol.

WhyMe420
Premium
join:2009-04-06
kudos:1
Just because it doesn't lose sync doesn't mean it's not dropping packets. Sure, for TCP connections, it can simply retransmit the data, but for UDP, once a packet is dropped, that's it. When it comes to U-verse TV, dropped packets are not tolerable as they will cause picture/audio problems. Online gaming as well can't tolerate a lot of dropped packets. There's plenty of other things as well that can't tolerate dropped packets.

Regardless of what your equipment does, the U-verse VDSL equipment does not keep sync when the profile is dropped due to marginal line conditions. It will drop sync, then retrain to the lower profile, but, as I said already, at greater than 80% capacity there is no room for error correction, so basically the integrity of the line is not there, and there is no room at all for variances (thunderstorms, squirrels, temperature, rain, etc.)

So yeah while it might work (barely,) it's not what most people want. I can almost guarantee you that with over 80% line capacity being used, there will be uncorrectable blocks and sooner or later sync issues.

ConstantineM

join:2011-09-02
San Jose, CA

the 80% rule

I can only talk about my prior experience with G.DMT, and extrapolate to VDSL. However, back in the day I was explicitly told that my line would be unstable if they change my profile from 512 to 1.5 profile, by both the multiple official technicians that claimed it was impossible, as well as the regulars at dslreports, yet there I was afterwards, with my line syncing at 1.2Mbps and nearly zero CRC error count, with very minimal FEC error count, too (I was on interleave for the extra stability).

Packet loss is even more horrible with TCP than it is with UDP, and I recall having no packet loss for the many weeks I had been running at 96% downstream and 76% upstream, with effectively no artificial cap on the downstream speed whatsoever, with only the upstream being limited by the profile. So I'm here to say again that the 80% rule holds not much water: line is either really stable at 80% and pretty stable uncapped (e.g. near 100%), or it's hardly stable at 80% and quite unstable at 100%. There is no magic 80%. It's either a good line, or a bad line. I'd say even distance is irrelevant, based on my prior research as well as my old awesome 1.2Mbps far-away line that worked perfectly even after it was set free. Of course, there may be exceptions, but I'm convinced my case was not an exception instead.

WhyMe420
Premium
join:2009-04-06
kudos:1
Sorry, but you're just talking outta your a**, first of all stating that TCP packet loss is worse than UDP, second of all saying "there is no magic 80%," when in fact 80% is the "magic" number as that is when you run out of reserve bits.

ConstantineM

join:2011-09-02
San Jose, CA
Of course TCP packet loss is worse than UDP, as the sliding window makes your throughput considerably slower than just mere retransmission. That's one reason TCP is not used for streaming video, as it would make it unacceptably slow very easily with just minimal, yet consistent, packet loss.

BTW, why are we even talking about TCP or UDP packet loss in the first place? Does VDSL, unlike ADSL, not support CRC and retransmission, as well as FEC? I think you're the one who doesn't know what they're talking about.

And what's so magic about 80% anyhow? Why do you need reserve bits in the first place; are you suggesting that unlike dialup and ADSL, and ADSL2, that VDSL/VDSL2 cannot simply downgrade the sync rate without loosing a connection? Because all these other mentioned technologies do that just fine!

WhyMe420
Premium
join:2009-04-06
kudos:1

1 edit
said by ConstantineM:

Of course TCP packet loss is worse than UDP, as the sliding window makes your throughput considerably slower than just mere retransmission. That's one reason TCP is not used for streaming video, as it would make it unacceptably slow very easily with just minimal, yet consistent, packet loss.

Actually TCP is used in many forms of streaming video. It's not worse with TCP as, yes, throughput is slowed down, but at least it is retransmitted. When UDP packets are dropped, it is not retransmitted, thus, the data is lost for good. Not a hard concept to grasp.

said by ConstantineM:

Does VDSL, unlike ADSL, not support CRC and retransmission, as well as FEC? I think you're the one who doesn't know what they're talking about.

Your ignorance is shining here, as none of the xDSL technologies retransmit data. When the line is interleaved, FEC corrects errors in real time. If FEC is unable to correct the error, using the extra redundant data, then a CRC error is produced. CRC has nothing to do with retransmission. A CRC error means that the data is lost. That is why 80% is an important number, as the rest is needed for the redundant FEC overhead. Again, not a hard concept to grasp.

said by ConstantineM:

And what's so magic about 80% anyhow? Why do you need reserve bits in the first place; are you suggesting that unlike dialup and ADSL, and ADSL2, that VDSL/VDSL2 cannot simply downgrade the sync rate without loosing a connection? Because all these other mentioned technologies do that just fine!

None of these technologies do what you are saying, at all. If there are too many errors, the connection will lose sync and retrain. It's pretty amusing that you think that you are smarter than everyone on Earth, including technicians. Just like in the beginning of this thread, you were expecting to be the only person on Earth to have AT&T FTTP and 24/3 Internet.

EDIT: Here we go, just to seal the deal, a PDF relating to Broadcom PhyR, a new and little-used xDSL data retransmission system, that also explains how FEC, Reed Solomon, and Interleaving, do their job:

quote:
The RS + Interleaver scheme suffers from a high overhead burden because for every errored byte, two
additional overhead bytes must be transmitted to allow for a successful FEC correction. For example,
assuming that an overhead of 10% correctable is tolerable, correcting a burst of 1 ms of impulsive noise
(INP = 4 DMT symbols) requires an interleaver depth (or delay) of minimum 10 ms:

INP (ms) = ½ OH . delay (ms)

The ITU amendments mentioned above do not change anything in that fundamental limitation and only
intend to be as close as possible to the formula without introducing additional framing limitations.
Figure 1 clearly illustrates the capacity losses on an ADSL2+ system that complies with latest ITU
amendments for increasing INP when delay is constrained to 8 ms. When INP is set to 4 and at 16 Mbps
(4 kilobits per symbol), capacity loss is about 20%!
Source: »www.broadcom.com/collateral/wp/X···01-R.pdf (page 3)

Notice that 20% number thrown in? What's 100% minus 20%? That's right, 80%. I rest my case.

As for the TCP/UDP thing, page 2 explains it just right:

quote:
ADSL has been a huge success for fast Internet access, but the job was rather easy from a service perspective;
rates are still fairly low (only a few Mbps) and Bit Error rate (BER) requirements are not too
stringent, as the TCP-IP retransmission protocol effectively hides transmission errors at these rates.
With the evolution towards IPTV, much lower BER figures are required. Typically, multicast video
streams are no longer protected by native retransmission protocols, no more than one error per movie is
allowed (equivalent with a BER lower than 10-10 for a 120’ movies at 20 Mbps), and application-level
retransmission protocols are expecting Ethernet-level BER to scale economically.
Therefore, it clearly explains that TCP makes it easier to accept line errors, whereas UDP and other protocols (such as used in certain video streams, online gaming, VoIP, etc.) require a lower BER, therefore they are not as tolerant to line errors.

Very simple concept.


Metatron2008
Premium
join:2008-09-02
united state
Well he may be wrong on those issues, but coming in expecting to have the same speeds as people on copper is certainly a feasible argument to have.

WhyMe420
Premium
join:2009-04-06
kudos:1
Well, it is pretty ridiculous how AT&T's FTTP is limited even more-so than their FTTN, but sometimes you just have to face the facts of life. The fact of the matter is that nobody on AT&T FTTP has accomplished what OP is wanting to do to this date. Hell, I would like to expect to have the same speeds as FiOS customers, but the fact of the matter is that Verizon doesn't serve my area, and even if they did they probably wouldn't deploy fiber around here.

dave006

join:1999-12-26
Boca Raton, FL
Actually FTTP customers were provisoned above FTTN customers when the highest service profile was UvClass10 Stream Profile - 25Mbps profile (25/2). They were all at 30/3.6.

FTTP customer also still have a very big advantage in a very low latency connection, great for gaming! FTTP customers also don't have to worry about being put on a UvClass9 Stream Profile - 19Mbps profile (19/2) due to distance from the VRAD.

As has been previously indicated, until the hardware / software is upgraded on the FTTP plant, only the 30/3.6 profile is available.

Dave

WhyMe420
Premium
join:2009-04-06
kudos:1
Agree with everything Dave . Though as it currently stands FTTP is (artificially) at a disadvantage in the bandwidth department, and 1.5Mbps upload is pretty bad for FTTP, IMO. Heck, I'd probably still choose it though, (that is, if I actually had a choice.)


DataRiker
Premium
join:2002-05-19
00000
reply to WhyMe420
said by WhyMe420:

Well, it is pretty ridiculous how AT&T's FTTP is limited even more-so than their FTTN,

Ridiculous?

I would say more like semi-retarded and primitive. ATT's home run swing!


Metatron2008
Premium
join:2008-09-02
united state
said by DataRiker:

semi-retarded and primitive

Now you know the secret to how the death star works


ConstantineM

join:2011-09-02
San Jose, CA
reply to ConstantineM

Alcatel HONT-C "155.52 Mbps upstream and 622.08 Mbps downst

I did a bit of research to find out the exact numbers as they relate to my equipment installed.

I found out that the ONT that I have is an Alcatel HONT-C, which supports "155.52 Mbps upstream and 622.08 Mbps downstream", according to Alcatel's specification. (This is an exclusive from ConstantineM, you won't hear it elsewhere! Noone seems to know what ONTs they have with U-verse!)

As it's a PON device, where a 16, 32 or 64 beam splitter must certainly be used for cost savings, this bandwidth is shared between all the 16/32/64 users, but, luckily, the notion of oversubscription of bandwidth is supported, according to wikipedia.

I presume AT&T is using either 32- or 64- beam splitters? In any case, these numbers clearly indicate a relationship of 4/1 of downstream/upstream bandwidth. I believe the total capacity in each direction is fixed regardless of distance (it either works or not), and I would equally imagine that there won't be any savings by leaving any of this bandwidth unused, since the downstream and upstream are entirely separate.

This brings into question why instead of going with something like 30/7.5 profile for FTTP, AT&T supposedly provisions FTTP with 30/3.6 instead, whereas FTTN VDSL gets 32/5.
Not sure if this is not news to other people, but IMHO this certainly brings it up to light the fact that there are really no hardware limitations whatsoever in offering 24/3 package to FTTP customers. In fact, I'd argue that the upload speed should really more closely represent the technology at hand, and the HSI offerings over FTTP should be something like 6/1.5, 12/3, 18/4.5 and 24/6, and not the outdated copper-style 6/1, 12/1.5, 18/1.5 and 24/3. In fact, since some speed must be reserved for AT&T's IPTV, which mostly (or even always) is to occupy the downstream portion of the connection, the upstream HSI spec offered might even be higher than that 4:1 ratio compared to downstream.

Not exactly sure about VDSL specifically (sorry, don't feel like researching technology I might never end up using!), but I think with copper as you get further away on the loop distance, any extra frequency you'd use in upstream, would have to dip into your downstream potential, so with VDSL, it indeed might make some sense to offer disproportionally lower upstream than downstream. However, with FTTP and fixed light capacity in both directions with a 4:1 ratio, it simply makes very little sense.

I want my 18/4.5! When you sell "18Mbps" (without upload speed being explicitly specified), and provide it via the above PON technology, it's only natural to assume that the upload speed would be exactly 4.5. Where's my 4.5? Why do I only get a third of that?


weaseled386

join:2008-04-13
Port Orange, FL
kudos:1
Reviews:
·Bright House
·AT&T U-Verse

Re: Alcatel HONT-C "155.52 Mbps upstream and 622.08 Mbps do

You need to look at it differently... you're barking up the wrong tree. You need to look at where FTTP and FTTN customers meet. Have you thought the limitation(s) may be the CO equipment instead? Stop looking at the medium its delivered on, and start looking at the equipment providing the stream.


houkouonchi

join:2002-07-22
Ontario, CA
Reviews:
·Verizon FiOS
said by weaseled386:

You need to look at it differently... you're barking up the wrong tree. You need to look at where FTTP and FTTN customers meet. Have you thought the limitation(s) may be the CO equipment instead? Stop looking at the medium its delivered on, and start looking at the equipment providing the stream.

I thought I remember hearing a AT&T employee say that VRAD's and stuff had like 10 gig uplinks or something?

The upstream still seems low but the 30 meg sync rate makes sense for bpon on uverse. With all the people using IPTV the network bandwidth would be a lot higher than say with FIOS where TV is handled on a different wave length and the full 622 megabits down is used for internet only (or 2.4 gigabits if on GPON like I am). Even if multicast is used I would think a big chunk of that 622 megabits would be used for TV traffic if split between 32 users.
--
150/75 mbit Verizon FiOS connection FTW!


weaseled386

join:2008-04-13
Port Orange, FL
kudos:1
Reviews:
·Bright House
·AT&T U-Verse
said by houkouonchi:

said by weaseled386:

You need to look at it differently... you're barking up the wrong tree. You need to look at where FTTP and FTTN customers meet. Have you thought the limitation(s) may be the CO equipment instead? Stop looking at the medium its delivered on, and start looking at the equipment providing the stream.

I thought I remember hearing a AT&T employee say that VRAD's and stuff had like 10 gig uplinks or something?

The upstream still seems low but the 30 meg sync rate makes sense for bpon on uverse. With all the people using IPTV the network bandwidth would be a lot higher than say with FIOS where TV is handled on a different wave length and the full 622 megabits down is used for internet only (or 2.4 gigabits if on GPON like I am). Even if multicast is used I would think a big chunk of that 622 megabits would be used for TV traffic if split between 32 users.

VRAD's for FTTN take 1G links, and its shared between 192 customers... with a possibility of 384 depending on the cabinets config. However, the Alcatel 7330 will not accept fiber and copper. A single VRAD is not the common point. You'd have to know if the FTTP people tie into the same Alcatel 7450/7500 equipment that the FTTN people do at the CO. For video we installed some sort of Fujitsu equipment, and they'd have to tie into it at some point... Dave006 would know much more about this than me, because I'm simply a hardware installing knuckle dragger

ConstantineM

join:2011-09-02
San Jose, CA
reply to weaseled386

Re: Alcatel HONT-C: 155.52 Mbps upstream / 622.08 Mbps downstrea

The CO can't possible have more strict limitation than the 622/155 PON G.983 FTTU hardware that is provided to the premises. Also, my complaint is now explicitly regarding upstream, and surely stuff at the CO has symmetrical bandwidth.

I looked more at the datasheet for HONT-C from Alcatel, and it seems like they suggest that 1:32 delivery must be used, e.g. all this 622/155 is shared by a mere maximum of 32 users.

155.52Mbps divided by 32 is clearly 4.86Mbps, as if the bandwidth could not be oversubscribed. In such light, the 3.6Mbps upstream part that, supposedly, everyone on FTTP is provisioned for, simply makes exactly zero (0) sense whatsoever. The alleged 30/3.6 FTTP profile should be more like 30/7.5 (if not higher in the first place), or, at the very least, 30/5 (with corresponding increase in HSI upload speeds), but not 30/3.6.

3.0Mbps is really the absolute minimum HSI upload speed that should be offered on the most expensive downstream package that's already been oversubscribed as far as FTTP profiles are concerned. This upload speed is a big value-add that comes entirely for free, yet rests absolutely unused and unaccounted for! This utter nonsense on AT&T's part is why stuff like internet hard drives still have virtually no place in our life today.


weaseled386

join:2008-04-13
Port Orange, FL
kudos:1
Reviews:
·Bright House
·AT&T U-Verse
All I see is wall of text, because you obviously are lost on this. Who cares what the ONT is listed for? It has NOTHING to do with the equipment thats installed in the field, and in the CO's.

The network card in my computer is 100M, and my switch is 1G. What does this have to do with anything? Nothing.

WhyMe420
Premium
join:2009-04-06
kudos:1
said by weaseled386:

All I see is wall of text, because you obviously are lost on this. Who cares what the ONT is listed for? It has NOTHING to do with the equipment thats installed in the field, and in the CO's.

The network card in my computer is 100M, and my switch is 1G. What does this have to do with anything? Nothing.

It's a lost cause arguing with this guy. He's some guy that came in 15 days ago on a load of turnips that thinks he knows more than the entire DSLR community. Almost starting to think he's a troll.