Sign-in / Sign-up
Your question

About link test pulse

Tags:
  • Ethernet Card
  • Networking
Last response: in Networking
Anonymous
October 29, 2004 5:31:49 PM

Archived from groups: comp.dcom.lans.ethernet (More info?)

Hi,

I try with my poor head to understand the integrity link test pulse.

(1) The link test pulse (e.g. for 10BaseT) is not repeated on the other
ports of the hub when this one receives it. Is it correct?

(2) Is someone can explain me in a few words why there is sometimes NLP
(normal link pulse) and why there is sometimes FLP (fast link pulse)? Is NLP
still exists?

Regards,
Michelot

More about : link test pulse

Anonymous
October 29, 2004 5:31:50 PM

Archived from groups: comp.dcom.lans.ethernet (More info?)

In article <41822a20$0$31226$8fcfb975@news.wanadoo.fr>,
"Michelot" <mhostettler@wanadooNOSPAM.fr> wrote:

> Hi,
>
> I try with my poor head to understand the integrity link test pulse.
>
> (1) The link test pulse (e.g. for 10BaseT) is not repeated on the other
> ports of the hub when this one receives it. Is it correct?
>

That is correct; link test pulses are not frames, and have no
significance beyond the link on which they are sent/received.

> (2) Is someone can explain me in a few words why there is sometimes NLP
> (normal link pulse) and why there is sometimes FLP (fast link pulse)? Is NLP
> still exists?
>

Normal link pulses are used by 10BASE-T devices. Fast Link Pulse bursts
are used by devices that perform Auto-Negotiation, and are present only
during Auto-Negotiation.


--
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
Anonymous
October 30, 2004 1:31:53 AM

Archived from groups: comp.dcom.lans.ethernet (More info?)

Bonsoir Rich,

Thanks for your clear replies, I understand better. Can I ask you two more
questions?

(1) If I understand correctly 802.3-2002, the TP_IDL signal is sended just
after the last frame data bit (last FCS bit I suppose). And, 16 ms after
TP_IDL, comes LTP pulse if TD is always idle. Is it correct? I note that the
minimum TP_IDL signal duration is greater (2.5 BT min.) than the one of LTP
(0.85 BT min.), but perhaps, in real circuits they have the same shape.

(2) Is the automatic detection of the cable twisted pair connection
(straight or crossover) is also an effect of the autonegotiation? I don't
see that in 802.3 but perhaps, I haven't read correctly.

Regards,
Michelot
Related resources
Anonymous
October 30, 2004 1:31:54 AM

Archived from groups: comp.dcom.lans.ethernet (More info?)

In article <41829aa5$0$24979$8fcfb975@news.wanadoo.fr>,
"Michelot" <mhostettler@wanadooNOSPAM.fr> wrote:

> Bonsoir Rich,
>
> Thanks for your clear replies, I understand better. Can I ask you two more
> questions?
>
> (1) If I understand correctly 802.3-2002, the TP_IDL signal is sended just
> after the last frame data bit (last FCS bit I suppose). And, 16 ms after
> TP_IDL, comes LTP pulse if TD is always idle. Is it correct?

Correct, although you should understand that, in 10BASE-T, the "TP_IDL"
signal is transmitted as a lack of any signal altogether; "TP_IDL" is
"silence" in 10BASE-T. If the transmit link is idle for 16 ms (nominal),
then the device sends a link test pulse, just to tell the receiver that
the link is still up and functioning, even if frames are not being sent.


> I note that the
> minimum TP_IDL signal duration is greater (2.5 BT min.) than the one of LTP
> (0.85 BT min.), but perhaps, in real circuits they have the same shape.
>

The TP_IDL signal does not have any "shape"; a TP_IDL of 2.5 BT min
simply means that the line must go quiet for at least 2.5 bit times.

> (2) Is the automatic detection of the cable twisted pair connection
> (straight or crossover) is also an effect of the autonegotiation? I don't
> see that in 802.3 but perhaps, I haven't read correctly.
>

No, auto-polarity (as it is sometimes called) is outside the standard,
but commonly implemented in commercial transceivers because it is so
useful.


