Talk:Optical Carrier transmission rates/Archive 1
This is an archive of past discussions about Optical Carrier transmission rates. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 |
CRS-1 for enterprise?
that's a new one for me. Last time I looked, the CRS-1 was solidly aimed at the ISP market, not enterprise. --Alvestrand 18:38, 23 February 2006 (UTC)
- You're quite right. Sound like someone is taking his CCNA a bit too seriously. --72.165.204.2 07:05, 25 February 2006 (UTC)
although I think the poster might have been correct if he'd replaced "enterprise" with "ISP" - OC-768 (40G) is indeed being rolled out in major backbones, and support of 40G interfaces is a design criterion for any serious new high-end router today. --Alvestrand 08:43, 25 February 2006 (UTC)
- Whos backbone? ... The pre-existing optical transport gear can't support it without special (and insanely expensive) coding transponders like those made by StrataLight and even then it's difficult to get an existing 10g wave carrying OC-768. Worse, the signal produced by such specialized transponders is non-standardized and non-interoperable. At the current time it's much cheaper to run four DWDMed OC-192s than a OC-768. There has been a lot of testing and some trials, but I don't believe that anyone is actually rolling it out.
- Now, as far as 40G interfaces as a design criteria for a router.. If you're talking about a router positioned at core provider networks, then I'd agree. But there are only two vendors who really have market share in that space: Juniper Networks and Cisco Systems.... and both of them offer OC-768 interfaces on their highest end boxes. So the point is somewhat moot. --72.165.204.2 16:53, 25 February 2006 (UTC)
Unsupported claims
The article previously contained a number of claims which I feel confident are inaccurate, specifically that OC768 was already replacing OC192 in large scale networks, and that 10GE is more popular in 'carrier grade' networks than OC192. Direct experience tells me that both of these claims are inaccurate enough to be laughable, and I can find no citations to back them up... So I've removed them.
The article also seemed to imply that 10GE is used over OC192 for internet traffic links because 10GE provides more bandwidth. Even under best case conditions for internet traffic on 10GE (1500 byte packets), 10GE only provides 2.36% more bandwidth. SONET's troubleshooting tools (alarms, and link trace, BER measurment) and OAM (which is not yet standard for ethernet) would justify the selection of SONET over ethernet against a 2.36% gain in any carrier enviroment. Worse, common internet traffic has a mean packet size around 300 bytes (and it's on its way down due to VoIP and other real time services), and at 350bytes/packet OC192 carries about 5% more capacity than 10GE. --Gmaxwell 19:53, 18 October 2005 (UTC)
- I agree with you Gmaxwell, and i agree with your edits. However, i feel the sentence, as it currently is, is totally confusing to the reader. The sentence i mean is, "Although OC-192 operates at a somewhat slower line-rate than 10GE, it provides greater capacity for internet sized packets because Ethernet has higher per-packet overhead." Ommitted are: line rate of 10GE, and the definition of an "internet sized packet'. I think it would be great if you converted what you wrote above into information in the article. Remember, right now, we don't have a "too much information" problem, we have lack of information problem, so feel free to add as much as you can. — Fudoreaper 06:41, 28 October 2005 (UTC)
- Gmaxwell asked me to comment on my changes with regard to comparing 10 GbE to OC-192. Specificly, I deleted "Although OC-192 operates at a somewhat slower line-rate than 10GE, it provides greater capacity for internet sized packets because Ethernet has higher per-packet overhead." because I felt it wasn't accurate since OC-192 does not always provide greater capacity, even with the qualifer about "internet sized", a term which isn't likely to be well understood by most audiences. I work in the industry, and I can't even be sure I understand what "internet sized" means. I think I have a good guess, but a layman would have no chance. Back to the issue at hand: per-packet overhead depends upon packet size (as discussed above), just like data inflation with HDLC depends on data content. Either the discussion needs to go fairly indepth to explain the comparison, or, in my opinion, it shouldn't be made since it is not important to explaining what OC-192 is. Mentioning it in passing simply invites misunderstanding by a large part of the audience. But this is in the past, working with what the article has now -- I see Gmaxwell updated it, and I like the improved wording about inter-operating. I question, however, if we really need the diversion about 10GE-LAN. Would it not be enough to just say OC-192 is compatible with 10GE-WAN and leave the LAN vs. WAN discussion in the 10GE article? I've thought quite a lot about what else could be added to flesh out this article - and honestly, I don't think there is much. Most of the info should be handled by the SONET article - almost to the point where I find myself wondering if the OC-n articles shouldn't just redirect to SONET (or be combined into the Optical_Carrier page). Mrand 05:33, 17 March 2006 (UTC)
- We should probably have an entire article on link encap efficiency, you're right that the text is somewhat misleading if we over simplify. I just don't want to go do the converse route of misleading people to believe that 10GE always has higher capacity. :)
- As far as LAN vs WAN... It *pains* me to mention 10GE Wan PHY without some clarification.. I don't have hard data in front of me, but I'd still be willing to bet that most 10GE wide area links are currently LANphy over wave.. The name is somewhat misleading.
- As far as merging and redirecting, I'm all for it.. The proliferation of articles on speculative SONET speeds has been making me sad for a while. --Gmaxwell 05:42, 17 March 2006 (UTC)
Consolidation of Optical Carrier pages
Hi guys, I've consolidated all the OC-<whatever> pages to Optical Carrier, and the Talk pages of OC-192 and OC-768 --NigelJ talk 23:12, 28 April 2006 (UTC)
Cost?
- How much do OC-192 lines cost?
- How much does the a fancy house cost? :) Your question is a bit too broad to answer, if you're talking about a OC-192 link from point A to B we need to know where A and B are. If you want to know what an OC-192 worth of internet connectivity costs, that too is hard to answer because, like many other high end things, such purchases are negotiated on a case by case basis. --Gmaxwell 03:24, 26 February 2006 (UTC)
- OK, but what ballpark are we talking about?
- Please sign your comments. Ask a Tier-2 internet provider. They sell the stuff if I'm not mistaken. -Thekittenofterra 11:12, 30 December 2006 (UTC)
- OK, but what ballpark are we talking about?
- How much does the a fancy house cost? :) Your question is a bit too broad to answer, if you're talking about a OC-192 link from point A to B we need to know where A and B are. If you want to know what an OC-192 worth of internet connectivity costs, that too is hard to answer because, like many other high end things, such purchases are negotiated on a case by case basis. --Gmaxwell 03:24, 26 February 2006 (UTC)
OC 2496
I am wanting to add external citations to this sectionCyberdyneinc 18:09, 4 April 2007 (UTC)
- The issue really is here that Cyberdyneinc continues to maintain that a OC 2496 network is being devloped by a company he appears to be affiliated with while at the same time failing to cite any reliable or verifiable sources. It appears highly unlikely that such a project would exist without there being any references to it, starting with (but by no means restricted to) on the pages of DARPA. As things stand, no such references exist.
- It would also be fairly odd if a standard out of step (normaly 4x - for example, going from 192 to 768) from the common multiplies of lower-bandwidth standards (2496 is 13 x 192 and thus not a multiple of 768) would be developed, thus additing this to teh category of extraordinary claims requiring extraordinary proof.
- —The preceding unsigned comment was added by Sander (talk • contribs).
- Looks like the referenced site has fallen victim to Go Daddy now. In any case, claims like these cannot be kept merely on the basis of ludicrous claims made by a company itself — without any reliable secondary sources. I am removing the section now. -- intgr 08:21, 9 April 2007 (UTC)
- Gentlemen, This issue presented clearly is a as a reaction to lack of infomation , a visbile pattern of unsupported justification for repeated harrasment during introduction of important contributions to the state of the Art. a visble level of contempt is displayed (please define you term NORMAL? Please define justification of DARPA being the AUTHORITY for Independant R&D? Please leave the section alone until we can complete our citiations, clearly you you would be in gross error to believe that just because you can not find something in a search engin it is not real? clearly biased behavior... the reference to the dead link via godaddy is a result of moving our data back to our servers a if that is a need to know, furthermore the links provided are were test, User Intgr? do you have a purposed behind you visble harrasment? Cyberdyneinc 05:12, 11 April 2007 (UTC)
Unsupported justification? Harrassment? Important? "Clearly biased behavior"? Well, excuse us for wanting to remain reasonably true, but the only thing you've managed to turn up is a SINGLE Power Point presentation on a company's web site, which is NOT a reliable source according to Wikipedia's policies.
Until you have produced a "proper citation" of a single reliable source to the article, this information will stay out of Wikipedia. The fact that it doesn't get a single relevant hit on Google is simply an indicator that there probably are no reliable sources conveying this information, thus your R&D does not exist for the purposes of Wikipedia. Repeated adding of unsourced material is taken as vandalism and you will be blocked if you continue your current behavior.
Quoting verifiability policy: "The burden of evidence lies with the editor who adds or restores material. Any material that is challenged or likely to be challenged needs a reliable source, which should be cited in the article. If an article topic has no reliable, third-party sources, Wikipedia should not have an article on it." -- intgr 05:46, 11 April 2007 (UTC)
- On the other hand, if you would like to report me for "harrassment", removing cited/reliable information, being biased or whatnot, you are very welcome to do so at requests for comment, requests for mediation or requests for arbitration. It would save me the trouble of having to fight you — they would do it for me. :) -- intgr 06:16, 11 April 2007 (UTC)
TAKE NOTICE SIR YOU HAVE BEEN SUCESSFUL IN YOUR ABILITY TO HINDER SHARING OF INFORMATION AND GAIN ATTENTION FOR IT !!
SPECIAL NOTICE 11-APRIL-2007
AS MANY OF YOU ARE AWARE, WE HAVE BEEN WORKING TO ARRANGE AND ADD OUR RESEARCH TO WIKIPEDIA BASED ON THE MAJOR CONTRIBUTION OUR WORK HAS HAD AND WILL CONTINUE TO HAVE ON TECHNOLOGY ADVANCEMENT THESE EFFORTS HAVE BECOME DIFFICULT AND IMPOSSIBLE DUE TO ACTIONS OF UNETHICAL BIASED ACTIONS OF INDEPENDNANT EXTERNAL CONTENT EDITORS FOR WIKIPEDIA. IE USER:intgr IE User:NijelJ
AS A RESULT OF ACTIONS WE WILL HAVE TO DEPLOY ALL OF THE RESEARCH VIA OUR OWN INTERNAL WIKI :THIS PROCESS WILL TAKE TIME TO COMPLETE: WE APOLOGIZE FOR ANY DELAY IN RECIEVING ACCESS TO OUR RESEARCH PAPERS. (this notice will run via all of our domains internal and external until such time as as we complete our deployment) Cyberdyneinc 14:48, 11 April 2007 (UTC)citation
- Oh, that is comforting to hear. You finally figured out that you're not supposed to publish original research on Wikipedia? -- intgr 14:47, 11 April 2007 (UTC)
High rate OC launchings
(re:Launched for testing in Sydney, Australia: 22/08/2007. Test is being compounded by SCN Global, a devision under the SAVVIS Network. additions). When the "testing" phase of these higher rates is completed, it would be appropriate to change the repective sections to indicate this - but not to "spam" each section with a link to a given site. -- MarcoTolo 03:41, 23 August 2007 (UTC)
OC-7144F
Never heard of such a thing as OC-7144F. Google hasn't, either. And the cited speed doesn't follow the pattern. The edit adding OC-7144F seems to have been inserted between OC-3072 and the reference citation for OC-3072. The reference has nothing about any oddball OC-7144F. I'll let someone else add OC-6144 after finding an appropriate reference. There are a few pages Google finds on OC-6144, so there does seem to be some work in that direction. But I'm not going to research it right now. 76.125.202.149 (talk) 22:49, 18 May 2009 (UTC)
Nonstandard and higher SONET
The classification of "in-use" and "unused" is misleading. ANSI/ATIS T1.105.1 p. 11 states that "In the range of 1 to 768, this standard recognizes only certain values of N. These values of N are: 1, 3, 12, 24, 48, 192, and 768." also indicated by Table 1. The only standard rate that isn't a multiple of is OC-24, and the article correctly notes that this is rare (at best). I see no reason to list OC-256, OC-384, or OC-1536, as I've never seen any serious reference to them, and it is highly unlikely that these rates will ever be standardised or deployed. They definitely fall under "original research" and should be deleted. OC-3072 is generally recognised as the next logical rate to be standardised by ATIS and the ITU, but there isn't currently motivation to do so, given that the current cost and engineering tradeoffs favor WDM of multiple OC-192 rates. Therefore, I think that the "in-use" part of the heading should be removed, OC-3072 folded in with the note that it is the next logical rate that is likely to be standardized when and if there is reason to do so. If I don't see any objection here, I'll fix this in the near future.
There should also be a list of virtual tributary rates for VT1.5, VT2, VT3, and VT6, and cross reference to the SDH article. Jpgs (talk) 17:48, 21 April 2008 (UTC)
I agree and am removing oc96, as I have removed others in the past. Is there public access to your source? Full Decent (talk) 20:39, 28 October 2009 (UTC)
I just noticed Fuldecent's comment on my talk page. Thanks, but OC-96 is back! OC-96 is *not* a standard SONET rate, as I indicated above. I'm removing it again. 24.124.83.153 (talk) 16:40, 27 February 2010 (UTC) Didn't realise my login session had timed out; now properly signing: Jpgs (talk) 16:44, 27 February 2010 (UTC)
OC-45
There seems to be a limited number sources out there what mention a specification or standard known as OC45 with speeds claimed between 2.5/Gbps and 4.5/Gbps. Can anyone comment on if this "OC-45" standard actually exists and can anyone provide a bit of info on it such as what it's maximum speed is and when and where it is used? Most articles regarding the OC-45 specification date from around 2000, so I guess it is one of the older OC-XX specifications. None the less, why no mention of it on the main article? Below are the sources I found:
Sources Below:
212.159.114.107 (talk) 19:05, 4 September 2015 (UTC)
There has never been an OC-45; it is not even possible from the Bellcore/Telcordia, ANSI T1 (or in SDH-equivalent) ITU specs. Sources [1] and [2] are content free and not credible, [3] is almost certainly a typo for OC-48, and [4] is probably a typo for OC-48 as well. Jpgs (talk) 10:50, 6 October 2015 (UTC)
References
- ^ http://board.flashkit.com/board/showthread.php?10435-Fastest-connection-speed
- ^ http://discussions.virtualdr.com/showthread.php?9129-free-unix-shells-with-300mb-5-free-eggdrops-on-a-OC-45-backbone
- ^ http://conta.uom.gr/conta/ekpaideysh/metaptyxiaka/technologies_diktywn/ergasies/2006/Core-Backbone%20Networks.pdf (Page 24)
- ^ http://fiberhosting.com/mission.htm
Inconsistent payload rates
The payload rates cited for the different OC-N levels are not self-consistent. In particular, the payload rate for OC-3 includes a deduction for path overhead, while the others do not. This leads to a situation where the payload from three OC1s would not fit into the payload of the OC-3, which is contrary to the principle of SONET/SDH.
Although there is a notation in the OC-3 entry that path overhead has been deducted, there is no notation pro or con on the other rates, which makes the page confusing for readers.
I lean toward including path overhead in all entries, but I don't have personal expertise, so I have not edited anything. I note that the page on Synchronous optical networking omits path overhead for all rates.
Ultimately, the page should be self-consistent and clear. Does someone have the expertise to say whether path overhead should be in all entries or no entries?
Mdfeuer (talk) 16:09, 8 November 2015 (UTC)