[daip] Re: Large experiments, VBGLU, etc.

Jon Romney jromney at aoc.nrao.edu
Mon Mar 20 11:36:14 EST 2006


I thought I had given several compelling reasons why the
"burden on the users" would be negligible, while to do
nothing would continue several user-unfriendlinesses that
we could eliminate by going to pure Mark 5 operations.

This morning, I thought of a couple more advantage in the
latter category:

     d)  Mark 5B becomes possible, making 1-Gbps operation
     available for our best users.  As long as we have to
     stick to tape playback, our bandwidth capability will
     remain very limited.

     e)  Substantial simplification of the software that
     must be modified for Mark 5B.  If we can reduce the
     famous 2 work-years enough, this upgrade will become
     more feasible.

We will also have a lot more credibility to get Mark 5B
implemented the way we need it if we demonstrate a con-
tinuing commitment to Mark 5A.  I'm going off to JIVE now
to debate this issue, and it's hard to think anyone will
take NRAO's requirements seriously if I have to begin by
saying we are sticking to tape.

If there is a political reason for doing so, that has to
be taken seriously, of course.  But it sure needs a better
cover story than burdening the users.  I also am fairly
skeptical that the EVN stations will want to buy us some
more Mark 5 units.  Aren't they likely to say they already
arranged for ESA to buy us three units, and we should move
two of them to the correlator as extra playbacks, and buy
our own units for the VLBA stations?

Jon


Jim Ulvestad wrote:
> Yes, it was triggered by the test meeting report.
> 
> The problem is that y'all are talking about accepting disks
> from more stations than we have playbacks for, thus shifting
> the burden from the stations onto the users.  Once we do
> this, we have lost all leverage to get the stations to help us
> out with playbacks if they want to abandon their tape drives.
> 
> Jim
> 
> R. Craig Walker wrote:
> 
>> Jim,
>>
>> Was this triggered by my test meeting report?
>>
>> Jon has been testing the long-unused ability to process large 
>> observations
>> with multiple pass processing to make sure we have a way to handle a 
>> small
>> number of such projects that may come through here for which we do not
>> have enough tape drives.  We have very little realistic prospect of
>> getting more than 14 playbacks so this gives us a way to handle a few big
>> globals and RDVs.  And it may give an alternative that will allow foreign
>> stations to abandon the tapes that are starting not to work very well,
>> causing us considerable pain on correlation.  We certainly don't want to
>> subject smaller projects to this sort of thing while we have an
>> alternative.
>>
>> Cheers,
>>
>> Craig
>>
>>
>>  
>>
>>> Hi all,
>>>
>>> On the VLBA, why are we correlating projects (if we are) with
>>> 13 disk stations, for our 11 disk playbacks.  This makes life
>>> miserable for the users.  Shouldn't we be recording only 11
>>> stations on disk in that case, as I thought we had planned,
>>> and a couple stations on tape?
>>>
>>> Making a large number of users use VBGLU is not conducive
>>> to making the VLBA more user friendly.  For 20-station
>>> RDVs, the geodetic folks can buy us playbacks if they want
>>> to get all 20 stations.  If we can get to 14-station support for
>>> HSA, I'd rather spend another $100K keeping St. Croix from
>>> collapsing than spend it on playbacks, and I bet the RDV people
>>> sure would like to have SC as well.
>>>
>>> I'm copying this to daip because of the work that has been done
>>> on VBGLU and VBMRG recently.
>>>
>>> Jim
>>>
>>>   
>>
>>
>>
>> ---------------------------------------------------------------------
>>    R. Craig Walker            Array Operations Center
>>    cwalker at nrao.edu           National Radio Astronomy Observatory
>>    Phone  505 835 7247        P. O. Box O
>>    Fax    505 835 7027        Socorro NM 87801   USA
>> --------------------------------------------------------------web
>>
>>  
>>
> 




More information about the Daip mailing list