20010724: University of Costa Rica connectivity (cont.)

>From: =?X-UNKNOWN?Q?Jimmy_Mejia_Fern=E1ndez?= <address@hidden>
>Organization: University of Costa Rica
>Keywords: 200106050208.f5528Sp02926 LDM ingest decode

Mario Guerra wrote:

>> Dear Ms. Wilson:
>> 
>> I'm Mario Guerra, system administrator in the CI (computer center) of the
>> University of Costa Rica. My email is address@hidden.
>> 
>> I'd like to work closely with you for solving this weird problem that
>> Jimmy told me about.
>> 
>> The connectivity situation is as follows.
>> 
>> For many months we had a very difficult situation with bandwidth but that
>> changed some months ago when the submarine cable started to work with
>> plenty of bandwidth for the Costa Rica Academic Network. This connection
>> serves about 10 Mb/seg to several academic institutions, both universities
>> and investigation labs.
>> 
>> The UCR is connected by a T1 which is shared by web, mail and other
>> applications. This T1 is connected to a 2 Mb/seg. which sometimes shows a
>> mild saturation. This link is connected to another 2 Mb/seg. one which
>> shows no saturation. The next one is a double 2 Mb/seg. (4
>> mb/seg. total) wich shows a 70/80% bandwidht ocupation rate), which in
>> turn is connected to the submarine link.
>> 
>> In short, except for the immediate UCR network we don't have a critical
>> situation with our bandwidth. Moreover, due to a job done with our proxy
>> servers, about 1/2 of the inbound bandwidth is saved. This means that the
>> UCR link is very well. The NEXT link is the problem, but, fortunately, it
>> not always saturated. When it isn we can get 6, 8, 10, 12, even 18
>> KB/seg. for an FTP. When there is a slight to moderate saturation, we can
>> get 2-4 KB/seg.
>> 
>> On the other side, an unusual OUTBOUND saturation was produced on
>> Thursday 18, Friday 19 and Saturday 20 . This was provoked, seemingly, by
>> a repeated DOS attack on one of the workstations a in regional site of the
>> UCR. Could you repeat the tests you talked above and tell me and Jimmy?.
>> 
>> In short, we shouldn't have problems for getting the data. I'm going to
>> make more investigation about this. It does not seem to be related to
>> bandwidth problems. One possibility is that some port used by these
>> applications is blocked (the 388 and 503 ports).
>> 
>> One more thing that can be of interest. We don't allow to many
>> connections to web and we hace delay pools that limit download of big
>> objects by web. This has helped us quite a bit.
>> 
>> I hope this information helps to solve this nagging problem. After all, it
>> is about science research, nothing less....
>> 
>> Best regards.
>> 
>> Mario Guerra - address@hidden

Hi Mario and Jimmy,

Thank you for the information.  Mario, I look forward to working with
you on this problem.

I'm sorry, but I'm not understanding some of your terminology.  What do
you mean by 2 Mb/seg.?  Do you mean 2 megabits per second?

The tests we've done from here are still not showing very good
end-to-end connectivity.  Again this morning we logged on to inti and
ran a test using McIDAS IMGCOPY from motherlode (the machine
feeding inti IDD data) to inti.  It took about 13 minutes to transfer
an uncompressed, GOES-East VIS image.  We also ran another FTP test.
ncftp reported rates from 400 bytes/second to 1.3 Kbytes/second.  For
comparison, we did a similar test from a site, the University of Puerto
Rico, which often reports difficulty receiving imagery in the IDD.
They were able to FTP at about 60 Kbytes/second, a rate 60 times faster
than your connection.

I'm wondering about your submarine link because our experience was that
connectivity got worse around the April time frame.  Is that about when
you got that link?

I think it would be useful for all of use if you ran a series of
tests.  We are interested in seeing how long it takes to FTP image
files (from motherlode to inti) at various times during the day.  You
can FTP the files you're interested in from our server,
motherlode.ucar.edu.  We setup ncftp access to motherlode under the
'mcidas' account on inti.  The bookmark used is 'motherlode'.  This
will put you in the decoded/mcidas/RTIMAGES/GE-VIS directory.  The set
of images that Jimmy expressed interest in were all from GOES-East.
These can be found in the following locations:

VIS - decoded/mcidas/RTIMAGES/GE-VIS
IR  - decoded/mcidas/RTIMAGES/GE-IR
WV  - decoded/mcidas/RTIMAGES/GE-WV

Also, it would be very interesting to see how long it takes to get the
same images using McIDAS ADDE transfers.  We also setup your 'mcidas'
account to have a local dataset named MYDATA.  MYDATA has groups for
images (MYDATA/IMAGES), point source files (MYDATA/PTSRCS), grids
(MYDATA/GRIDS), and topography images (MYDATA/TOPO).  You can see this
by:

<login to inti as 'mcidas'>
cd workdata
dsserve.k LIST MYDATA

Using ADDE to copy the latest GOES-East VIS, IR, and WV images can be
done as follows while timing the transfers:

<login to inti as 'mcidas'>
cd workdata
time imgcopy.k RTIMAGES/GE-VIS MYDATA/IMAGES.140 SIZE=ALL
time imgcopy.k RTIMAGES/GE-IR  MYDATA/IMAGES.150 SIZE=ALL
time imgcopy.k RTIMAGES/GE-WV  MYDATA/IMAGES.210 SIZE=ALL

By getting quantative numbers for how well data files can be transferred
to init, we should be able to better understand how good the end-to-end
connectivity is from inti to motherlode.

Another possibly revealing test is a program called netcheck that comes
with the LDM.  It uses ping and traceroute to check network connectivity
over time.  Basically it checks for packet loss and sends an email if
the packet loss drops below a configurable threshold.  It is
configurable via the file netcheck.conf that resides in ~ldm/etc. 
Here's a sample cron entry:

# run netcheck every 2 minutes
#*/2 * * * *    /usr/local/ldm/bin/netcheck

For your information, both Tom and I are very busy at the moment
preparing to teach workshops.  We will have much more time to devote to
your problem after they are over, in about two weeks.  In the mean time
we can only provide short responses.  I hope that you can bear with us
until the workshops are over.

Anne and Tom