送信者: Alan R. Whitney 宛先: Wayne Cannon ; Brent Carlson ; Dick Ferris ; Dave Graham ; Nori Kawaguchi ; Tetsuro Kondo ; Sergei Pogrebenko ; Misha Popov ; Jon Romney ; Ralph Spencer ; Alan Whitney ; Ed Himwich ; Ari Mujunen 件名 : Re: VSI-S draft 2 日時 : 2001年4月6日 6:08 Gentlemen, I am trying to gather a consensus from the recent flurry of e-mails and will try within the next couple of days to propose what I think is a reasonable compromise path for VSI-S. We all need to recognize that the process and the result are not likely to be perfect, and that noone is likely to, or should expect to, end up with a result that exactly suits them in all respects. The goal is to come to an end result that is workable, practical and reasonably robust without extreme measures. Please keep this in mind. In the meantime, below I try to answer some specific questions and concerns from Ed Himwich, mostly regarding VSI-H, which he is encountering for the first time and need to be explained. I will address his software concerns in my notes in a couple of days. Regards, Alan - ----------------------------- - At 04:38 PM 3/29/01, Ed Himwich wrote: >VSI-H QUESTIONS > >There are a couple of things I didn't understand about the VSI-H >document. These may have been due to my missing the relevant >information, so please excuse me if these are spurious points. > >I don't understand the P/QDATA time setting mechanism. It seems like >this is an attempt to implement a DOM-to-DIM direct tape copying system >without the use of a controller. I don't mean to sound like a union shop >steward, but is this really feasible? It seems like you would need to >have a controller to start and stop the tape, select clock rates, which >tracks are in use, etc? In fact the controller might want to use the >observing schedule and log to coordinate the copy operation. If so then >it seems like you could safely remove the DOT-set function from both >sides of the interface. The P/QDATA interface could then be used >exclusively for injecting and recovering a small amount of auxiliary >data to/from the DTS. It seems well suited for that purpose. It should >be possible to send all the auxiliary data over the control interface so >that a separate connection to the PDATA input for this purpose is not >required. PDATA/QDATA were originally envisioned as a 'hardware time code' transfer mechanism in early VSI-H discussions, mostly for purposes of media copying. But it was realized the broader utility of generalizing this capability for other potential uses, and P/QDATA were born. Essentially, the PDATA input to the DIM receives 'attribute' information regarding the data stream, which may be updated on a second-by-second basis, although the DOT_set command is a useful *command* to be transmitted by PDATA for tape copying. The control interface can equally well be used to accomplish the same thing. When being used for tape copying, the QDATA output of the DOM will duly note any time discontinuities automatically and cause the DOT clock to be appropriately updated with no intervention from the controller. Media copying is a more or less complicated affair depending on the particular type of system you are using. Mark 4/VLBA is particularly complicated. Others are much simpler and could happen pretty automatically. Of course, the controller will probably need to be present for other reasons, but managing clock discontinuities automatically is a very practical plus. The VSI-H specification is expressly non-specific on the uses of PDATA/QDATA, but suggests possible uses (see VSI-H Section 14). For example, QDATA output from the DOM is potentially highly useful in transmitting attribute information to the correlator or other type of processing device. The command set suggested in VSI-S draft 2 allows and supports specific usages, but does not prohibit others. >Why is there is an alt1pps? It seems as though selecting the 1PPS source >would be an external function. Probably there has been a lot of >discussion about this that I have missed. So taking it for granted that >ALT1PPS is needed, shouldn't it be requirement for correct operation >that when the 1PPS source is changed that a DOT_set is required? It >seems to be a potentially confusing situation if the 1 PPS can be >different from that determined the clock setting. I guess the clock >marches on using the old 1 PPS defined epoch, if you don't do a DOT_set, >but what is the point of that? Perhaps this is to allow potential >internal clock comparison circuitry in the DTS to be used to figure out >what is going on in some pathological case. Otherwise it seems like it >should be disallowed or at least discouraged. The ALT1PPS is included for stations whose 1PPS tick does not or cannot, for whatever reason, come in through the 80-pin DIM data connector. An underlying, but probably unstated assumption, is that a station will be wired one way or the other and stay that way. Switching between them is an obvious problem and wasn't even considered in our thinking space. >How far in advance of the 1PPS does the DOT_set have to be issued? This is not specified anywhere and probably should be. A suggestion might be to require that it be fully received no later than 25% of the 1PPS period before the target 1PPS tick. This would be .25 seconds in case of a normal 1PPS tick, but speeded-up or slowed-down versions are allowed in tape copying and/or playback (ROT clock), so the 25% rule might be a reasonable general rule. >H-8.1.2.5 obviously might include some AND operation on a PVALID input >and the playback units judgement of whether the reproduction is faithful This is allowed and is suggested as a possible implementation in VSI-H, if I am not mistaken >The fact that Fclock is the DAS sampler rate isn't explained until >H-10.1.3, perhaps this should be explained somewhere earlier and more >prominently, perhaps in H-7.1.1.1, since it is so fundamental. It is >hinted at in other places, but the lack of an explanation early on seems >like an omission. One thing that is confusing is that H-7.1.1.1 says >that CLOCK is a clock accompanying the bit streams, but if I understand >correctly in fact is not the clock OF the bit streams. If I want to >change sample rates do I change Fclock to the new sample rate, Fbsi to >the new bit rate, and then do DOT_set again? It is unfortunate if >changing the sample rate requires resetting the clock. I presume section >H-7.3.1 should also mention that the controller would specify the Fclock >to the DIM as well. I am a little puzzled here. CLOCK is simply the synchronous clock accompanying the data into the DIM which is properly phased to allow sampling of the bit streams. The actual sample rate used by the DIM to collect data from the bit streams is specified as a binary submultiple of CLOCK (as explained in VSI-H Section 10), with strick rules regarding sampling epoch with respect to the 1PPS tick. Unless a system is poorly designed, there should be no need to reset the DOT clock after changing the sample rate. (After much discussion, the sample rate in VSI-H was designated f/BSI and called the 'bit-stream information rate' -see the Glossary in Section 15. >12.3 Both RS-232 and Ethernet interfaces being active at the same time >seems problematic. The control interface needs to provide a function to >allow one interface to lock out command functions on the other >interface. Should there also be a lockout on monitor requests since some >status requests reset the values? It seems logical that only one interface at a time should be used, and probably should be made part of the VSI-S rules. >The document seems to imply that only pre-existing systems are allowed >to use DR format. Will all new systems be NDR? That is correct. Older systems that have been upgraded to VSI-H but have a fundamental DR format are only Level B compliant in the VSI-H specification.