| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi - after some conversation with Mike, here is my view of TP3 (&
2) testing and some suggestions. Much of this has already been expressed by
others.
Goals
I have 3 goals that are not mutually exclusive:
1. The tests should reasonably assure interoperability;
2. The tests used should be common and consistent among all users;
3. The tests should be as simple as possible.
Are there more?
Questions to ask:
Can we agree with a set of goals?
Can we get some agreement on what is meant by "reasonably". There is no
such thing as the perfect test, but how rigorous do we want to be?
An important point - there is a difference between rigor and complexity. I
generally tend towards rigor, but also prefer simplicity. Due to schedule
pressures, 802.3ae did not find the right combination, and in fact, it could be
argued that we did not do completely well in either aspect.
Willingness to compromise? I believe the
philosophical positions in our case are approaching the goals from
different starting points. As long as the group that wants to start with simple
tests is willing to add components as justified by rigor, and as long as the
group that want so start with complex tests is willing to remove test components
as justified by simplicity, we should be able to get through this. So to me, I
want to stand in the middle as long as I sense a good attitude of willingness
from each direction.An approach
For me to progress, I need more information. Perhaps we can approach this
apparent impasse by examining each test component that is at
issue:
1. Magnitude or significance (in dB, I suppose) and how variable the
magnitude is with product implementation.
2. Test implementation (setup, method - with a view on complexity, cost,
time to test, etc.); Lew has suggested this already.
3. For simplification, can rigor still be assured if the test is
replaced by a fixed OMA penalty term? Would the penalty be fair to all
product implementations?
If we do this for the test components that are at issue (dynamic penalty,
RIN - are there others?), hopefully we'll be able to gather enough information
for some of us to make informed decisions. Should a smaller group be formed for
each test component being discussed?
Finally, even if we do wind up with a complex test, I would like to see the
document informatively (Annex?) recommend/document ways to simplify tests with
extracted components (assuming it can be justified). This would encourage the
goal of common tests.
|