--
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
Anonymous
October 30, 2004 6:26:22 AM

Archived from groups: comp.dcom.lans.ethernet (More info?)

Rich Seifert wrote:

(snip)

> Normal link pulses are used by 10BASE-T devices. Fast Link Pulse bursts
> are used by devices that perform Auto-Negotiation, and are present only
> during Auto-Negotiation.

And what does a 10baseT device built before auto-negotiation
do with a fast link pulse?

I once had some Asante (for Macs) NICs that would blink the
link light when connected to a 10/100 hub. The book didn't
say anything about a blinking link light (maybe 1Hz or so).
It just didn't work on that hub, but worked fine on
ordinary 10baseT hubs.

-- glen
Anonymous
October 30, 2004 3:18:22 PM

Archived from groups: comp.dcom.lans.ethernet (More info?)

Bonjour Glen,

Probably Rich will add some good comments to our remarks.

> And what does a 10baseT device built before auto-negotiation
> do with a fast link pulse?

Normally, NLP is compatible with FLP: FLP can act the role of NLP.

> I once had some Asante (for Macs) NICs that would blink the
> link light when connected to a 10/100 hub.

You're talking a 10baseT NIC without auto-negotiation connected to a 10/100
hub. To detect correctly the 10baseT, I think the hub has to treat the
parallel detection mecanism. I heard that sometimes, there are some bugs
with that.

You can find an exemple in the reverse situation (10/100 NIC face to 10 Hub)
here (dated on 1996)
http://www.ethermanage.com/ethernet/100quickref/ch13qr_...

> The book didn't
> say anything about a blinking link light (maybe 1Hz or so).

Minimum frequency should be 62 Hz (1000/16) and the light seems stable for
our eyes.

> It just didn't work on that hub, but worked fine on
> ordinary 10baseT hubs.

Difficulties with the parallel detection?

Regards,
Michelot
Anonymous
October 30, 2004 4:44:04 PM

Archived from groups: comp.dcom.lans.ethernet (More info?)

Bonjour Rich,

> The TP_IDL signal does not have any "shape"; a TP_IDL of 2.5 BT min
> simply means that the line must go quiet for at least 2.5 bit times.

I understood that it was a real signal added, confirmed by the case when the
last cell was CD0.

"If the last bit transmitted was a CD0, the PLS will generate an additional
transition at the bit cell
boundary following the CD0. After the zero crossing of the last transition,
the differential voltage shall
remain within the shaded area of Figure 14-10".

Are you saying in your reply that after the last positive transition (normal
if CD1, or added if CD0 is the last bit), the signal returns freely to the
quiet (conforming to the standard template)? So, I can understand now the
term "start" in the expression "transmitter waveform for start of TP_IDL".

> No, auto-polarity (as it is sometimes called) is outside the standard,
> but commonly implemented in commercial transceivers because it is so
> useful.

Do you know how is the mecanism? I suppose the polarity is detected before
any frame is sent.

Regards,
Michelot
Anonymous
October 30, 2004 4:44:05 PM

Archived from groups: comp.dcom.lans.ethernet (More info?)

In article <4183706e$0$31226$8fcfb975@news.wanadoo.fr>,
"Michelot" <mhostettler@wanadooNOSPAM.fr> wrote:

>
> Are you saying in your reply that after the last positive transition (normal
> if CD1, or added if CD0 is the last bit), the signal returns freely to the
> quiet (conforming to the standard template)? So, I can understand now the
> term "start" in the expression "transmitter waveform for start of TP_IDL".
>

Correct. The transceiver ensures that the last transition is
positive-going (either because the data worked out that way, or by
forcing it that way), and then lets the signal naturally descend to
zero. The waveshape of the return-to-zero is a function of the cable
impedance, the transformer magnetics, etc.

> > No, auto-polarity (as it is sometimes called) is outside the standard,
> > but commonly implemented in commercial transceivers because it is so
> > useful.
>
> Do you know how is the mecanism? I suppose the polarity is detected before
> any frame is sent.
>

