| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Mike & EEE’ers: First, let me express my regret at not being able to get to Secondly, let me express my regret at not being able to hear
and actively speak for or against the proposals for changing the objectives or
considering “subset PHYs” at the meeting. Based on my knowledge of PHYs, experience in standards
projects in IEEE and elsewhere, and under the limitations in my knowledge from
not hearing directly these discussions, it is my belief that the proposal for
expanding the objectives, coupled with a discussion of “subset PHYs”
would lead to a long-delayed and problematic EEE project, without any great
benefits. The discussion on changing the objectives seems to make much
hay of “vagueness”. However, in my opinion, the proposed
remedy of replacing the speed changes with “a lower power mode”
makes the result ambiguous, essentially opening the door to anything that
someone could argue is lower power (and 802.3 standards don’t specify the
power of devices either – and traditionally this is an area of much
disagreement between vendors and their implementations.). Furthermore, this
change has the potential to make EEE as complicated as starting 4 new PHY
projects at once – something it would be difficult to see the bandwidth
for in the industry (Even though it would be a great job-protection program for
guys like me ;) While Pat has raised some important arguments about required
transition times that I think need to be incorporated, I believe that we could
incorporate a link to QoS or shorter switching time with less pain. The
pain is considerable, and I don’t believe the authors have fully
considered what training and transitions would need to occur with a subset PHY.
Some more technical detail is below, but let me cut to the chase – a
new PHY is unnecessary, if you solve the startup fine-training and link-test
problem. Any subset PHY would have to solve this anyways on the upshift
transition. As someone in this discussion who has brought up robust
10GBASE-T PHYs, I tell you that turning on and off FEXT, NEXT and ECHO filters,
changing PAM levels, as well as disabling FFEs to save power, even if you cycle
the pairs, which has it’s one problem, you will still have to
occasionally fine-train and most always re-check the link integrity. The
easiest way to do that was to reuse the PHY control diagram in 10GBASE-T, and
that was the source of my analysis. If 10-20msec is too long, as Pat
suggests, then we’d have to do something else. The main sources of the longer switching time come from the
use of the existing PHY control transition mechanism in 802.3an for transition
states in fine-retraining and testing the high-rate link on the upshift
transition. The lion’s share of this process is driven by the infofield signaling
in the 802.3an standard. Any faster transition would require a reworked signaling
scheme anyways, so why not use it for upshifting from an existing, well-defined
PHY, and have to deal with only about 10% of the standards work? (which is
still a lot, since it’s on several PHYs). That’s the gist of it. What follows below are
some specific examples of where the “subset PHY” arguments go awry. First, the discussion on complexity of shifting using
existing PHYs is overblown. Nobody in their right mind wanting to downshift
from 10GBASE-T to 1000BASE-T would add a math coprocessor just for the purpose.
It’s easier to straight decimate and train a response. After
all, we’ve all been told (and some have seen) that 1000BASE-T trains very
rapidly, and beginning from a close target response should get it there even
faster. Keeping a prior stored state should be sufficient.
First-time training would take longer, of course, but that will be true
regardless. Speaking as someone who’s spent a lot of time in the
lab getting many different PHY types working, I’m afraid that the
thinking on the subset PHY proposals themselves seems a bit oversimplified, and
lacks practical experience. A simple example of this is the “pair
cycling”. The wire has memory, which is LONG in terms of symbol
times. Thus, you’d either have to wait for things to clear for up
to 1 usec or re-enable echo and NEXT cancellers…. Another example
is that the discussion seems to believe that you can switch on a frame
boundary. Frame switching would need to be synchronized at the PHY level,
which would require out-of-band signaling – something there isn’t
significant room for in the link. And then there’s the fact that
the link has latency of 2.5usec (hence 5usec round trip….) So
single-digit microseconds are out. And then there’s the issue of
how the upshift is accommodated. Re-entry requires re-synchronization and
testing of the LDPC link. That was the MAIN reason for entering into the
10GBASE-T PHY control state machine and taking a 10 msec hit. As mentioned before, the 10-20msec doesn’t come from
the fact that you’re using 1000BASE-T as the low-speed state, but rather the
re-use of the 10GBASE-T PHY control to do 2 things: 1) fine-tuning the 10GBASE-T receive
path from a state that isn’t sufficient for PAM-16 transmission (this
would have to be done as well upshifting from a subset PHY – PAM4
training is different from PAM16 training, and simplex transmission, without
FEXT will lead to changes in the coefficients of the NEXT cancellers, because
the receive filter response will drift). And, 2) synchronizing and testing
the LDPC decoder to ensure a good link before data is re-engaged. Testing
the link itself takes many frames of LDPC data, and, if you use the link
quality metric in the 802.3an standard, that in itself costs 125usec. However, the main cost is really
using Gottfried’s infofields and the protocol already developed for
managing the transitions, and the PHY control machine in the standard.
These require state transitions to take hundreds of usec. If you simply
go away and develop a new transition scheme (which is much easier than defining
an entirely new “subset PHY”) you can reduce the time
substantially. This is the right place to focus if you really want to
change the upshift transition time. In summary, changing the objective language to be a lower
“power state” makes it VERY ambiguous and nebulous, and
doesn’t define speeds. It broadens the scope of EEE to make it
likely unmanageable, and more likely to produce market confusion. I would
not support that. I further do not think that including “subset
PHYs” solves any problems, and creates a whole set of new ones, including
the workload of 802.3an defining multiple PHY types at one time. What I DO support is the effort to
put some numbers on the switching time. You have made an interesting case
that the time has to be under 10msec, and probably near 1 in the case of
certain applications. I’m not sure that any rationale switching
algorithm would be dropping the speed if there were a constant video feed
running or a constant set of VOIP calls running. (And, if it’s just
one call, does anyone really care if it warbles a bit…) However, we
do need to be talking with the appropriate application developers to allow the
EEE switching to be sensitive to QoS. This begs the entire question of
WHERE and in what body the rate-control algorithms will be developed. That is where the application problems Pat raises should be
solved. Not by redefining entirely new PHYs, which would take years and
end up with things that looked nice from 40,000 feet, but don’t look so
great when you get close. -george George A. Zimmerman Founder & CTO, PHY Technologies Solarflare Communications gzimmerman@solarflare.com Tel: 949-581-6830 x2500 Cell: 310-920-3860 |