Quick Install Guide And Cheatsheet For Setting Up A VSIB PC
Metsähovi Radio Observatory, Jan Wagner, 11/2006

Document Changelog:


Introduction

This document is meant to provide you a short overview of components usually needed for a Metsähovi style VSIB board equipped PC, and will give you the specifics of configuring Debian Linux to work properly with the VSIB board. It will also describe the contents and commissioning of Metsähovi preloaded and preconfigured Debian system disks.

A mini summary is at http://www.metsahovi.fi/vlbi/instr/mro-vsib-pc/minisummary.html.

Updated versions of this document can be found online, see http://www.metsahovi.fi/vlbi/instr/mro-vsib-pc/.

This document is more like a cheatsheet and quick install guide, and we will not discuss general Linux administration nor explain how to install and use Linux. If you are interested in administration basics or need Linux help, see for example the Linux Newbie Administration Guide [1] or some introductory Linux handbook as is for example provided in the retail SuSE linux package [2], or refer to the online Debian Users Guide. You may also find Linux installation help online through the homepage of your linux distribution, like via www.debian.org or www.ubuntu.com. In addition you may read the slightly outdated but quite detailed from-scratch instructions for installing a Debian 3.0 system and configuring it for VSIB, Installing VSIB/VSIC Test Software, 2003 [4] written by Ari Mujunen.

For VSIB PC/Linux and VSIB board related problems, including new VSIB driver versions, feel free to contact the Metsähovi VLBI staff. For general information about VSIB boards, please see the Metsähovi VLBI Data Acquisition page [5].

Preconfigured or from scratch install

Preconfigured system disks or recovery CD's that contain a preconfigured Debian 3.1 Linux are available from Metsähovi. These should guarantee minimum effort and hassle-free setup. Instead of shipped preloaded parallel-ATA disks it is also possible to download a set of "Recovery" CD images from this page, and use these CDs to create a system disk.

On the other hand, you may equally well start from your own preferred Linux distribution and follow these instructions to configure your linux setup correctly so you can use the VSIB board. Just note that the instructions here are assuming a Debian 3.1 setup, and that in other Linux distributions the location of configuration files and even the kernel compile process usually differ.

Instructions for using the VSIB software tools like the 'wr' recording program are given in the separate document Using VSIB Test Software, 02-2006 [6] written by Ari Mujunen.

Most relevant steps for a from-scratch install

To very shortly summarize what VSIB related steps are needed for a functional VSIB PC:

Notation

About the notation used in this document: commands to enter on the command line, names of directories or files, and the contents of some ASCII text files are displayed in a Courier font, so for example sudo fdisk -l means that this is a command that can be executed on the command line, and /usr/src/linux-2.6.17.4/ denotes a directory.

PC Hardware Requirements

These are the minimum system requirements for a VSIB PC:

Server motherboards and exotic hardware and components are usually considered a bad choice because of e.g. high price vs performance, undersized or overkill components, possible problems in Linux hardware support. Most current consumer motherboards are much better suited for VSIB use, also in regard to data throughput.

Metsähovi has been extensively using consumer PCs for VSIB. Inexpensive motherboards based on the nVidia nForce and Intel i945 / i9x5 chipset series were found to perform very well [status of 06/2006, later chipsets may be equally good and better].

It is highly preferred that all other PCI slots are left unoccupied and that no on-board devices on the motherboard (e.g. PCI network controller) are attached to the same PCI bus as the VSIB. Devices sharing the PCI bus with the VSIB may steal bandwith from the VSIB and reduce the maximum possible VSIB recording/playback rate. At maximum data rate the VSIB requires nearly 100% of the PCI bus bandwidth.

On an existing machine, with a VSIB board plugged in, you can check the bus layout by downloading http://pciids.sourceforge.net/pci.ids and running lspci -i pci.ids -vt. In the same tree node with "PLX Technology, Inc.: Unknown device 5406" there should not be any other devices, or at least, these devices should be "mostly" unused (i.e. not used concurrently with VSIB transfers) or alternatively, they should be "low speed" devices.

