Archived from groups: comp.dcom.lans.ethernet (More info?)
Why CSMA/CD is not suitable for real time applications??
Why CSMA/CD is not suitable for real time applications??
Archived from groups: comp.dcom.lans.ethernet (More info?)
In article <2f3b012a.0501180106.40060b7@posting.google.com>,
levin_ae101hk@yahoo.com.hk (levin) wrote:
> Why CSMA/CD is not suitable for real time applications??
I question the premise; I designed and shipped shared-media Ethernet
(CSMA/CD) products for real-time factory automation applications 20
years ago.
--
Rich Seifert Networks and Communications Consulting
21885 Bear Creek Way
(408) 395-5700 Los Gatos, CA 95033
(408) 228-0803 FAX
Send replies to: usenet at richseifert dot com
In article <2f3b012a.0501180106.40060b7@posting.google.com>,
levin_ae101hk@yahoo.com.hk (levin) wrote:
> Why CSMA/CD is not suitable for real time applications??
I question the premise; I designed and shipped shared-media Ethernet
(CSMA/CD) products for real-time factory automation applications 20
years ago.
--
Rich Seifert Networks and Communications Consulting
21885 Bear Creek Way
(408) 395-5700 Los Gatos, CA 95033
(408) 228-0803 FAX
Send replies to: usenet at richseifert dot com
Archived from groups: comp.dcom.lans.ethernet (More info?)
In article <2f3b012a.0501180106.40060b7@posting.google.com>,
levin <levin_ae101hk@yahoo.com.hk> wrote:
:Why CSMA/CD is not suitable for real time applications??
Sounds like a homework question to me...
Suppose you have a frame ready to send. What is the minimum time before
the recipient receives it? And presuming it doesn't get lost or
discarded, what is the maximum time before the recpient receives it?
--
What is "The Ultimate Meme"? Would it, like Monty Python's
"The World's Funniest Joke", lead to the deaths of everyone who
encountered it? Ideas *have* lead to the destruction of entire cultures.
-- A Child's Garden Of Memes
In article <2f3b012a.0501180106.40060b7@posting.google.com>,
levin <levin_ae101hk@yahoo.com.hk> wrote:
:Why CSMA/CD is not suitable for real time applications??
Sounds like a homework question to me...
Suppose you have a frame ready to send. What is the minimum time before
the recipient receives it? And presuming it doesn't get lost or
discarded, what is the maximum time before the recpient receives it?
--
What is "The Ultimate Meme"? Would it, like Monty Python's
"The World's Funniest Joke", lead to the deaths of everyone who
encountered it? Ideas *have* lead to the destruction of entire cultures.
-- A Child's Garden Of Memes
Archived from groups: comp.dcom.lans.ethernet (More info?)
For the same reason why homework questions are not suitable on
technical newsgroups.
--
hsb
"Somehow I imagined this experience would be more rewarding" Calvin
**************************ROT13 MY ADDRESS*************************
Due to the volume of email that I receive, I may not not be able to
reply to emails sent to my account. Please post a followup instead.
********************************************************************
For the same reason why homework questions are not suitable on
technical newsgroups.
--
hsb
"Somehow I imagined this experience would be more rewarding" Calvin
**************************ROT13 MY ADDRESS*************************
Due to the volume of email that I receive, I may not not be able to
reply to emails sent to my account. Please post a followup instead.
********************************************************************
Archived from groups: comp.dcom.lans.ethernet (More info?)
Levin wrote:
> Why CSMA/CD is not suitable for real time applications??
Walter Roberson replied:
> Suppose you have a frame ready to send. What is the minimum time before
> the recipient receives it? And presuming it doesn't get lost or
> discarded, what is the maximum time before the recpient receives it?
and Rich Seifert wrote:
> I question the premise; I designed and shipped shared-media Ethernet
> (CSMA/CD) products for real-time factory automation applications 20
> years ago.
In general, you can take anything Rich says and consider it gospel (at
least I do) but I've got to side with Walter on this one.
I think there is a lot of misunderstanding (or maybe different
understandings) about what is really meant by real-time. Most seem to
think that real-time means high speed or high performance. What it
really means is *guaranteed* performance. At least that's the case for
what people commonly refer to as hard real-time. When Walter asks "What
is the minimum time before the recipient receives it?", that is really
the crux of the matter because may recollection is that max delivery
time is unbounded even for a correctly operating ethernet network (at
least for the non-trivial case with more than one node offering load).
You can't guarantee performance when you don't know the worst case
performance.
Having said that, very few real-time applications are that stringent.
Most are soft real-time systems that can (or should) easily tolerate an
occasional dropped packet. I, like a lot of developers, successfully
use ethernet for real-time applications every day. Most of the time
using something like token ring for deterministic performance just ain't
worth the hassle. You can add a software layer on top of the ethernet
network layer to implement deterministic performance (something along
the lines of MIL-STD-1553 command/response) but again it usually isn't
worth the effort.
If you're designing a Space Shuttle Main Engine controller then by all
means use a network with deterministic performance. Other than that, at
least go in with your eyes open and understand the limitations.
Just my $0.02 worth and I hope Rich doesn't flog me too bad. ;-)
Bob Baggerman
Georgia Tech
Levin wrote:
> Why CSMA/CD is not suitable for real time applications??
Walter Roberson replied:
> Suppose you have a frame ready to send. What is the minimum time before
> the recipient receives it? And presuming it doesn't get lost or
> discarded, what is the maximum time before the recpient receives it?
and Rich Seifert wrote:
> I question the premise; I designed and shipped shared-media Ethernet
> (CSMA/CD) products for real-time factory automation applications 20
> years ago.
In general, you can take anything Rich says and consider it gospel (at
least I do) but I've got to side with Walter on this one.
I think there is a lot of misunderstanding (or maybe different
understandings) about what is really meant by real-time. Most seem to
think that real-time means high speed or high performance. What it
really means is *guaranteed* performance. At least that's the case for
what people commonly refer to as hard real-time. When Walter asks "What
is the minimum time before the recipient receives it?", that is really
the crux of the matter because may recollection is that max delivery
time is unbounded even for a correctly operating ethernet network (at
least for the non-trivial case with more than one node offering load).
You can't guarantee performance when you don't know the worst case
performance.
Having said that, very few real-time applications are that stringent.
Most are soft real-time systems that can (or should) easily tolerate an
occasional dropped packet. I, like a lot of developers, successfully
use ethernet for real-time applications every day. Most of the time
using something like token ring for deterministic performance just ain't
worth the hassle. You can add a software layer on top of the ethernet
network layer to implement deterministic performance (something along
the lines of MIL-STD-1553 command/response) but again it usually isn't
worth the effort.
If you're designing a Space Shuttle Main Engine controller then by all
means use a network with deterministic performance. Other than that, at
least go in with your eyes open and understand the limitations.
Just my $0.02 worth and I hope Rich doesn't flog me too bad. ;-)
Bob Baggerman
Georgia Tech
Archived from groups: comp.dcom.lans.ethernet (More info?)
Bob wrote:
> I think there is a lot of misunderstanding (or maybe different
> understandings) about what is really meant by real-time. Most seem to
> think that real-time means high speed or high performance. What it
> really means is guaranteed performance. At least that's the case for
> what people commonly refer to as hard real-time. When Walter asks "What
> is the minimum time before the recipient receives it?", that is really
> the crux of the matter because may recollection is that max delivery
> time is unbounded even for a correctly operating ethernet network (at
> least for the non-trivial case with more than one node offering load).
> You can't guarantee performance when you don't know the worst case
> performance.
A lot of those issues disappeared, with the use of switches, in place of
hubs or shared cable. In the days of collisions, you really couldn't put
hard numbers on some things. With switches, a lot of that ambiguity
disappears.
Bob wrote:
> I think there is a lot of misunderstanding (or maybe different
> understandings) about what is really meant by real-time. Most seem to
> think that real-time means high speed or high performance. What it
> really means is guaranteed performance. At least that's the case for
> what people commonly refer to as hard real-time. When Walter asks "What
> is the minimum time before the recipient receives it?", that is really
> the crux of the matter because may recollection is that max delivery
> time is unbounded even for a correctly operating ethernet network (at
> least for the non-trivial case with more than one node offering load).
> You can't guarantee performance when you don't know the worst case
> performance.
A lot of those issues disappeared, with the use of switches, in place of
hubs or shared cable. In the days of collisions, you really couldn't put
hard numbers on some things. With switches, a lot of that ambiguity
disappears.
Archived from groups: comp.dcom.lans.ethernet (More info?)
Bob <bob.public@mindspring.com> wrote:
> In general, you can take anything Rich says and consider
> it gospel (at least I do)
I do too!
> I think there is a lot of misunderstanding (or maybe different
> understandings) about what is really meant by real-time. Most seem
> to think that real-time means high speed or high performance.
> What it really means is *guaranteed* performance. At least that's
> the case for what people commonly refer to as hard real-time.
> When Walter asks "What is the minimum time before the recipient
> receives it?", that is really the crux of the matter because may
> recollection is that max delivery time is unbounded even for a
> correctly operating ethernet network (at least for the non-trivial
> case with more than one node offering load). You can't guarantee
> performance when you don't know the worst case performance.
Only literally true. Real life is all a question of
probabilities. There's no sense in hardening the network if
it is surrounded by weaker links in the performance chain.
Ethernet is probabilistically suitable for some real-time apps.
-- Robert
Bob <bob.public@mindspring.com> wrote:
> In general, you can take anything Rich says and consider
> it gospel (at least I do)
I do too!
> I think there is a lot of misunderstanding (or maybe different
> understandings) about what is really meant by real-time. Most seem
> to think that real-time means high speed or high performance.
> What it really means is *guaranteed* performance. At least that's
> the case for what people commonly refer to as hard real-time.
> When Walter asks "What is the minimum time before the recipient
> receives it?", that is really the crux of the matter because may
> recollection is that max delivery time is unbounded even for a
> correctly operating ethernet network (at least for the non-trivial
> case with more than one node offering load). You can't guarantee
> performance when you don't know the worst case performance.
Only literally true. Real life is all a question of
probabilities. There's no sense in hardening the network if
it is surrounded by weaker links in the performance chain.
Ethernet is probabilistically suitable for some real-time apps.
-- Robert
Archived from groups: comp.dcom.lans.ethernet (More info?)
In article <cslu1j$f1g$1@news-int2.gatech.edu>,
Bob <bob.public@mindspring.com> wrote:
>
> I think there is a lot of misunderstanding (or maybe different
> understandings) about what is really meant by real-time. Most seem to
> think that real-time means high speed or high performance. What it
> really means is *guaranteed* performance.
If by "guaranteed" you mean 100.0%, then no communications system in the
real world can meet the criterion. If you are willing to live with less
than "guaranteed," then the question becomes what level of imperfection
is acceptable (i.e., "how many nines?").
> Most are soft real-time systems that can (or should) easily tolerate an
> occasional dropped packet.
Not "can" or "should", but *must*. Since communication errors are
inevitable (ultimately, it comes down to thermal noise), there will
always be some residual level of packet loss.
> I, like a lot of developers, successfully
> use ethernet for real-time applications every day.
Which was exactly my point. To say that Ethernet and CSMA/CD are not
suitable for real-time communications is belied by the fact that we use
it for such purposes all the time.
> Most of the time
> using something like token ring for deterministic performance just ain't
> worth the hassle.
Ignoring for the moment the implied assumption that somehow
"deterministic performance" is a requirement of a real-time application,
there is a common misconception that Token Ring is in fact
deterministic, in that one can predict its delay and/or throughput in
advance of frame transmission. This is pure propaganda once used by IBM
(and others) to try to dissuade users from deploying Ethernet networks,
under the claim that somehow you would get more reliable and predictable
macro-performance from Token Ring (i.e., performance as seen by the user
of an application).
Token Ring is "deterministic" only in a theoretical, abstract sense,
using "textbook-style" assumptions. In reality, what an application
cares about is the time delay between queueing a frame for transmission
on the LAN, and reception of that frame by the intended recipient. Just
as with Ethernet, Token Ring cannot put any "guaranteed bound" on this
time, due to a number of factors:
(1) As discussed above, frames will always be discarded due to
communications errors. The error rate on a Token Ring LAN is essentially
the same as for an Ethernet LAN, as they use similar encoding, cables,
etc.
(2) While textbooks all discuss the "bounded time" for circulation of a
token, they rarely discuss the disruption caused by insertion/removal of
stations on the ring. Since any practical network will have workstations
regularly powering up/down during operation, there will be numerous
disruptions of the ring during application execution. Each such
disruption will normally require a "ring recovery", whereby a token must
be regenerated, and perhaps a selection of a new Active Monitor, etc.
This will incur a delay orders of magnitude greater than the "expected"
token rotation time.
(3) Token Ring advocates like to tout the availability of low-level
priority access mechanisms, whereby certain stations or applications can
assert a higher claim to use a token than others. Of course, any
application that is not running at the highest priority level can never
ensure that it will *ever* see a free token, much less one within some
bounded time. That is, "deterministic" behavior exists (if it exists at
all) only for the highest priority level. Since *everyone* wants high
priority (who ever says that their network application is less important
than someone else's?), the result is that all applications always run at
the highest priority, making the entire priority scheme moot.
(4) Finally (and perhaps the most important), it is rarely the case that
a given station has only *one* active application using the network at
any time. All network applications running on the station are placing
frames into the transmit queue for the network interface, independently
from each other. Thus, even if: (a) there are no errors, (b) the ring is
not disrupted, and (c) the application is running at the highest
priority, putting a frame on the transmit queue does NOT ensure that it
will be transmitted (much less received) within the "bounded" token
rotation time. All of the frames ahead of it in the queue (placed there
by other applications) will be transmitted first.
It becomes clear that any "determinism" theoretically present in Token
Ring is useless in a practical sense, since applications cannot use such
characteristics to their advantage. It may make for nice classroom
discussions, but the effects are lost in real-world systems.
--
Rich Seifert Networks and Communications Consulting
21885 Bear Creek Way
(408) 395-5700 Los Gatos, CA 95033
(408) 228-0803 FAX
Send replies to: usenet at richseifert dot com
In article <cslu1j$f1g$1@news-int2.gatech.edu>,
Bob <bob.public@mindspring.com> wrote:
>
> I think there is a lot of misunderstanding (or maybe different
> understandings) about what is really meant by real-time. Most seem to
> think that real-time means high speed or high performance. What it
> really means is *guaranteed* performance.
If by "guaranteed" you mean 100.0%, then no communications system in the
real world can meet the criterion. If you are willing to live with less
than "guaranteed," then the question becomes what level of imperfection
is acceptable (i.e., "how many nines?").
> Most are soft real-time systems that can (or should) easily tolerate an
> occasional dropped packet.
Not "can" or "should", but *must*. Since communication errors are
inevitable (ultimately, it comes down to thermal noise), there will
always be some residual level of packet loss.
> I, like a lot of developers, successfully
> use ethernet for real-time applications every day.
Which was exactly my point. To say that Ethernet and CSMA/CD are not
suitable for real-time communications is belied by the fact that we use
it for such purposes all the time.
> Most of the time
> using something like token ring for deterministic performance just ain't
> worth the hassle.
Ignoring for the moment the implied assumption that somehow
"deterministic performance" is a requirement of a real-time application,
there is a common misconception that Token Ring is in fact
deterministic, in that one can predict its delay and/or throughput in
advance of frame transmission. This is pure propaganda once used by IBM
(and others) to try to dissuade users from deploying Ethernet networks,
under the claim that somehow you would get more reliable and predictable
macro-performance from Token Ring (i.e., performance as seen by the user
of an application).
Token Ring is "deterministic" only in a theoretical, abstract sense,
using "textbook-style" assumptions. In reality, what an application
cares about is the time delay between queueing a frame for transmission
on the LAN, and reception of that frame by the intended recipient. Just
as with Ethernet, Token Ring cannot put any "guaranteed bound" on this
time, due to a number of factors:
(1) As discussed above, frames will always be discarded due to
communications errors. The error rate on a Token Ring LAN is essentially
the same as for an Ethernet LAN, as they use similar encoding, cables,
etc.
(2) While textbooks all discuss the "bounded time" for circulation of a
token, they rarely discuss the disruption caused by insertion/removal of
stations on the ring. Since any practical network will have workstations
regularly powering up/down during operation, there will be numerous
disruptions of the ring during application execution. Each such
disruption will normally require a "ring recovery", whereby a token must
be regenerated, and perhaps a selection of a new Active Monitor, etc.
This will incur a delay orders of magnitude greater than the "expected"
token rotation time.
(3) Token Ring advocates like to tout the availability of low-level
priority access mechanisms, whereby certain stations or applications can
assert a higher claim to use a token than others. Of course, any
application that is not running at the highest priority level can never
ensure that it will *ever* see a free token, much less one within some
bounded time. That is, "deterministic" behavior exists (if it exists at
all) only for the highest priority level. Since *everyone* wants high
priority (who ever says that their network application is less important
than someone else's?), the result is that all applications always run at
the highest priority, making the entire priority scheme moot.
(4) Finally (and perhaps the most important), it is rarely the case that
a given station has only *one* active application using the network at
any time. All network applications running on the station are placing
frames into the transmit queue for the network interface, independently
from each other. Thus, even if: (a) there are no errors, (b) the ring is
not disrupted, and (c) the application is running at the highest
priority, putting a frame on the transmit queue does NOT ensure that it
will be transmitted (much less received) within the "bounded" token
rotation time. All of the frames ahead of it in the queue (placed there
by other applications) will be transmitted first.
It becomes clear that any "determinism" theoretically present in Token
Ring is useless in a practical sense, since applications cannot use such
characteristics to their advantage. It may make for nice classroom
discussions, but the effects are lost in real-world systems.
--
Rich Seifert Networks and Communications Consulting
21885 Bear Creek Way
(408) 395-5700 Los Gatos, CA 95033
(408) 228-0803 FAX
Send replies to: usenet at richseifert dot com
Archived from groups: comp.dcom.lans.ethernet (More info?)
Begin <usenet-D36DF3.09051120012005@news.isp.giganews.com>
On 2005-01-20, Rich Seifert <usenet@richseifert.com.invalid> wrote:
[snip!]
>
> Ignoring for the moment the implied assumption that somehow
> "deterministic performance" is a requirement of a real-time application,
> there is a common misconception that Token Ring is in fact
> deterministic, in that one can predict its delay and/or throughput in
> advance of frame transmission. This is pure propaganda once used by IBM
> (and others) to try to dissuade users from deploying Ethernet networks,
> under the claim that somehow you would get more reliable and predictable
> macro-performance from Token Ring (i.e., performance as seen by the user
> of an application).
``802.4''.
Anyway, my point and pet-peeve is that it is still useful to have
native support like what ATM provides. Too bad that ATM is chock full
of assumptions that don't make much sense outside of the teleco world,
and otherwise is dead already. The effect is that we're now rolling out
ethernet(-like) stuff everywhere, with the nicer extras bolted on, as it
were. I can't help but think that it'd be nicer if such'd been designed
in from the start. But, you know, that's simply not how the world works.
On a different tangent; 802.12. Sure it isn't dead, just resting. But
did it, in fact, improve on deterministic-ness compared to ethernet, in
practice?
--
j p d (at) d s b (dot) t u d e l f t (dot) n l .
Begin <usenet-D36DF3.09051120012005@news.isp.giganews.com>
On 2005-01-20, Rich Seifert <usenet@richseifert.com.invalid> wrote:
[snip!]
>
> Ignoring for the moment the implied assumption that somehow
> "deterministic performance" is a requirement of a real-time application,
> there is a common misconception that Token Ring is in fact
> deterministic, in that one can predict its delay and/or throughput in
> advance of frame transmission. This is pure propaganda once used by IBM
> (and others) to try to dissuade users from deploying Ethernet networks,
> under the claim that somehow you would get more reliable and predictable
> macro-performance from Token Ring (i.e., performance as seen by the user
> of an application).
``802.4''.
Anyway, my point and pet-peeve is that it is still useful to have
native support like what ATM provides. Too bad that ATM is chock full
of assumptions that don't make much sense outside of the teleco world,
and otherwise is dead already. The effect is that we're now rolling out
ethernet(-like) stuff everywhere, with the nicer extras bolted on, as it
were. I can't help but think that it'd be nicer if such'd been designed
in from the start. But, you know, that's simply not how the world works.
On a different tangent; 802.12. Sure it isn't dead, just resting. But
did it, in fact, improve on deterministic-ness compared to ethernet, in
practice?
--
j p d (at) d s b (dot) t u d e l f t (dot) n l .
Archived from groups: comp.dcom.lans.ethernet (More info?)
On 20 Jan 2005 21:18:47 GMT, jpd <read_the_sig@do.not.spam.it.invalid>
wrote:
[snip]
>Anyway, my point and pet-peeve is that it is still useful to have
>native support like what ATM provides. Too bad that ATM is chock full
>of assumptions that don't make much sense outside of the teleco world,
>and otherwise is dead already.
We're still getting requests from customers for new ATM equipment,
mostly because of the requirement to interwork with the intstalled
base. I expect this segment of the market will move to GbE over the
next few years.
ATM is old and grey, but it's not dead yet.
Regards,
Allan
On 20 Jan 2005 21:18:47 GMT, jpd <read_the_sig@do.not.spam.it.invalid>
wrote:
[snip]
>Anyway, my point and pet-peeve is that it is still useful to have
>native support like what ATM provides. Too bad that ATM is chock full
>of assumptions that don't make much sense outside of the teleco world,
>and otherwise is dead already.
We're still getting requests from customers for new ATM equipment,
mostly because of the requirement to interwork with the intstalled
base. I expect this segment of the market will move to GbE over the
next few years.
ATM is old and grey, but it's not dead yet.
Regards,
Allan
Archived from groups: comp.dcom.lans.ethernet (More info?)
"Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in
message news:qi61v09e8tb1h3sql1lrcv9a5pfqq35d05@4ax.com...
> On 20 Jan 2005 21:18:47 GMT, jpd <read_the_sig@do.not.spam.it.invalid>
> wrote:
>
> [snip]
> >Anyway, my point and pet-peeve is that it is still useful to have
> >native support like what ATM provides. Too bad that ATM is chock full
> >of assumptions that don't make much sense outside of the teleco world,
> >and otherwise is dead already.
>
> We're still getting requests from customers for new ATM equipment,
> mostly because of the requirement to interwork with the intstalled
> base. I expect this segment of the market will move to GbE over the
> next few years.
agreed - the ATM backbone at work has increasing load even now, although a
lot of the frame relay ports it used to feed are going as corporates move to
MPLS.
>
> ATM is old and grey, but it's not dead yet.
UK DSL is 95% or more ATM based. i believe the same is true in some other
countries.
and the incumbent carrier (BT) recently launched a national Ethernet
service - but the underlying WAN is actually ATM - i suppose they have to
keep all those switches busy somehow.
>
> Regards,
> Allan
--
Regards
Stephen Hope - return address needs fewer xxs
"Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in
message news:qi61v09e8tb1h3sql1lrcv9a5pfqq35d05@4ax.com...
> On 20 Jan 2005 21:18:47 GMT, jpd <read_the_sig@do.not.spam.it.invalid>
> wrote:
>
> [snip]
> >Anyway, my point and pet-peeve is that it is still useful to have
> >native support like what ATM provides. Too bad that ATM is chock full
> >of assumptions that don't make much sense outside of the teleco world,
> >and otherwise is dead already.
>
> We're still getting requests from customers for new ATM equipment,
> mostly because of the requirement to interwork with the intstalled
> base. I expect this segment of the market will move to GbE over the
> next few years.
agreed - the ATM backbone at work has increasing load even now, although a
lot of the frame relay ports it used to feed are going as corporates move to
MPLS.
>
> ATM is old and grey, but it's not dead yet.
UK DSL is 95% or more ATM based. i believe the same is true in some other
countries.
and the incumbent carrier (BT) recently launched a national Ethernet
service - but the underlying WAN is actually ATM - i suppose they have to
keep all those switches busy somehow.
>
> Regards,
> Allan
--
Regards
Stephen Hope - return address needs fewer xxs
Archived from groups: comp.dcom.lans.ethernet (More info?)
["stephen"]
| UK DSL is 95% or more ATM based. i believe the same is true in some other
| countries.
It's important to differentiate between 1. ATM used on the link from
DSLAM to DSL "modem" at the customer location, and 2. ATM used from the
DSLAM towards the backbone.
In Norway 1 is very common (but not ubiquitous - the provider I work for
also sells SHDSL which is *not* ATM based, using Nettonet/Paradyne
equipment). 2 is not nearly as common.
Steinar Haug, Nethelp consulting, sthaug@nethelp.no
["stephen"]
| UK DSL is 95% or more ATM based. i believe the same is true in some other
| countries.
It's important to differentiate between 1. ATM used on the link from
DSLAM to DSL "modem" at the customer location, and 2. ATM used from the
DSLAM towards the backbone.
In Norway 1 is very common (but not ubiquitous - the provider I work for
also sells SHDSL which is *not* ATM based, using Nettonet/Paradyne
equipment). 2 is not nearly as common.
Steinar Haug, Nethelp consulting, sthaug@nethelp.no
Archived from groups: comp.dcom.lans.ethernet (More info?)
"Steinar Haug" <sthaug@nethelp.no> wrote in message
news:cst8vb.1l4k.1@bizet.nethelp.no...
> ["stephen"]
>
> | UK DSL is 95% or more ATM based. i believe the same is true in some
other
> | countries.
>
> It's important to differentiate between 1. ATM used on the link from
> DSLAM to DSL "modem" at the customer location, and 2. ATM used from the
> DSLAM towards the backbone.
>
> In Norway 1 is very common (but not ubiquitous - the provider I work for
> also sells SHDSL which is *not* ATM based, using Nettonet/Paradyne
> equipment). 2 is not nearly as common.
Steinar, what protocol are they running over SHDSL instead of ATM? Is it
pure Ethernet, as in 2BASE-TL? Or is there some other kind of (proprietary)
encapsulation involved?
Michael
remove "filter" from email address
http://www.ethernetinthefirstmile.com
"Steinar Haug" <sthaug@nethelp.no> wrote in message
news:cst8vb.1l4k.1@bizet.nethelp.no...
> ["stephen"]
>
> | UK DSL is 95% or more ATM based. i believe the same is true in some
other
> | countries.
>
> It's important to differentiate between 1. ATM used on the link from
> DSLAM to DSL "modem" at the customer location, and 2. ATM used from the
> DSLAM towards the backbone.
>
> In Norway 1 is very common (but not ubiquitous - the provider I work for
> also sells SHDSL which is *not* ATM based, using Nettonet/Paradyne
> equipment). 2 is not nearly as common.
Steinar, what protocol are they running over SHDSL instead of ATM? Is it
pure Ethernet, as in 2BASE-TL? Or is there some other kind of (proprietary)
encapsulation involved?
Michael
remove "filter" from email address
http://www.ethernetinthefirstmile.com
TRENDING THREADS
-
-
News Windows 11 will reportedly display a watermark if your PC does not support AI requirements- Started by Admin
- Replies: 4
-
Question Why Beyerdynamic DT 990 PRO is so quiet?- Started by kaizerSoze05
- Replies: 2
-
-
Latest posts
-
Question r9 390 a good budget option since rx 580s are overpriced?
- Latest: jordanbuilds1
-
-
-
-
Question Issues with USB3 hub chained from Thunderbolt dock
- Latest: jauntysquirrel
Facebook
Twitter
Instagram