You can detect the polarity by looking at the link test pulse; it should
be unipolar and positive (seen differentially). If it shows up as a
negative differential, just invert the output of the receiver.


--
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
Anonymous
November 2, 2004 2:33:46 AM

Archived from groups: comp.dcom.lans.ethernet (More info?)

Bonsoir Rich,

Thanks for that talking which helps me.

(1) I should be curious to know why 802.3 uses sometimes the term repeater
instead of hub. Is there a difference of meaning?

(2) The NLP pulses (or FLP) don't carry the synchronization. Can we say that
these test pulses are asynchronous of the frame bit timing? Perhaps, 2
consecutive frames issue from the same end TD could be even asynchronous. Is
it correct?

(3) When the AUI isn't separated from the DTE, can we still talk about the
CO (control out) et CI (control in) signals? I'm wondering now if the test
pulses come from DO or CO!

Regards,
Michelot
Anonymous
November 2, 2004 3:46:08 AM

Archived from groups: comp.dcom.lans.ethernet (More info?)

Bonsoir Rich,

Thanks for that talking which helps me.

(1) I should be curious to know why 802.3 uses sometimes the term repeater
instead of hub. Is there a difference of meaning?

(2) The NLP pulses (or FLP) don't carry the synchronization. Can we say that
these test pulses are asynchronous of the frame bit timing? Perhaps, 2
consecutive frames issue from the same end TD could be even asynchronous. Is
it correct?

(3) When the AUI isn't separated from the DTE, can we still talk about the
CO (control out) et CI (control in) signals? I'm wondering now if the test
pulses come from DO or CO!

Regards,
Michelot
Anonymous
November 2, 2004 10:19:06 AM

Archived from groups: comp.dcom.lans.ethernet (More info?)

(snip)

> (1) I should be curious to know why 802.3 uses sometimes
> the term repeater instead of hub. Is there a difference of meaning?

I would expect it to always use repeater.

In the beginning there was coaxial ethernet. Multiple stations
could tap into a long coaxial cable. The electronics for building
a repeater was expensive, so they were only used when needed.
The cable could be 500m long, so a fairly large net could be
built without any repeater.

Coaxial ethernet is inconvenient in that the cable can't
have any branches in it. AUI cables up to 50m long reach from
the host to the nearest tap on the cable.

As electronics got cheaper, twisted pair ethernet began.
This allowed the more convenient hub and spoke topology,
where a hub in a wiring closet is connected to each host,
and a separate cable is needed for each host. Electrically
such hubs were ethernet repeaters, as the term had been used
since the coaxial ethernet days, but, as all twisted pair
hubs were repeaters, the term hub became commonly used.

As electronics became even cheaper, the ethernet bridge,
as previously defined in the ethernet standards, became
affordable. To emphasize the fact that the signal was
not sent out every port, marketing departments started
to use the term switch, related to the telephone system
device which connects individual phone subscribers to
the phone network.

So, technically there are repeating hubs and bridging,
or switching, hubs. The word hub alone is often taken
to mean repeating hub, and the word switch to mean
switching hub. Hub is the topology, repeater is
the function.

Does that help any?

-- glen
Anonymous
November 2, 2004 4:33:19 PM

Archived from groups: comp.dcom.lans.ethernet (More info?)

Bonjour Glen,

> Does that help any?

Yes, it's wonderful! As I always say, I have some difficulties talking about
telecom technicals with my dear wife, or with my neighbours, on Sundays
during aperitif! Thanks for that interesting synthesis.

> AUI cables up to 50m long reach from
> the host to the nearest tap on the cable.

We always talk about AUI in 10Base-T, and MII or GMII. Are these interfaces
really used? Perhaps it is used in specific applications as banking
terminal... But, nowadays, I don't see the advantages.

> Electrically
> such hubs were ethernet repeaters, as the term had been used
> since the coaxial ethernet days, but, as all twisted pair
> hubs were repeaters, the term hub became commonly used.

Yes, it's commonly used by the users, not by the Standard. In the IEEE, I
note that the term hub is used 2 times in the sections relative to twisted
pair or optical 10 Mbit/s and, on the contrary, the term repeater is used
more than 300 times.