Installing more than one VSIB board into a PC is currently not supported by the driver - a small driver code modification is needed. Even after such a modification, multiple boards per PC are not recommended, as dual PCI bus motherboards (if still existing) are very expensive and in Metsähovi's experience did not even allow for doubled throughput. On the other hand, with two VSIBs installed on a normal single PCI bus, throughput per board will be <256 Mbit/s. Thus, unless you really know what you are doing, you should rather use only one VSIB per PC and if needed get more PCs.

Further about hardware, for recording large amounts of data fast, you may find it very useful if your PC has enough disks to create a large (>1 TB) software RAID-0 system. A typical setup would be:

Generally speaking, the simplest system hardware configuration using only commonly available inexpensive consumer desktop PC components is also the best configuration for the VSIB. If unsure, you may ask Metsähovi staff for further advice about suitable PC components.

The following are currently not supported: Microsoft Windows OS, non-x86 architectures, multiple VSIB cards per PC (slight vsib.c driver code modification necessary).

Creating A System Disk From Recovery CDs

If you do not have a preloaded system disk supplied by Metsähovi, you can use Recovery CDs or a Recovery DVD to create your own preconfigured system disk. The Recovery CDs (v1.3, 11/2006) can be downloaded below, alternatively as a single DVD or as a set of two CD's:

  DVD 1: mro-preloaded-recovery-v13-DVD.iso (685MB, burn in linux!)
  http://www.metsahovi.fi/vlbi/instr/mro-vsib-pc/mro-preloaded-recovery-v13-DVD.iso

  CD 1: mro-preloaded-recovery-v13-CD1-boot.iso (628MB, boot)
  http://www.metsahovi.fi/vlbi/instr/mro-vsib-pc/mro-preloaded-recovery-v13-CD1-boot.iso
  CD 2: mro-preloaded-recovery-v13-CD2.iso (62MB, second)
  http://www.metsahovi.fi/vlbi/instr/mro-vsib-pc/mro-preloaded-recovery-v13-CD2.iso

  Root .tar.b2: root-v13.tar.bz2 (580 MB)

Changelog of preloaded system versions: CHANGELOG.txt

In Windows you can use an ISO image burning tool like the free ISO Recorder Power Toy or the commercial Nero to create CD's from the ISO images. It can happen that the above DVD image created by Mondo Rescue can not be burned in Nero / Windows, in which case you should use the CDs instead.

In Linux you may use cdrecord, xcdroast, k3d, growisofs, the commercial NeroLinux, or other tools. For example to burn a DVD you might use growisofs -dvd-compat -Z /dev/hdb=mro-preloaded-recovery-v11-DVD.iso.

How to use the recovery DVD or CDs:

1) on a PC that has a CD/DVD writer, burn a DVD from the DVD ISO image in linux, or burn two CDs from the CD ISO images in Windows
2) prepare your target PC: install a blank(!!) P-ATA/IDE drive of >10 GB size as primary master, remove/disconnect all(!!) other hard disk drives if present!!, check BIOS settings that booting from CD is enabled
3) boot off the first CD of the set, or from the DVD
4) type RESTORE when prompted
5) automatic formatting of the disk takes a long time and the progress bar in Mondo Rescue probably freezes, but that is "normal" for Mondo Rescue
6) the actual restore process, once it starts, takes about 15min to complete - if restoring from CD, insert the second CD when prompted
7) the restore hopefully ends in "Run complete. Please remove media and reboot" and gives you a command line prompt, so, remove the CD/DVD, and type shutdown -h now to switch off the PC
8) if applicable, install any additional hard disk drives that you want to use for e.g. RAID
9) boot the PC and check that linux boots correctly into the MRO kernel (first and default entry in the GRUB boot menu)

If you have a big dislike for CDs or Mondorescue, and you know what you are doing, then you can also download the .tar.bz2 file that contains the entire root filesystem.


