Re: [STDS-802-3-EPOC] Link Ad Hoc Notes
Geoff,
I still disagree. What you call "cable TV" is a bi-directional service. I
don't see one-way as useful for any of the services cable operators sell
today. Each and every cable service today is bi-directional. Even
non-service uses (aka transponders) are bi-directional so they can be
managed. Even devices like power supplies have bi-di communications for
management. These simply is no one-way only service. Even those that
"appear" to be one-way are really two-way for key exchange, management, data
collection, etc.
You are saying, the technology we are developing should support a one-way
service and I say that is not useful and not a good use of effort/time. I'm
respectfully disagree, not putting words in your mouth.
-Victor
From: Geoff Thompson [mailto:thompson@xxxxxxxx]
Sent: Thursday, April 18, 2013 11:02 AM
To: Victor Blake
Cc: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] Link Ad Hoc Notes
Victor-
You are trying to attribute things to my statement that aren't there.
I have not said, nor would I say that two way communication on coax is (a)
not useful, (b) more useful than one way communication. Also, it is
certainly true that 2-way coax data communication has been around for a long
time, even in an integrated broadband sense. See clause 11 of 802.3 for an
example.
That does not mean that one way communication systems have not existed and
been economically viable, they have. One major example was called cable TV.
I had such a service at my residence as recently as a year ago supplied as a
revenue service by a major participant in this standards effort. Therefore
your argument that it is "not useful" is non-sensical. Even if the fact that
it is substantially less useful is true (and it is). Even if it is true
that a one way system by itself would not be worthy of a standard (also
true).
My point was only that including a minimal one-way downstream capability is
useful for diagnostic reasons. You may disagree with me, but you would be
wrong.
Geoff
On 4/18/13 5:46 AM, Victor Blake wrote:
#1 - Two-way data communications isn't a recent phenomenon. It's been in the
cable plant for decades. So while users may not have used "two-way"
services, STB's have been two way for decades (literally). Applications like
NAVIC are not new. So I definitely disagree.
#2 - Regardless of history, one way has no utility. And there is no
relationship between coax and one-way. Coax is widely used for two-way
communications beginning with - as it turns out this thing called
"Ethernet".
-Victor
From: Geoff Thompson [mailto:thompson@xxxxxxxx]
Sent: Thursday, April 18, 2013 1:19 AM
To: Victor Blake
Cc: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] Link Ad Hoc Notes
Victor-
I don't understand how you can deny the market existence and success of the
first 50 years of the cable industry.
During that period, cable systems were one way only, yet proved to be a
viable enough business to pay for installing a great deal of the coax that
you are trying to reuse.
In addition, I have no trouble whatsoever imagining use on a diagnostic
basis for a 1 way broadcast data signal.
In our twisted pair standards it is called Linkbeat. It is the signaling
vehicle for AutoNegotiation.
An unpowered very inexpensive pen size handheld tester is a quite useful
tool to see if the other end of a Cat 5 cable is plugged into a live switch.
For example, it is quite common to have a two jack outlet in an office
cubicle. It is just as common for only one of the outlets to be live.
Geoff
On 4/17/13 7:20 PM, Victor Blake wrote:
Geoff,
I don't see how a receive only state is useful. Whether it is for broadcast
or diagnostics, return data path is required. I'm not sure what you mean by
a long history of providing services that are broadcast only. All of those
"broadcast only" are two-way services for authentication, data collection,
quality monitoring, etc.
-Victor
From: Geoff Thompson [mailto:thompson@xxxxxxxx]
Sent: Wednesday, April 17, 2013 1:44 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] Link Ad Hoc Notes
Folks-
I happen to disagree with this conclusion.
I can see a number of reasons that it would be be very useful to hold a CNU
in a state that prevents PLC hunt/acquisition for an appreciable duration of
time.
After all, the cable industry has a long history of providing services that
are broadcast only.
Further, it certainly might be useful to have CNUs that have been installed
but not provisioned for actual service be able to operate in a receive-only
"diagnostic/ready-for-service" mode when powered up.
(i.e. Operator: Plug the box in. Does the box say "Ready for Service"?)
Also, it could be useful for system diagnostic purposes (i.e. fault
isolation) from a central location. Any thing to save a truck roll.
Geoff
On 4/17/13 8:06 AM, Marek Hajduczenia wrote:
Thank you Bill,
That would imply that such a register should be accessible only locally (by
CNU management clients) and not remotely (by CLT management clients)
Marek
From: Bill Keasler [mailto:bkeasler@xxxxxxxxxx]
Sent: Wednesday, 17 April, 2013 3:59 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] Link Ad Hoc Notes
My working assumption is that HALT/PAUSE would be asserted prior to updating
the frequency control registers and that after the update a RESTART would
signaled through MDIO followed by a de-assertion of HALT/PAUSE.
I agree with your observation that it would be not be very useful to hold a
CNU in a state that prevents PLC hunt/acquisition for any appreciable
duration of time.
Regards,
Bill K.
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx]
Sent: Wednesday, April 17, 2013 9:54 AM
To: Bill Keasler; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-3-EPOC] Link Ad Hoc Notes
Bill,
Would that happen to be a remotely controlled (from CLT) action? I always
thought that the PLC hunt would be pretty much always on and once the lock
was lost, the only thing that the CNU could do was actually go and start
hunting for PLC. I wonder how useful a CNU is when it sits around without
PLC connection . we would not be able to do much with such a device.
Marek
From: Bill Keasler [mailto:bkeasler@xxxxxxxxxx]
Sent: Wednesday, 17 April, 2013 2:49 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] Link Ad Hoc Notes
Although I do NOT have (at the current time) specific recommendations for
the bit fields in the control register, I would expect that the ability to
HALT (or PAUSE) PLC hunt/acquisition and the ability to RESTART PLC
hunt/acquisition would be useful.
Regards,
Bill K.
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx]
Sent: Wednesday, April 17, 2013 6:24 AM
To: Bill Keasler; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-3-EPOC] Link Ad Hoc Notes
Hi Bill,
Can you provide a few words on the PLC_SRCH_ CNTRL (R/W) and PLC_SRCH_
STATUS (RO) registers, that are grayed out in your presentation? I assume,
by their name, that the first one is an enable/disable switch, allowing the
CLT to remotely control whether PLC hunt is enabled or not. However, if the
PLC hunt is disabled, then how can the CNU locate PLC and start working in
the first place. I think PLC hunt should be always on, and what we can
optimize is the expected range of frequencies that should be scanned in the
process of PLC hunting.
I assume that the status register (PLC_SRCH_ STATUS) reflects the PLC lock
status (locked / hunting) and makes perfect sense to me.
Perhaps I am off here, but these registers are listed without any
explanation and I was wondering what we plan to do with them .
Regards
Marek
From: Bill Keasler [mailto:bkeasler@xxxxxxxxxx]
Sent: Tuesday, 16 April, 2013 8:48 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] Link Ad Hoc Notes
I am forwarding some rough notes on the idea of exploiting three MDIO
registers to control the frequencies scanned during PLC acquisition. I am
hoping to have a few minutes to discuss during the 17APR PHY Link Ad-Hoc.
Regards,
Bill K.
From: Ed (Edward) Boyd [mailto:ed.boyd@xxxxxxxxxxxx]
Sent: Monday, April 15, 2013 11:50 AM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-3-EPOC] Link Ad Hoc Notes
All,
Sorry for the delay sending out the notes from last week's meeting. The
meeting was focused on the baseline proposal for the next meeting. I have
attached the slides with the working baseline. The notes are below. Mark;
please post the slides. We would like to see proposals on the FEC/CRC for
the PLC, preamble for the PLC, hunting procedure, and TDD PLC cycle.
Thanks,
Ed.
Review baseline proposal and questions
- Nicola will have presentation for TDD PLC frame duration
- PLC cycle for FDD is clear due to alignment with pilot pattern.
- PLC cycle for TDD is not clear and needs presentation. Nicola will present
in
future meeting.
- Preamble needs definition. Preamble is a single fixed pattern of lower
than
QAM16. Preamble is not covered by FEC and infrequent errors in preamble will
not cause bit errors in frame.
- Differences are minor between Duane/Hesham/Ed and Marek's proposal for
instructions. To be discussed at future call.
- FEC+CRC will be considered to determine error performance of channel.
Description: Description: Description: Description: Description:
Description: Description: Description: Description: Description:
Description: Description: cid:image009.jpg@01CD505E.7B800DB0
Edward Boyd | Sr Technical Director
Broadcom Corporation | (O) 707-792-9008 | (M) 707-478-1146
<http://www.linkedin.com/company/broadcom> Description: Description:
Description: Description: Description: Description: Description:
Description: Description: Description: Description: Description:
Description: Description: image005 <http://twitter.com/#%21/broadcom>
Description: Description: Description: Description: Description:
Description: Description: Description: Description: Description:
Description: Description: Description: Description: image002
<https://www.facebook.com/Broadcom> Description: Description: Description:
Description: Description: Description: Description: Description:
Description: Description: Description: Description: Description:
Description: image003
<https://plus.google.com/109188783526874806673/posts#109188783526874806673/p
osts> Description: Description: Description: Description: Description:
Description: Description: Description: Description: Description:
Description: Description: Description: Description: image004
<https://www.youtube.com/user/BroadcomCorporation> Description: Description:
Description: Description: Description: Description: Description:
Description: Description: Description: Description: Description:
Description: Description: image006 <http://blog.broadcom.com/> Description:
Description: Description: Description: Description: Description:
Description: Description: Description: Description: Description:
Description: Description: Description: image008 <http://broadcom.com/>
Description: Description: Description: Description: Description:
Description: Description: Description: Description: Description:
Description: Description: Description: Description: image007
_____
<="" p="">
_____
<="" p="">
_____
<="" p="">
_____
<="" p="">
_____
_____
________________________________________________________________________
To unsubscribe from the STDS-802-3-EPOC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1
