Not speaking on behalf of any company in particular, I just wanted to say I know of a number of 4500's and 4700's running in production with the ATM card. Their throughput is limited by the CPU performance, but you can expect to get upwards of 40Mbps through it. If you want more than an OC3 I would suggest you look at something like a 7600 OSR, not speaking on behalf of any company in particular of course. Now we just need a Telco or three in NZ to support ATM at STM-4 rates. Arron Scott -----Original Message----- From: owner-nznog(a)list.waikato.ac.nz [mailto:owner-nznog(a)list.waikato.ac.nz]On Behalf Of Dennis Su Sent: Tuesday, 20 February 2001 7:04 p.m. To: nznog(a)list.waikato.ac.nz Subject: ATM card in Cisco 4500 Hi, We would like to purchase a ATM card for a Cisco 4500. Someone has mentioned to us that its ATM card is not very stable, although I doubt it. 4500 series router has been on the market for such a long time after all. I wonder if anyone can give us some previous experience. Good or bad and what type, all welcome. Thanks, Dennis ------------------------------------------------------------------------ ---- ----------------- Dennis Su, BSc MSc Network+ MCP CCNA CCDA CCNP CCDP Team Leader, Network Admin and Development IT Infrastructure, ITS, University of Waikato Hamilton, New Zealand phone:64 7 838 4183 email:d.su(a)waikato.ac.nz http://network-services.its.waikato.ac.nz/people/dennis.html --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
Yep - if all you need is an oc3 then a juniper will be a very expensive solution for you. If on the otherhand you want to run lines of oc48 or oc192 at full wirespeed, then it's the box for you. Dean On Thu, Feb 22, 2001 at 02:17:09PM +1100, Scott, Arron wrote:
If you want more than an OC3 I would suggest you look at something like a 7600 OSR, not speaking on behalf of any company in particular of course. Now we just need a Telco or three in NZ to support ATM at STM-4 rates.
Arron Scott
--------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Thu, Feb 22, 2001 at 02:17:09PM +1100, Scott, Arron wrote:
Now we just need a Telco or three in NZ to support ATM at STM-4 rates.
Is anybody really waiting for that? If you're shifting an STM-4s worth of data around, it's probably a stream of packets, and it's probably IP, and you probably want to use POS. You probably don't want the additional complexity, cost, operational overhead, cell tax and SAR latency that using ATM would involve. Also, ATM is the work of Satan, which should be mentioned, for the record. Joe --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
At 09:49 22/02/2001 -0500, Joe Abley wrote:
On Thu, Feb 22, 2001 at 02:17:09PM +1100, Scott, Arron wrote:
Now we just need a Telco or three in NZ to support ATM at STM-4 rates.
Is anybody really waiting for that? If you're shifting an STM-4s worth of data around, it's probably a stream of packets, and it's probably IP, and you probably want to use POS. You probably don't want the additional complexity, cost, operational overhead, cell tax and SAR latency that using ATM would involve.
Also, ATM is the work of Satan, which should be mentioned, for the record.
Read and listen to the lyrics and marvel at the prescience of the King: www.elvispresleyonline.com/html/devil_in_disguise.html --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
Yeah Joe's right. Given the fact that there is no way of sar-ing over oc48, most major players are now moving to POS. Even if you don't need oc48 or oc192 now, it makes little sense to embrace ATM for a new network and then have to throw it in the bin next year anyway. Also the higher the speed the more the celltax costs you. Eg if you pay for an oc12 on southern cross then you loose the equiv of an oc3 in overhead. Thats a heckload of cash. Loosing an oc12 on an oc48 link is even worse. Long live wirerate oc192. Dean On Thu, Feb 22, 2001 at 09:49:20AM -0500, Joe Abley wrote:
On Thu, Feb 22, 2001 at 02:17:09PM +1100, Scott, Arron wrote:
Now we just need a Telco or three in NZ to support ATM at STM-4 rates.
Is anybody really waiting for that? If you're shifting an STM-4s worth of data around, it's probably a stream of packets, and it's probably IP, and you probably want to use POS. You probably don't want the additional complexity, cost, operational overhead, cell tax and SAR latency that using ATM would involve.
Also, ATM is the work of Satan, which should be mentioned, for the record.
Joe --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
dean(a)flatnet.gen.nz wrote:
Yeah Joe's right.
Given the fact that there is no way of sar-ing over oc48, most major players are now moving to POS. Even if you don't need oc48 or oc192 now, it makes little sense to embrace ATM for a new network and then have to throw it in the bin next year anyway. Also the higher the speed the more the celltax costs you. Eg if you pay for an oc12 on southern cross then you loose the equiv of an oc3 in overhead. Thats a heckload of cash. Loosing an oc12 on an oc48 link is even worse.
The 'cell tax' is 5 bytes of overhead for every 48 bytes of data, or about 1/10. So for OC12 (around 622Mbps), it's about 60Mbps, not 155, and for oc48 it's around 250Mbps. That is over an OC3, but much less than an OC12. In case you're interested, we have built a PCI card for passive monitoring OC48 POS. (no one wanted ATM, for some reason ;) fairly old page: http://atm.cs.waikato.ac.nz/wand/docs/dag4/ Research group pages (also old): http://wand.cs.waikato.ac.nz/ 'Sweating the small stuff' Stephen. -- ----------------------------------------------------------------------- Stephen Donnelly (BCMS) email: sfd(a)cs.waikato.ac.nz WAND Group Room GG.15 phone +64 7 838 4086 Computer Science Department, University of Waikato, New Zealand ----------------------------------------------------------------------- --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Fri, Feb 23, 2001 at 12:02:05PM +1300, Stephen Donnelly wrote:
The 'cell tax' is 5 bytes of overhead for every 48 bytes of data, or about 1/10. So for OC12 (around 622Mbps), it's about 60Mbps, not 155, and for oc48 it's around 250Mbps. That is over an OC3, but much less than an OC12.
The 5 bytes of header per cell is part of the cell tax; there's also the wastage caused by (a) AAL5 and possibly SNAP encapsulation, and (b) needing to populate an integer number of cells when the total frame-based payload is not a multiple of 48 bytes. Worst case, you will carry 49 bytes of payload per two cells. That's 57 bytes wastage in 106 bytes transmitted, or a cell tax of around 54%. The extent to which this effect is significant depends on the distribution of packet sizes in your traffic. Unfortunately, on the internet, a high proportion of packets are TCP ACKs with no data, which narrowly fail to fit inside a single cell. On the internet, a cell tax of 30% or so is quite normal.
In case you're interested, we have built a PCI card for passive monitoring OC48 POS. (no one wanted ATM, for some reason ;)
Cool :) Joe --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
Joe Abley wrote:
On Fri, Feb 23, 2001 at 12:02:05PM +1300, Stephen Donnelly wrote:
The 'cell tax' is 5 bytes of overhead for every 48 bytes of data, or about 1/10. So for OC12 (around 622Mbps), it's about 60Mbps, not 155, and for oc48 it's around 250Mbps. That is over an OC3, but much less than an OC12.
The 5 bytes of header per cell is part of the cell tax; there's also the wastage caused by (a) AAL5 and possibly SNAP encapsulation, and (b) needing to populate an integer number of cells when the total frame-based payload is not a multiple of 48 bytes.
Worst case, you will carry 49 bytes of payload per two cells. That's 57 bytes wastage in 106 bytes transmitted, or a cell tax of around 54%.
The extent to which this effect is significant depends on the distribution of packet sizes in your traffic. Unfortunately, on the internet, a high proportion of packets are TCP ACKs with no data, which narrowly fail to fit inside a single cell.
On the internet, a cell tax of 30% or so is quite normal.
You're right there, of course. I'm still in the habit of thinking of raw cell payloads as opposed to actual useful bytes of IP in AAL5 etc. Ethernet also only gets about 50% efficiency for small packets though, if you include the IFG. Cisco POS does better, with only 4 bytes header per packet (plus a start byte and 2 to end), but I think there's a minimum frame size there too in practice that would lower the efficiency slightly. POS also has to do byte stuffing, as it's basically HDLC. Stephen. -- ----------------------------------------------------------------------- Stephen Donnelly (BCMS) email: sfd(a)cs.waikato.ac.nz WAND Group Room GG.15 phone +64 7 838 4086 Computer Science Department, University of Waikato, New Zealand ----------------------------------------------------------------------- --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Fri, Feb 23, 2001 at 02:24:35PM +1300, Stephen Donnelly wrote:
Ethernet also only gets about 50% efficiency for small packets though, if you include the IFG. Cisco POS does better, with only 4 bytes header per packet (plus a start byte and 2 to end), but I think there's a minimum frame size there too in practice that would lower the efficiency slightly. POS also has to do byte stuffing, as it's basically HDLC.
Yeah There will be a minimum frame size but because the frame is able to grow to fit almost all payload types, it doesn't suffer from the atm pathological case where you have overflowed the cell by one byte and you need a whole new cell. I might actually pump some internet style (tm) traffic over some oc3's to see the difference. Dean --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Fri, Feb 23, 2001 at 12:02:05PM +1300, Stephen Donnelly wrote:
dean(a)flatnet.gen.nz wrote:
Yeah Joe's right.
Given the fact that there is no way of sar-ing over oc48, most major players are now moving to POS. Even if you don't need oc48 or oc192 now, it makes little sense to embrace ATM for a new network and then have to throw it in the bin next year anyway. Also the higher the speed the more the celltax costs you. Eg if you pay for an oc12 on southern cross then you loose the equiv of an oc3 in overhead. Thats a heckload of cash. Loosing an oc12 on an oc48 link is even worse.
The 'cell tax' is 5 bytes of overhead for every 48 bytes of data, or about 1/10. So for OC12 (around 622Mbps), it's about 60Mbps, not 155, and for oc48 it's around 250Mbps. That is over an OC3, but much less than an OC12.
See Joes reply for a full description, but needless to say that the 5 byte header is not the only overhead that atm imposes.
In case you're interested, we have built a PCI card for passive monitoring OC48 POS. (no one wanted ATM, for some reason ;)
fairly old page: http://atm.cs.waikato.ac.nz/wand/docs/dag4/
Research group pages (also old): http://wand.cs.waikato.ac.nz/
Cool - We use agilent, ixia and smart bits for testing (although the smart bits imo are a bit light.) If you ever want to give me a sample to play with I'll see how it works with our gear. Dean --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Fri, 23 Feb 2001, Stephen Donnelly wrote:
dean(a)flatnet.gen.nz wrote:
Yeah Joe's right.
Given the fact that there is no way of sar-ing over oc48, most major players are now moving to POS. Even if you don't need oc48 or oc192 now, it makes little sense to embrace ATM for a new network and then have to throw it in the bin next year anyway. Also the higher the speed the more the celltax costs you. Eg if you pay for an oc12 on southern cross then you loose the equiv of an oc3 in overhead. Thats a heckload of cash. Loosing an oc12 on an oc48 link is even worse.
The 'cell tax' is 5 bytes of overhead for every 48 bytes of data, or about 1/10. So for OC12 (around 622Mbps), it's about 60Mbps, not 155, and for oc48 it's around 250Mbps. That is over an OC3, but much less than an OC12.
I beleive the extra overhead is in carrying IP over ATM - the smallest packet in IP is 64 bytes, which is split into 2 cells, 1 with 32 bytes of padding in it due to fixed cell length. Of course not all packets are 64 bytes long, but this is the by far the largest excuse for overhead with IP over ATM I have heard cheers -- Brendan Black - Evil Engineer Extraordinaire - ratfink(a)xtra.co.nz UK mobile: +44 7790 525596 Linux User# 44680 "You know, it's at times like this when I'm trapped in a Vogon airlock with a man from Betelgeuse and about to die of asphyxiation in deep space that I really wish I'd listened to what my mother told me when I was young!" "Why, what did she tell you?" "I don't know, I didn't listen!" -- Douglas Adams, "Hitchhiker's Guide to the Galaxy" --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Thu, 22 Feb 2001, Joe Abley wrote:
On Thu, Feb 22, 2001 at 02:17:09PM +1100, Scott, Arron wrote:
Now we just need a Telco or three in NZ to support ATM at STM-4 rates.
Is anybody really waiting for that? If you're shifting an STM-4s worth of data around, it's probably a stream of packets, and it's probably IP, and you probably want to use POS. You probably don't want the additional complexity, cost, operational overhead, cell tax and SAR latency that using ATM would involve.
Also, ATM is the work of Satan, which should be mentioned, for the record.
aggreed, pos is much simpler, even if you do have to add a few extra parameters to run cisco pos interfaces over sdh -- Brendan Black - Evil Engineer Extraordinaire - ratfink(a)xtra.co.nz UK mobile: +44 7790 525596 Linux User# 44680 "You know, it's at times like this when I'm trapped in a Vogon airlock with a man from Betelgeuse and about to die of asphyxiation in deep space that I really wish I'd listened to what my mother told me when I was young!" "Why, what did she tell you?" "I don't know, I didn't listen!" -- Douglas Adams, "Hitchhiker's Guide to the Galaxy" --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
participants (6)
-
Andy Linton -
Brendan Black -
dean＠flatnet.gen.nz -
Joe Abley -
Scott, Arron -
Stephen Donnelly