If downloads are too slow, please contact us for other download locations.

Preconfigured Metsähovi System Disk Summary And Customization

This information is for those who have obtained a preconfigured PATA ("IDE") system disk from Metsähovi, or have created a system disk using the recovery CD's.

System summary

The preconfigured system disk contains:

Directories:

User account information:

Default settings:

How to install the disk

To use the preconfigured PATA disk, attach it to the end of an IDE cable connected to the first IDE slot on your motherboard, and plug in a power connector to the disk. After this you can turn on the PC. The PC should now boot into the preinstalled Debian system, and you can log in as 'oper'.

If the PC has problems detecting or booting the disk, please see your motherboard's Users Guide on how to install the PATA disk as the IDE master disk. Also check which settings to change in the PC BIOS so that the PC boots from the hard disk (e.g. check the boot order settings).

The RAID will probably not work out-of-the-box. For setting up RAID, see the next section "Configuring RAID".

Customizing the system

To temporarily change to a non-US keyboard layout, you may sudo loadkeys fi (while substituting fi with your own country, e.g. sv or de).

To configure a non-US keyboard layout permanently, use sudo dpkg-reconfigure console-data
where you'd choose "Select keymap from arch list", then "qwerty", and then your country.

For further customizations like time zone , new user accounts, another host name, local apt-get package servers etc, use the easy console menu driven tool 'base-config' by running:
sudo base-config

Note that for Tsunami versions prior to version 'cvsbuild 13' / Feb13 2007 you must use UTC time zone on the server.

If you want to use a static IP instead of DHCP assigned IP for your network card, you will have to edit /etc/resolv.conf and /etc/network/interfaces. For help and examples, see man interfaces, man resolv.conf, or see the brief An introduction to Debian networking setup [7].

Original preconfigured settings can be restored (to some extent) by running cd /usr/local/siteDeployConfigs/ then sudo ./switchTo.sh default. This will delete most current settings and reapply the default configuration. Note that by running only ./switchTo.sh you will get a list of possible pre-customized configurations that you may apply, too, instead of just the default configuration. Currently available are: "default", Metsähovi "MRO", Onsala "ONS").

You may also send your own customized configuration files to the Metsähovi VLBI staff, who then can incorporate them into the /usr/local/siteDeployConfigs and thus also into possible future preconfigured disks or CD images.

Configuring RAID

Note: the preconfigured system disk assumes you will be using software RAID with four SATA disks, and not a hardware RAID. What ever the case may be, in the end you'll usually need to configure and format your RAID only once and it should work.

Hardware RAID

This section applies if you have a motherboard that supports hardware RAID, and you want to use hardware RAID instead of software RAID. First see your motherboard Users Guide on how to enable hardware RAID from the BIOS and how to configure it to use your SATA disks. RAID-0 i. e. disk striping or "fake RAID" is the best choice for VSIB use, since it is the fastest "RAID" setup, but does not protect against data loss in case of disk failures.

After you have activated and configured hardware RAID, and you are using a PATA system disk, then you most probably can now access the new RAID in linux via /dev/sda. To make sure, you may examine the output of sudo fdisk -l and spot the disk that has a few terabytes of space and no partition table. If it is e.g. /dev/sdc then of course use that instead of the /dev/sda example assumed below :-)

You should now use fdisk or the more user-friendly cfdisk to create desired partitions on the disk. Usually, you would create one primary partition, which is then accessible as /dev/sda1. For help on fdisk or cfdisk, please read their 'man' pages.

Finally, you may want to create a mount point for the RAID, for example mkdir /raid and then edit /etc/fstab to add the mount information. An example fstab line to use would be
/dev/sda1 /raid auto rw,user,auto 0 0
Also see the fstab 'man' pages. With a line similar top the above, the RAID should automatically be avaible through /raid even after reboots. To test your /etc/fstab and mount the RAID already now, use mount /raid.

Software RAID

To use software RAID, you need to install the linux 'mdadm' package first. It is already installed on the preconfigured system disk.

