The purpose of this note is to answer the questions asked by several people about the present delays in getting files DISTRIBUTEd from the US to Europe, and vice-versa. There are two causes to this problem. The first one is that the BITNIC CPU is too small for the load it is getting, and that its link to CUNY is also too slow. But today the major delays are in Europe, where the "hub" LISTSERV backbone node is FRULM11. Although the node is quite stable and their staff has never failed to take action whenever they were notified of a problem, the CPU is simply too slow for the amount of jobs it is getting (we are talking about over 5000 a day), and its connection to the rest of the network is via a 9.6k line. LISTSERV@FRULM11 is still processing the backlog caused by an interruption of service at FRORS12 last weekend, and is probably flirting with the 9900 spoolids limit as I type these lines. I have analyzed the situation and there is unfortunately no satisfactory solution. Temporarily changing FRULM11 to DISTRIBUTE(NO), or changing the link weights, would only move the totality of the load to another EARN server: TREARN, HEARN, DEARN, depending on the new set of weights. There is only one solution that would spread the load across several servers: nullifying the weight of the CUNY-MOP link (now 75) and setting all the other weights so that all the hub European servers lay at the same distance from CUNY. There would then be 'N' files sent from BITNET to EARN rather than 1, but the CPU and outbound files load would not hit a single machine. But this change would have other implications, like causing European subscribers to be assigned to a BITNET peer or vice-versa. You can imagine the political consequences that this might have, and I want to stay clear of that. It could be argued that there may be better machines than FRULM11 to take that load, but unfortunately there is none that is clearly better. The requirements are a fast (or at least lightly-loaded), non volume-charged connection to the EARN backbone, a fast CPU and the willingness to burn a large amount of CPU cycles for the network, a large spool with no more than 1000-2000 local files at any time or a version of VM that can handle more than 9900, excellent availability and, above all, responsible staff willing to take immediate action if there is an urgent problem. I know of no node meeting all these requirements, especially as this would mean dramatically increasing the traffic on a given international line in order to provide service to other countries, thereby greatly reducing the bandwidth available to users of the local country - more political problems, which lead me to think that the wisest thing to do is to leave things as they are. Finally, I would like to remind you that FRULM11 is a "private" computing centre having no obligation to take that load (unlike DEARN, CEARN, BITNIC, etc, whose only purpose is to do this kind of things). They have kindly accepted to do so, because of their advantageous topological location, in order to help the network to solve its chronic line saturation problems. We should all remember this when we complain about their CPU being slower than we would like it to be. Cheers, Eric