> So, technically there are repeating hubs and bridging,
> or switching, hubs. The word hub alone is often taken
> to mean repeating hub, and the word switch to mean
> switching hub. Hub is the topology, repeater is
> the function.

Great! I just trying to look for a generic word for naming hubs (in the
sense of repeatind hubs) and bridges (either a full equipment, either
embeded in routers, domestic modems, industrial modems as LMDS CPE,
stations...). So, as you say, we can define the generic hub word which can
be qualified of repeating or switching feature. In France, hubs is opposed
to switches (or bridges), but I can all the same to be clear on a generic
word for gathering both device concepts.

Regards,
Michelot
Anonymous
November 2, 2004 4:33:20 PM

Archived from groups: comp.dcom.lans.ethernet (More info?)

Michelot wrote:

> Bonjour Glen,
>
>> Does that help any?
>
> Yes, it's wonderful! As I always say, I have some difficulties talking
> about telecom technicals with my dear wife, or with my neighbours, on
> Sundays during aperitif! Thanks for that interesting synthesis.
>
>> AUI cables up to 50m long reach from
>> the host to the nearest tap on the cable.
>
> We always talk about AUI in 10Base-T, and MII or GMII. Are these
> interfaces really used? Perhaps it is used in specific applications as
> banking terminal... But, nowadays, I don't see the advantages.
>
>> Electrically
>> such hubs were ethernet repeaters, as the term had been used
>> since the coaxial ethernet days, but, as all twisted pair
>> hubs were repeaters, the term hub became commonly used.
>
> Yes, it's commonly used by the users, not by the Standard. In the IEEE, I
> note that the term hub is used 2 times in the sections relative to twisted
> pair or optical 10 Mbit/s and, on the contrary, the term repeater is used
> more than 300 times.
>
>> So, technically there are repeating hubs and bridging,
>> or switching, hubs. The word hub alone is often taken
>> to mean repeating hub, and the word switch to mean
>> switching hub. Hub is the topology, repeater is
>> the function.
>
> Great! I just trying to look for a generic word for naming hubs (in the
> sense of repeatind hubs) and bridges (either a full equipment, either
> embeded in routers, domestic modems, industrial modems as LMDS CPE,
> stations...). So, as you say, we can define the generic hub word which can
> be qualified of repeating or switching feature. In France, hubs is opposed
> to switches (or bridges), but I can all the same to be clear on a generic
> word for gathering both device concepts.

In marketing-speak generally if it says "hub" on the label one may assume a
repeater and if it says "switch" one may assume a bridge, but this has
become complicated as multiport bridge ICs have become cheaper, the ability
to support multiple speeds has become necessary, and as routing features
have been added to switching hubs.

For the rest of this when I use "hub" and "switch" assume I mean a device
labelled as such, regardless of its actual function.