To initialize RAID you should first plug in the four SATA disks, then boot your PC and log in ('oper' account on preinstalled systems) and open a root shell with 'sudo bash'. On the preconfigured system disk, you can find a RAID configuration script in the /root/RAID-Setup directory, called raid-reInit.sh (download), together with short instructions in RAID-Info.txt (download).

If you do not have the preconfigured system disk, you will first have to edit /etc/fstab and add the following line:
/dev/md0 /raid auto rw,user,auto 0 0

Since the same instructions apply for users of a preconfigured system disk and for users installing from scratch, the instructions contained in RAID-Info.txt are also provided below: 

----------------------------------------------------------------------
 The RAID initialization script

   raid-reInit.sh

 assumes a system where:

   - four Serial ATA disks /dev/sda, /dev/sdb, /dev/sdc, /dev/sdd
     are installed, unused, and available for a RAID setup

   - you have used fdisk or cfdisk, or more dangerously sfdisk e.g.
       $ echo 0,,FD,- | sfdisk /dev/sda
     to create on each of the SATA disks a single primary
     partition of type 'FD' (Linux raid autodetect)

   - the system root / is safe on e.g. a Parallel ATA system
     disk and definitely not on one of the above SATA disks

   - you want a RAID-0 configured on the four disks (RAID0 is
     the fastest configuration but it doesn't offer any resilience
     or fault tolerance like true RAID)

 You can edit the script to reflect other SATA drives or a
 different RAID level.


 To create a new RAID on /dev/md0 run the above script as root.
 Your RAID files will then be available under /raid.


 If you created the RAID for the first time you probably have to
 format it first, using e.g.

   mkfs.xfs /dev/md0
   mkdir /raid
   mount /dev/md0 /raid

 It is possible that after a reboot linux forgets the RAID configuration
 or does not automatically restart RAID. In this case, run the
   raid-reInit.sh
 again after a boot (but don't reformat the disk :-), then do a
   dpkg-reconfigure mdadm
 and select automatic start of raid.
----------------------------------------------------------------------
The raid-reInit.sh script that you should call after reading and understanding the above RAID-Info.txt, and then possibly editing the script, is: 
# re-initialize the raid stack to /dev/md0,
# creating a /dev/md0 devnode if necessary

umount /raid
mdadm --stop /dev/md0

# NOTE: experiment with the chunk= parameter! and hdparm -t /dev/md0
# to get the highest speed
echo y | mdadm --create /dev/md0 --chunk=512 --raid-disks=4 --level=0 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1

# wait for sync disks, then remount
sync
mkdir /raid
mount /raid

# store settings
echo 'DEVICE /dev/hd[a-h]1 /dev/sd[a-h]1' > /etc/mdadm/mdadm.conf
mdadm --examine --scan >> /etc/mdadm/mdadm.conf

So, run the script or the commands in the script (with modifications to suit your own custom system if necessary), and then format the RAID with some file system as described at the end of RAID-Info.txt, that is, 

  mkfs.xfs /dev/md0
  mkdir /raid
  mount /dev/md0 /raid
where of course you may also use mkfs.ext2 or other.

After completing all the above steps the configuration of the RAID array is complete and the RAID can be accessed through the /raid directory.

File systems for RAID

Next, format the RAID with a file system of your choice, e.g. with ext2 using mkfs.ext2 /dev/sda1. Good file system choices are ext2, xfs and jfs - the latter are best when working with the large files common in VSIB use. xfs and jfs are fast in formatting the filesystem and when deleting files, whereas ext2 is really slow in these task. For writing and reading all three are fast enough. Recent post-2005 versions of reiserfs may work acceptably fast. too.

After setting up the RAID you could tune the disk settings using hdparm as described in [4]. If you want the best performance out of the RAID, you should try tuning the RAID chunk size parameter - see the comment in the above script, and Guifres test results in [12].

Notes For Compiling A New Kernel

To work, the VSIB driver module needs the "big physical memory area" (bigphysarea) patch present and enabled in your kernel sources and the running kernel.

On the preinstalled system the above has already been taken care of, and there generally shouldn't be any need to recompile the kernel, unless you want to upgrade to a newer kernel version due to fixed security issues etc. On other systems it is very likely that you must patch and compile a kernel for VSIB use, since the usual "stock" kernels in most common linux distributions never come with the bigphysarea patch alread included and enabled.

Currently, a precompiled 2.6.17.4mro patched kernel and its source are available as Debian .deb packages at http://www.metsahovi.fi/vlbi/instr/mro-vsib-pc/packages/. You can find a precompiled 'vsib.ko' VSIB kernel module for this kernel version there, too.

The kernel specifics required for a proper VSIB kernel can be found on the preinstalled system under /usr/src/1-MRO-KERNEL-INFO.txt. The same text file is also shown below:

 MRO Kernel Specifics
 --------------------

 When you install new kernel sources and you still want to be
 able to use the VSIB board you will have to:

   a) apply the bigphysarea patch to the new kernel 
      sources by using

       cd /usr/src/linux-yourversion
       patch -p1 < /usr/src/bigphysarea/bigphysarea-2.6.16.diff
   
     (you may also google for a newer bigphysarea .diff patch
      specifically for your kernel, since with the above it 
      is likely that you will have to manually edit some of the
      files that 'patch' is not capable of patching, e.g. mm/Makefile)

  b) after compiling, installing, and booting into the new kernel, 
     run as root:

       cd /usr/src/vsib/
       ./yank26 

     to recompile and install the vsib kernel module for your 
     new kernel

 That's it.
    
 Btw when compiling a new kernel, it is advisable to use

  cd linux-yourversion
  cp /boot/config-`uname -r` .config

  make oldconfig
  make menuconfig

  make-kpkg clean
  fakeroot make-kpkg kernel-image --initrd --append-to-version=own1
  
 And be sure that in the menuconfig you do not specify any 
 string to append to the version, nor select "automatically
 append to version string", since these options seem to generate
 a broken kernel install (the kernel then looks for modules 
 in /lib/modules/ under the completely wrong subdirectory...)

