Mark 5 discussion over lunch in Barcelona September 8, 2001

Attendees: Walter Alef, Bob Campbell, Ed Himwich, Kerry Kingham, Chopo
Ma, Franco Montavani, Arthur Niell, Richard Porcas, Nancy Vandenberg,
Alan Whitney

1. Who needs VSI (5B) capability and who should pay:
     VLBA formatter stations would need it for 1GB and high rates
     Mark IV stations could use two to get to ~1.8 Gb/sec
     New stations (e.g. Sardina-RT) would want to buy it
     Stations that want to have VSI compatibility (input only)
     Correlators that want VSI compatibility would need it (output
       only)
     Somewhat costly to design, but cheap to replicate
     Design cost is already included in the development contribution

2. How do you access the data on disk to, for example, ftp a small
   quantity:
     This would require a small amount of software in the Mark V Linux
       control computer
     This is expected to be available with Mark 5 prototype (Spring
       2002)

3. What provisions are there for station phase-cal extraction:
     Stations with Mark IV decoder or VLBA racks could continue to use
       them for phase-cal extraction
     Mark 5A will have 2 selectable tracks to be sent to the Mark IV
       decoder
     VLBA rack phase-cal extraction would have to be handled by
       maintaining synch with VLBA formatter (awkward?).
     It is unclear at this time how pcal extraction would be handled
       for new stations: require Mark IV decoder? Some integrated
       into Mark 5B? How expensive?
     A Mark 5 based pcal extraction (hardware or software) is possible,
       but not currently planned (should it be considered further?)
     It is possible that digital-BBC replacements will be available
       within a couple of years, which will change interface quite
       a bit (i.e. no samplers; direct connection from BBC's to VSI)

4. Will there be a provision to playback some data to a decoder at the
   stations for tests:
     For Mark 5A, it will playback to mark IV decoder or VLBA DQA
     Will this older hardware also be required for this function with
       Mark 5B?
     What future solution or what for new systems? Require Mark IV
       decoder?

5. What could be done to combat pilfering:
     No good answers. We can *hope* it won't be too much of a problem.
     We don't want to modify the disks since this reduces the economy
       of the system. The box and disk carriers may discourage some
       theft.
     Can we come up with something else?
     Pilfering could be a concern both in shipping and at stations.

6. Upgrade path:
     As disk sizes change we would just buy bigger disks. B.I. card
       handles it.
     It would be desirable to keep all the disks in a set the same size,
       but bigger disks could always be included although you would
       lose bandwidth when the smallest disk is filled, so one
       strategy would be be treat the set as all being the size of the
       smallest disk in the set.
     Disk specification (ATA-IDE?) is likely to continue for several
       years, 3? 5? 10? What then?
     Haystack would retain the right to reproduce B.I. card if they stop
       making them (can they squeeze us on the price before they stop
       making them ?).
     A replacement card for the B.I. card could be designed (by EVN?)
       and replace the B.I. cards.

7. EVN :
     The EVN seems to be willing to support Mark 5 although they still
       have some reservations
     We don't want EVN/CMVA/IVS/VLBA to go different ways. Redundant
       incompatible equipment at the same site would be a mistake,
     Haystack has almost a one year headstart, which is hard to
       overcome.
     EVN has a manpower shortage which probably precludes much
       development contribution
     MPI has already joined on its own
     CNR and Yebes will join on their own?

8. Maintenance of Linux kernel for control PC could be an issue:
     FS is on fourth kernel to keep up with changing PC hardware
     Mark 5 DTS is likely to need simpler kernel (no X for instance)
       so it may be easier to keep the same kernel for a long time.
     A new B.I. card driver might be needed if there is a kernel change,
       how would that be handled?

9. It is unfortunate that the Mark V disk carriers are the same as the
   new PC FS ones. It would be nice if they could be be non-swappable

10. It might have been desirable to have B.I. card do data decimation if
    one or more disk dies to maintain bandwidth of system. This
    would prevent a disk set from ending early as well. Probably
    too late for this change.
      Normally, bandwidth capability of a set of discs will
        significantly exceed the actual bandwidth being recorded so that
        loss of one or two discs should not cause data-rate overload on
        the remainder.
     But recording time will still be reduced?

11. FS should be able to access the health of the disks to see if the
    operator should change one.
      Status of disc health will be reported by Mark 5

12. Will Mark 5B include a monitor port for the 1 PPS being used to
    time tag the data. VSI-H seems to include this, so it presumably
    is included.
      Yes.

13. Disks are hot swappable, put probably not swappable while writing is
    occurring. It is probably too late to specify that even if it were
    possible.
      Hot swappable between scans only.

14. How do we define the command set:
      Meeting? who? where? when?