The result is that multiple-speed "hubs" are often several multiport
repeaters connected by two-port bridges to allow multiple speeds to be
handled, sometimes inexpensive "hubs" are implemented as bridges because it
was cheaper to implement using bridge chips (a 5-port gigabit bridge which
also supports 100baseTX and 10baseT is a single not terribly expensive chip
for example, and in a few more years they'll be 50 cent parts) than as a
conventional repeater, and a "switch" may in fine print say "layer 3" which
makes it a router. Unfortunately spec sheets these days seldom contain
enough detail for one to be able to determine how the particular device is
actually implemented--you have to take one apart and refer to chip vendors'
data sheets in many cases, _if_ the identifying information hasn't been
sanded off of the chip or covered with a blob of epoxy.

I suggested a while back that the Committee look into finding some means of
beating the marketroids into submission with regard to nomenclature but I
think I worded my suggestion poorly as it was taken as criticism of the
terminology used in the spec and not a request to recognize that the
marketroids are creating chaos by making up their own nomenclature and by
redefining standard nomeclature to suit themselves.

> Regards,
> Michelot

--
--John
Reply to jclarke at ae tee tee global dot net
(was jclarke at eye bee em dot net)
Anonymous
November 3, 2004 11:00:25 AM

Archived from groups: comp.dcom.lans.ethernet (More info?)

In article <4186b9c8$0$3704$8fcfb975@news.wanadoo.fr>,
"Michelot" <mhostettler@wanadooNOSPAM.fr> wrote:

>
> (1) I should be curious to know why 802.3 uses sometimes the term repeater
> instead of hub. Is there a difference of meaning?
>

As others have noted, "hub" carries two meanings:

(1) Marketeers/end-users generally use "hub" as a synonym for "repeater".

(2) The standards try to avoid the use of the word "hub" altogether,
although if pushed, most network architects would define hub as a device
at the center of a star-wired topology. Thus, a hub could be a repeater,
a bridge/switch, or a router. The distinction is in the higher-layer
functionality; the commonality is in the physical topology.

> (2) The NLP pulses (or FLP) don't carry the synchronization. Can we say that
> these test pulses are asynchronous of the frame bit timing? Perhaps, 2
> consecutive frames issue from the same end TD could be even asynchronous. Is
> it correct?
>

NLPs are completely asynchronous with respect to any data frames sent
over the same pairs. FLPs are also asynchronous with respect to data
frames, but since FLPs are NOT interspersed between data frames, it is
strictly correct only to speak of the timing relationship between the
FLP burst and the *first* data frame. In any case, there is no strict
timing relationship; the two signals are asynchronous.

It is possible that two 10BASE-T frames emitted from the same station
will have a precise timing relation between them, synchronized to the
same clock. However, the receiver cannot depend on this relationship,
and resynchronizes its receive clock independently for each received
frame. The reason is that it is possible (on shared media systems such
as coaxial cable) that sequentially received frames were sent by
different transmitting stations, each with its own independent clock.
Since the receiver must deal with this (worst-case) situation anyway,
there is nothing to be gained by trying to take advantage of some
potential synchronization between received frames in the case of
dedicated media systems.

In 100BASE-T, the line signaling is synchronous; there is an active-idle
signal on the line at all times, maintaining receiver clock
synchronization even in the absence of data frames. This is, in part,
why 100BASE-T cannot support shared-media wiring systems.

> (3) When the AUI isn't separated from the DTE, can we still talk about the
> CO (control out) et CI (control in) signals? I'm wondering now if the test
> pulses come from DO or CO!
>

Yes, we can still speak of the signals, although they may be present
only in a chip-to-chip connection, or even inside a single chip. Also,
virtually no devices even implemented the CO (Control Out) signals,
regardless of whether the AUI was exposed or not. (CI--Control In is
just another name for the Collision-Presence pair of the AUI.)

Both NLPs and FLP bursts are sent on the DO (Data Out) pair; they
emanate from the device regardless of whether there is an exposed
AUI/MII or not.


--
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
Anonymous
November 3, 2004 11:03:52 AM

Archived from groups: comp.dcom.lans.ethernet (More info?)

In article <41877e8e$0$18164$8fcfb975@news.wanadoo.fr>,
"Michelot" <mhostettler@wanadooNOSPAM.fr> wrote:


> We always talk about AUI in 10Base-T, and MII or GMII. Are these interfaces
> really used? Perhaps it is used in specific applications as banking
> terminal... But, nowadays, I don't see the advantages.
>

Historically, there were advantages, such as being able to build a
workstation with an Ethernet interface without having to commit to a
coaxial cable port vs. a twisted pair port vs. a fiber port. This
approach was taken both in 10 Mb/s systems, and in early 100 Mb/s
systems. (Sun workstations used to have an MII port, and used an
external transceiver.)

Today, the interface is more useful as an abstraction for system
designers. The interface may exist physically as well, for chip-to-chip
connections (e.g., when connecting to discrete 1000BASE-T transceiver
chips).


--
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
Anonymous
November 4, 2004 12:43:26 PM

Archived from groups: comp.dcom.lans.ethernet (More info?)

Rich Seifert wrote:

(snip)

> In 100BASE-T, the line signaling is synchronous; there is an active-idle
> signal on the line at all times, maintaining receiver clock
> synchronization even in the absence of data frames. This is, in part,
> why 100BASE-T cannot support shared-media wiring systems.

I hadn't thought of this one before...

100BASE-T media can't support shared media wiring, but if one
wanted to implement a 100BASE-?? at the MII interface, presumably
whatever conversion needed could be done in the transceiver.

I haven't looked at the MII signals for a long time, but I
suppose it would be synchronous all the way through the MII.
Some part has to supply the clock and the other has to synchronize
to that clock, I will guess that transmitters supply it and
receivers synchronize, then the receiver should be able to
synchronize to the incoming clock on shared media, presumably
with a PLL.

It seems that we discussed here before that 100BASE-?? still
have a preamble, even though it isn't needed for synchronous
signaling. Is that preamble long enough to lock a PLL on the
incoming bit stream?

It doesn't seem likely that a coaxial 100 Mbit ethernet will
ever be created. I might wonder how well gigabit or
10 gigabit would do on coax, though. For wiring closet to
end stations, would it be cheaper than fiber?

-- glen
Anonymous
November 4, 2004 5:04:36 PM

Archived from groups: comp.dcom.lans.ethernet (More info?)

Bonjour Rich,

> Historically, there were advantages, such as being able to build a
> workstation...

It's really interesting to read that. Thanks very much.
Michelot
Anonymous
November 5, 2004 4:27:39 PM

Archived from groups: comp.dcom.lans.ethernet (More info?)

In article <2Rmid.463057$mD.175301@attbi_s02>,
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

>
> 100BASE-T media can't support shared media wiring, but if one
> wanted to implement a 100BASE-?? at the MII interface, presumably
> whatever conversion needed could be done in the transceiver.
>

In theory, yes.

> I haven't looked at the MII signals for a long time, but I
> suppose it would be synchronous all the way through the MII.

Actually, some of the control signals (e.g., Collision Detect) are
defined as completely asynchronous, but you can always run them through
a dual-rank synchronizer to align the edges.

> Some part has to supply the clock and the other has to synchronize
> to that clock, I will guess that transmitters supply it and
> receivers synchronize, then the receiver should be able to
> synchronize to the incoming clock on shared media, presumably
> with a PLL.
>

Correct; the receive data stream is synchronous to a PLL-derived Receive
Clock.

> It seems that we discussed here before that 100BASE-?? still
> have a preamble, even though it isn't needed for synchronous
> signaling. Is that preamble long enough to lock a PLL on the
> incoming bit stream?
>

It should be long enough for that purpose, yes.

> It doesn't seem likely that a coaxial 100 Mbit ethernet will
> ever be created.

As a shared medium, I agree. The problem isn't so much the real-time
synchronization of the receive clock as it is the sensitivity to
reflections caused by tap capacitances. This was a serious enough
problem at 10 Mb/s; at 1000 Mb/s it may be intractable (or at least, not
worth the effort to try).

> I might wonder how well gigabit or
> 10 gigabit would do on coax, though. For wiring closet to
> end stations, would it be cheaper than fiber?
>

Perhaps, although not nearly as cheap as UTP, which currently supports
gigabit (and perhaps 10 gigabit in the relatively-near future).


--
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
Anonymous
November 5, 2004 11:35:05 PM

Archived from groups: comp.dcom.lans.ethernet (More info?)

Bonsoir John,

Thanks for your advice.

> ...I worded my suggestion poorly as it was taken as criticism of the
> terminology used in the spec and not a request to recognize that the
> marketroids are creating chaos by making up their own nomenclature and by
> redefining standard nomeclature to suit themselves.

Standards are often made up and worded by manufacturers and private
companies, the telecom professionals. And the marketoids you're talking are
members of these companies, or from their distributing system.

Regards,
Michelot
Anonymous
November 5, 2004 11:35:06 PM

Archived from groups: comp.dcom.lans.ethernet (More info?)

Michelot wrote:

> Bonsoir John,
>
> Thanks for your advice.
>
>> ...I worded my suggestion poorly as it was taken as criticism of the
>> terminology used in the spec and not a request to recognize that the
>> marketroids are creating chaos by making up their own nomenclature and by
>> redefining standard nomeclature to suit themselves.
>
> Standards are often made up and worded by manufacturers and private
> companies, the telecom professionals. And the marketoids you're talking
> are members of these companies, or from their distributing system.

So which "manufacturers and private companies, the telecom professionals",
made up and worded the "Pre 802.11N" standard with which certain equipment
currently on the shelf at CompUSA purports to be compliant?

Yes, the marketroids are employees of some company somewhere. Being an
employee of a company somewhere does not make one responsible or sensible
or smart or even sane.

Every company that puts boxes on the shelves in stores is not run by
"telecom professionals" or professionals at anything else except
money-grubbing. The simple fact is that you can buy a chip from Intel or
SiS or AMD or Marvell or whoever and stick it in a circuit board and sell
it as a hub or router or switch or gonkalator armature or whatever without
knowing much more than how to implement the reference circuit described in
the datasheet. And the claims that are made by whoever builds and sells
the box often bear little resemblance to the claims made by the true
"telecom professionals" who designed the chip.

I don't know why you're defending these twits. The folks who write the
standard are not the problem, the ones who act as if there is no standard
or the standard doesn't mean anything or the standard doesn't apply to
_them_ are the problem.


> Regards,
> Michelot

--
--John
Reply to jclarke at ae tee tee global dot net
(was jclarke at eye bee em dot net)
Anonymous
November 6, 2004 2:01:58 AM

Archived from groups: comp.dcom.lans.ethernet (More info?)

Bonsoir Rich,

> > (2) Is the automatic detection of the cable twisted pair connection
> > (straight or crossover) is also an effect of the autonegotiation? I
don't
> > see that in 802.3 but perhaps, I haven't read correctly.
> >
>
> No, auto-polarity (as it is sometimes called) is outside the standard,
> but commonly implemented in commercial transceivers because it is so
> useful.

Sorry, I don't explain correctly.

Suppose I connect a MDI to a MDI-X through a crossover cable instead of a
straight cable. We have an emitter face to an emitter, and a receiver face
to a receiver. In this case, it's not a polarity issue, but a question of
pair inversion.

It's the same thing if we connect a MDI to a MDI through a straight cable.
I heard that some devices detect that and try to invert the pairs. Have you
seen that?

Regards,
Michelot
Anonymous
November 8, 2004 11:56:53 AM

Archived from groups: comp.dcom.lans.ethernet (More info?)

Michelot wrote:

(snip)

> Sorry, I don't explain correctly.

> Suppose I connect a MDI to a MDI-X through a crossover cable instead of a
> straight cable. We have an emitter face to an emitter, and a receiver face
> to a receiver. In this case, it's not a polarity issue, but a question of
> pair inversion.

Yes, they can put drivers and receivers on both sides, with an
enable on the drivers. Once it detects which one is in use, it can
enable the appropriate drivers.

On devices that support 1000baseT, which sends and receives on
all four pairs at the same time, it is easy to do, and many do it.
Otherwise it is relatively rare, but I have known some to do it.

-- glen
Anonymous
November 8, 2004 8:27:10 PM

Archived from groups: comp.dcom.lans.ethernet (More info?)

Bonjour Glen,

> Yes, they can put drivers and receivers on both sides, with an
> enable on the drivers. Once it detects which one is in use, it can
> enable the appropriate drivers.
>
> On devices that support 1000baseT, which sends and receives on
> all four pairs at the same time, it is easy to do, and many do it.
> Otherwise it is relatively rare, but I have known some to do it.

The optional function is named autoswitching MDI/MDI-X or automatic
MDI/MDI-X configuration, it implies to have the auto-negociation enable.
Today, this solution exists also for 100 Mbit/s. The physical level try to
detect a link activity (frame ou pulses) during 80 to 100 ms. If no activity
is detected, the MDI pairs are switched in the other configuration, and
another listen slot time is taken, randomly, greater than 80 ms. Thus, the
probability that both sides take the same duration is low. Both ends can
implement the autoswitching.

Regards,
Michelot