After a successful 'make-kpkg kernel-image ...', you should find a new kernel-image-....deb under /usr/src. Install it with dpkg -i kernel-image-....deb.

Note: for own installs, check that your /boot/grub/menu.lst file contains a commented 'kopt' line similar to # kopt=root=/dev/hda1 ro bigphysarea=36000. 36000 with the normal 4kB page size gives a total bigphysarea size of 144MB. Note that areas larger than 256MB are not properly supported by bigphysarea, kernel or vsib. 144MB is fully sufficient for >512 Mbit/s recording or e-VLBI. For reference, the grub menu configuration already found on the preinstalled system is menu.lst.

As the final step you update the GRUB menu entries by running update-grub.

If you are not using a preinstalled system then of course the bigphysarea patch will not be in /usr/src/bigphysarea/bigphysarea-2.6.16.diff, and you should use for example Google to search for "bigphysarea 2.6.17" (without quotes, and with your real kernel version) to locate the correct patch. Some patches are currently (06/2006) available at bigphysarea patches [8].

If you have your own linux system and problems running the 'make menuconfig' part of the kernel build process, then check that you have ncurses5 and ncurses5 development installed (e.g. the packages ncurses5, libncurses5, ncurses5-dev, libncurses5-dev).

Installing The VSIB Driver

On the preinstalled system disk, the VSIB driver has already been installed. It is automatically loaded when the system boots, so you don't need to follow these instructions.

However, for your own linux installs, or if you upgrade or recompile the preinstalled kernel, you also need to compile and (re)install the VSIB driver for the (new) kernel. On completely new systems you will also have to install the fftw-dev, fftw and udev packages (using for example apt-get) before proceeding.

To begin with the install, boot into your self-compiled kernel first. Instructions for compiling and installing the actual VSIB kernel module are contained in the INSTALL.txt file that you find bundled with the VSIB source.

