CERN Accelerating science

Previous:		Computer Networking is Getting Faster and Better Organised	(See printing version)
Next:		CERN's Connections to European and Global Internet Improved

The accompanying article on the improvements in computer networking in CERN has indicated the considerable effort which is going into restructuring, creating a high performance backbone and offering the possibility of central data recording at very high rates of transfer. However, limitations of money and manpower have led to decisions on priorities such that most desktop equipment (PC, Macintosh, X-terminal or Unix workstation) is still sharing a 10 Megabit/second Ethernet segment with around 40 other systems. Given the power of modern processors, almost any desktop system can effectively monopolise such a segment for long periods. When we discover such cases, normally as a result of other users complaining, we often have no option but to block the offending system in order to protect the majority of users. However, we would much rather that users try to avoid any activity which could cause such situations.

Sometimes the problem is caused by a workstation trying to process large amounts of data which are actually held elsewhere: often an AFS or NFS mounted file held centrally somewhere. Since the workstation may have powerful CPU capacity the processing may be rapid, thus causing high data transfer. Our objective is rather to move this processing capacity to the data, hence the increasing number of PC processing farms in the Computer Centre.

The most frequent problem, however, is where an executing program is not running in the local workstation, but is exporting information to go onto the screen (and loudspeakers, perhaps) of the workstation. One example of this (which we now try to ban) is the use of a screen locking program (xlock) used to lock an X-terminal when a user is absent, and which sends constantly changing patterns to the locked screen. The answer is: use a simple screen lock which uses a blank screen!

More difficult (even impossible) to avoid is the use of the Netscape Web browser to view a dynamic page (perhaps displaying dynamic graphics files, perhaps running a Java applet). If the browser is executing remotely from the X-terminal (or a workstation running as an X-station, such as a PC running Exceed), then even a harmless-looking object (such as a rotating globe in a corner) can take a large fraction of the available network bandwith. And that remains true even if the rotating globe is not visible on the screen, or even if the whole Netscape window is reduced to an icon: it can, however, be stopped by turning off animation (in the Netscape "View" Menu). Therefore, for those people who can only run Netscape remotely, we ask that they be aware of these possible network monopoly situations and avoid them.

A number of persons who have personal workstations capable of running Netscape locally are nonetheless choosing to run it remotely, often on the central PLUS servers. Arguments for doing this can be found (central bookmarks, modern version of Netscape, lack of performance of local workstation). However, there are obvious counter arguments (put bookmarks onto a central AFS, NFS or Novell server!). The plain truth is that from a networking point of view it is almost always more efficient for our networking if Netscape is run from the local Operating System (i.e. your personal desktop machine).

Netscape can also be used together with various plug-in programs for receiving on-line audio/video. As long as this is in some way work-oriented there is normally no problem. However, if (as is technically possible) a user retains a connection to an external audio/video source for a long time then the data transfer becomes significant. Clearly, although the objective of CERN providing computing and networking facilities is to enable people to do CERN work, no-one is going to object to occasional casual surfing (e.g. of news headlines on www.cnn.com or similar sites). However, staying for significant periods of time on sites offering audio/video feeds unrelated to CERN can have an adverse effect on other users.

The bottom line is that for many people at CERN the potential for overloading the local network segment is a real one. Therefore, please try to recognise and avoid such situations before we are obliged, as a result of complaints from other users, to "pull out the communications plug" on your desktop system.

For matters related to this article please contact the author.