On the preinstalled system, the VSIB source code and text file are under /usr/src/vsib. Since the system has already been configured you only need to follow step 2 and run './yank26', that is, 

  cd /usr/src/vsib
  sudo ./yank26
On other systems you'll have to check that your linux setup meets the requirements in INSTALL.txt, and then you have to complete all the three steps in that same INSTALL.txt.

For convenience, the contents of INSTALL.txt is quoted below: 


Requirements:
----------------------------

 For kernel 2.4:
   - bigphysarea patch

 For kernel 2.6:
   - SYSFS built into kernel
   - udev package installed, and running
   - bigphysarea patch

 In addition, for all kernel versions:
   - kernel build tools (typically the "kbuild" package)
   - sources for your current kernel
   - bigphysarea patch already applied to the kernel and source,
     and the kernel boot parameters (see LILO or GRUB) already 
     contain "bigphysarea=8000" or similar
   - the .config file of your current kernel present
     in /usr/src/{output of uname -r}
   - gcc compiler and make tool

 The tools (wr, ft3, etc) require:
   - FFTW2 packages - under Debian fftw-dev and fftw2


Setting up and installing:
----------------------------

All commands as root or via sudo:

1) nano /etc/udev/permissions.rules   

    i.e. edit that file and add

    # vsib board
    KERNEL=="vsib",          MODE="0664", GROUP="-insertgroupnamehere-"

    Where group name is e.g. root ;-))

2) ./yank26  
   (run it in the VSIB source code directory)

    For kernel 2.6, rebuilds the vsib kernel module and 
    loads it, and also rebuilds tools (wr, rd, ft3, ...).

    The script assumes bigbufsize 144000000 (144MB). 
    Please edit the script if you want to use some other size.

    NB: compiling and running the 'vsib' needs the "bigphysarea"
    kernel patch applied. Google for it, download the .diff,
    and apply it to your kernel sources with 'patch'.

    NB: you can use ./yank24 for kernel 2.4

3)  For kernel 2.6:
    nano /etc/modules

    i.e. edit that file and add, at the end,
    
    # load vsib with 144MB buffer
    vsib bigbufsize=144000000
 
    With this setting the vsib kernel module 
    is loaded automatically on the next reboot.


Troubleshooting
----------------------------
  
1 - If during compiling you receive a very large number of
warnings like 'xx' undeclared, 'implicit declaration' etc
then it is likely your kernel config file e.g.
 /usr/src/kernel-source-.../.config 
is missing and should be copied from the /boot/ directory.

2 - Check that in
  ls -al /lib/modules/`uname -r`/
the directories "build" and "source" exist and link to
the correct /usr/src/kernel-source... or /usr/src/linux-...
directory. For example:

  # cd /lib/modules/`uname -r`/
  # pwd
  /lib/modules/2.6.17.3gofrito2
  # ls -al
  total 272
  drwxr-xr-x   3 root root  4096 Jul 14 07:34 .
  drwxr-xr-x  10 root root  4096 Jul  6 07:22 ..
  lrwxrwxrwx   1 root root    40 Jul  7 12:54 build -> /usr/src/kernel-source-2.6. 17.3gofrito2/
  drwxr-xr-x   9 root root  4096 Jul  6 07:08 kernel
  ...
  -rw-r--r--   1 root root 38561 Jul 14 07:34 modules.usbmap
  lrwxrwxrwx   1 root root    39 Jul  7 12:49 source -> /usr/src/kernel-source-2.6 .17.3gofrito2

3 - If vsib still does not compile correctly, go to
  cd  /lib/modules/`uname -r`/build
and rebuild the kernel using
  make-kpkg clean
  fakeroot make-kpkg kernel_image --initrd --append-to-version=mro
(where 'mro' you replace with the string behind the
output of 'uname -r', or entirely leave out the --append-to-version)

4 - If you have a kernel older than 2.4, it is not supported.

5 - If you have a kernel newer than 2.6.17 and get compile errors,
congratulations, it means the core kernel developers once 
again could not care less about backwards compatibility for
existing code. Either install an older kernel or try to
decipher http://lwn.net/ posts about what has changed this time.

6 - If you have problems with the big physical area patch and that
the system completely freezes during booting, try changing
the value of the "bigphysarea" kernel parameter to something 
smaller, for example 80000 which means reserve 80000 memory pages
for the big physical area (with 4kB pagesize this means 80000*4kiB~=14.4MiB). 
If the value is too high with respect to the installed RAM, the bigphysarea 
patch can not allocate enough memory and freezes the kernel (nasty but at 
least that gets the users attention...)
Regarding troubleshooting point 5, you could also contact Metsähovi VLBI staff and ask if there is a new VSIB driver version available that works with the given "too new" kernel.

VSIB Testing Tools And VLBI Observation Utilities

For testing the VSIB board and its setup in your PC, and for using tools like 'wr', please refer to the other documentsInstalling VSIB/VSIC Test Software, 2003 [4] and Using VSIB Test Software, 02-2006 [6].

Quick VSIB Test

You can download a small VSIB test script [10] vsib-test and follow the quick documentation for test preparations vsib-test-doc. The script tests recording of a VSI-H test pattern from VSIB to RAID disk. You can get the VSI-H test pattern either from a VSIC/MMM box switched into mode 7, or from the VSIB PC-internal VSI connector by connecting JP2 "TEST" pin 1 to ground JP3 GND. For more details, refer to the Using VSIB Test Software document, page 3.

The script assumes a 4 SATA disk RAID setup and a '/raid' RAID mountpoint with a '/t' test subdirectory i.e. that an empty directory '/raid/t/' exists and is on the RAID. You may have to edit two or three lines in the script to reflect your actual RAID setup.

The script should be run either via 'sudo' or as root, since it will unload and reload the vsib kernel module. If everything works correctly, the typical output of a vsib-test script run is like shown below:

$ cd /usr/src/vsib
$ sudo sh ./vsib-test
....
/usr/src/vsib/wr 16000 240000 2 0 1 0 1 /raid/t/t%06d 4000
at block = 0, opened file '/raid/t/t000000'
at block = 4000, opened file '/raid/t/t000001'
at block = 8000, opened file '/raid/t/t000002'
at block = 12000, opened file '/raid/t/t000003'
....
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/md0             922998396   3754104 872358624   1% /raid
631f3db28fa89dd1a3752837ac12491d  /raid/t/t000000
631f3db28fa89dd1a3752837ac12491d  /raid/t/t000001
631f3db28fa89dd1a3752837ac12491d  /raid/t/t000002
631f3db28fa89dd1a3752837ac12491d  /raid/t/t000003
631f3db28fa89dd1a3752837ac12491d  /raid/t/t000004
631f3db28fa89dd1a3752837ac12491d  /raid/t/t000005
...

Long VSIB Test

In addition to the above, under the VSIB stressing tests report [9] you can find a longtest VSIB PC stress test summary with the associated stress test script that you might find useful for reference as vsib-test presented above is basically a cut-down version of the longtest script.

Long VSIB test pretends to verify the correct process of our vsib board, cables and hard disks in a long term perspective. The procedure tries to fill the set of hard disks until 99,9 % of its capacity, then validate the data stored and finally start again by erasing the whole raid and acquiring data again. The aim of the test is to study the behaviour when data is stored close to the capacity limit of the disks and the possible data errors due to variable interferences and the ways to solve it.

You should check the output of dmesg | grep "ring buffer" after a run. Then compare the byte number in the last message of
vsib: big secondary ring buffer filled to 488832 bytes
to what dmesg | grep Allocated gives out, for example
bigphysarea: Allocated 36000 pages at 0xb1804000.
If the number of pages multiplied by 4096 bytes gets very close to the secondary ring buffer fill amount, this very likely indicates that your RAID disk stack (or your file systems performance on RAID at higher CPU load) is too slow. Before trying to improve RAID disks or motherboard, try if increasing the bigphysarea size in /boot/grub/menu.lst (run update-grub after editing) with corresponding increase in the /etc/modules setting, then rebooting and re-running the long test, helps to reduce the fill percentage of the secondary ring buffer.

Using real-time Tsunami

The improved normal and real-time version of tsunami is installed in /usr/src/tsunami. There's also a Tsunami-udp project page [11] on SourceForge with possibly newer versions of tsunami. If you want to get a new tsunami version, you can downloading it from CVS by following instructions at the SourceForge project page for downloading and compiling.

Using real-time Tsunami works in largely the same way as normal Tsunami. For a typical remote PC real-time VSIB capture and local PC storate to RAID disk, on the remote end use the "real-time" tsunami server application and locally run the normal non-realtime(!) tsunami client.

Known problems: the included Tsunami is already a bit out of date, and there are quite often several bugfixes to Tsunami. You generally should do a cvs update in /usr/src/tsunami once in a while, then recompile (see COMPILING.txt in the tsunami directory). Note that CVS may try to use the 'jwagnerhki' account instead of anonymous CVS access, in which case, sudo rm -rf /usr/src/tsunami/* and go to the Tsunami SourceForge project page [11] for instructions to check out a new CVS version.

For some instructions on how to use Tsunami, please read the USAGE.txt on the tsunami-udp project page.

Scheduled streaming or recording to disk

To start 'wr' recording to disk at times specified in a schedule, you can use the scripts recexpt and recpass available for download over here: http://www.metsahovi.fi/vlbi/instr/mro-vsib-pc/recexpt/ See the info.txt for short instructions. You need to edit the script files.

There are some utilities for transforming a FieldSystem schedule file into 'wr' or real-time Tsunami scripts. The utilities generate ready scripts that can be started and left running, and that will record all scans of an observation, per the schedule. The utilities are included in the Tsunami CVS repository under 'utilities', but can be found behind the above 'recexpt' link, too.


!----------------------------------------------------------------------->

References

[1] Linux Newbie Administration Guide
http://www.faqs.org/docs/lnag/lnag_basics.html

[2] retail SuSE linux with printed handbook
http://www.novell.com/products/suselinux/

[3] Debian Users Guide
http://www.debian.org/doc/manuals/users-guide/users-guide.en.html

[4] Installing VSIB/VSIC Test Software, 2003
http://www.metsahovi.fi/vlbi/instr/mro-vsib-pc/pre-sw-inst.pdf

[5] Metsähovi VLBI Data Acquisition page
http://www.metsahovi.fi/vlbi/instr/boards/

[6] Using VSIB Test Software, 02-2006
http://www.metsahovi.fi/vlbi/instr/mro-vsib-pc/pre-sw-use.pdf

[7] An introduction to Debian networking setup
http://www.debian-administration.org/articles/254

[8] Kernel bigphysarea patches for some new kernel versions
http://www.feise.com/~jfeise/Downloads/zr36120/

[9] Stressing tests over mro-vlbi-pc's
http://www.metsahovi.fi/~gofrito/vsib-tests/testsummary.html

[10] VSIB operational test script vsib-test with a short documentation
of test preparations vsib-test-doc, and a longer test script longtest
http://www.metsahovi.fi/vlbi/instr/mro-vsib-pc/vsib-test
http://www.metsahovi.fi/vlbi/instr/mro-vsib-pc/vsib-test-doc.pdf
http://www.metsahovi.fi/vlbi/instr/mro-vsib-pc/longtest

[11] Realtime Tsunami-UDP project page on SourceForge
http://tsunami-udp.sf.net/

[12] RAID chunk size tuning tests, example test results
http://www.metsahovi.fi/~gofrito/vsib-tests/Hard_disks_tests.html


Written 06/2006 by Jan Wagner, jwagner àt kurp hut fi, last updated 10/2006
http://www.metsahovi.fi/vlbi/instr/mro-vsib-pc/