NETWORK BEHAVIOUR What your Netrek habit REALLY does to the network... ---------------------------------------------------------------------- Date: Fri, 16 Nov 90 13:31:49 -0500 (EST) From: "Terence M. Chang" To: Bulletin Board Administration Subject: Re: New Server A few comments on the issue of net delay: Disclaimer: I am ignorant about networks, TCP/IP sockets, etc., this is just Berkeley Xtrek jargon. When the performance of your client degrades, it exhibits one of two symptons, called "freeze" and "blink". Freeze is when server packets (information from the server -- what the rest of the universe is doing) or client packets (information from the client -- what your ship is doing) get delayed by the network and/or server and are queued up. Whenever the server machine is trying to something else, like compile or do sups, you will see mondo freeze. The end result is usually that either the screen freezes briefly, or your ship seems to ignore your mousing briefly. To improve performance, you have to reduce packet traffic, meaning less updates per second (settable in the shift-O menu). I normally use 4. The default is 5. Now, with everybody running PMAXen, blink is going to be rare. This happens when the client's X server cannot keep up with what it has to draw, and the display will flicker badly. Subjective ways to measure freeze and blink: Freeze: Do an /etc/ping -l bronco.ece Take the average of 20 packets. Any packet loss is bad. Roundtrip times above 100ms are bad. Blink: Check the load average of your machine. For PMAXen, I have yet to see any blink at 5 updates/sec. Okay, now, somebody describe to me in terms of ping times, packet lossage, and load averages how bad the net delay is. Thanks, Terence ------------------------------ Date: Fri, 2 Nov 90 10:25:28 -0500 (EST) From: "Terence M. Chang" To: Bulletin Board Administration Subject: Re: monster I'd like to address the issue of noise and ettiquette with respect to Xtrek II, based on what I had seen at Berkeley. First, the Pmaxen in 5200 WeH are ideal for Xtrekking -- virtually silent mice. My pmax mouse is loud enough to bother my officemates, and my God a Sun 3 mouse raises hell when you beat on it. Second, I know that just about everybody is not accustomed to using the message facility, but this can eliminate a lot of noise. It will take some work, but everybody should get to the point where they notice messages as soon as they get printed on the window. There are two window configurations available (1 and 4 message window formats) plus other "filtering" options available via the shift-O menu. Experiment, find something that works for you. When it comes to sending, well, you have to be a fast typist. Somehow I've learned to send messages even while dogfighting. For the Xtrek community's sake, try to use messages -- they're not perfect (the code is rather crude). If someone has ideas on improving the message interface, let me know about them. Third, the server uptime hours are relatively generous compared to Berkeley [damn CUI...haven't tried batmail yet]. The analog of 5200 WeH at Berkeley, known as the WEB/e260 cluster, has hours limited to 11pm-8am during the week. Non-WEB machine machines are limited to 8pm-8am. I don't understand the bureaucratic authority structure here, but if a staff member contacts me, I will comply with any requests he makes. I can reduce the evening hours now if most of the noise problems happen in the early evening (5pm-8pm). I understand that pmaxen are better than anything else available, but really, it doesn't take *that* much computing power to run a netrek client. Is there a dusty Sun 3 cluster or something that doesn't get used during the night? (Nobody uses NFS any more anyway, right? "The network IS the load average." or whatever) Xtrek has never been popular with the UCB sysadmins -- the game itself loads up the campus network somewhat because of various bottlenecks at important locations. The best way to play is to get access to a non-public machine or a non-desirable machine, because then you aren't displacing a real user capable of lodging real complaints. [This is just a first draft, wish I could edit it. No flames please.] Terence ------------------------------ Date: Fri, 25 Jan 91 16:31:23 -0500 (EST) From: "Terence M. Chang" To: Bulletin Board Administration Subject: Me and my copilot A quick fix was patched in today to try to eliminate copilots. We'll see if it makes things better or worse. Another note: the latency involved in closing a connection may actually be 120 seconds, not 15 as I said earlier. If you try the shell command "netstat -f inet" you can see whether or not you have active/closing connections to bronco. If you try to join the game and you see the words "Bye." come back, then the queue is full (my server pretends that you clicked on "Quit" in the queue window ... before it popped up, even! :) If you see "Try again later" and it is not M-F 9am-5pm, then you have too many connections. Make sure you have killed off all client processes and check the netstat output. For your Xtrekking convenience, Terence ------------------------------ Date: Fri, 5 Apr 91 03:41:46 -0500 (EST) From: "Terence M. Chang" To: Bulletin Board Administration Subject: "My client's fallen, and it can't get up!" This is a review of unusual client behavior and what it means. SYMPTOM: Client accepts login name, but returns "Bad Password!" constantly, or, in the case of "guest", client quits, saying "SOB server won't let me log in as guest!" DIAGNOSIS: Your account has been locked out. Remember asking me to lock you out? SYMPTOM: That infuriating "Sorry, ... try again later." message. DIAGNOSIS 1: It's M-F 9am-5pm. Server is down. DIAGNOSIS 2: It's some weekend night. The queue fills at 18, and others who try to get on the queue receive the "Sorry" message. Wander about the cluster, trying to gauge the size of the queue by checking other screens. DIAGNOSIS 3: You already have a network connection to the server. Try the Unix command "netstat -f inet" and make sure you don't see any 2592s in the output. Kill off any other clients lurking around, wait 120 seconds, and try again. SYMPTOM: Everybody explodes and disappears. Client freezes. DIAGNOSIS: The server has crashed or gone down. Use Unix job control features (^Z to suspend, 'kill %1' to kill background job #1, etc.) to get rid of the client process. You may have to wait 120 seconds for your connection to die completely (check with netstat) before you can reconnect. SYMPTOM: Client doesn't give "Got connection." message. DIAGNOSIS: Some sort of local network failure, due to lightning strike, Andrew/ECE maintenance, or ECE bungling. SYMPTOM: Client gives "Got connection." but doesn't do anything for several minutes. DIAGNOSIS: Server is having trouble accessing its nameserver, or AFS is blocking the server. Try to be patient. SYMPTOM: Client doesn't even create window. Immediately says "Server not listening!". DIAGNOSIS: Server is still down. Maybe the server is rebooting itself, meaning that I have to manually restart the server next time I login. Or I could be patching something before restarting. SYMPTOM: Game animation is jerky. Screen freezes and then rushes to catch up with real-time. DIAGNOSIS: Net freeze. Try using the shift-O menu to reduce the number of updates per second. The startup default is always 5. This is a lot. Try 4 or 3. SYMPTOM: Game animation is jerky. Screen flickers but doesn't freeze. DIAGNOSIS: You're using a cheap workstation or doing compiles in the background. Reducing the updates helps, but if CPU is gasping for breath.... SYMPTOM: Your screen freezes. For a long time. DIAGNOSIS: This is a severe version of net freeze. Your connection may be permanently severed, and the client will quit with 'Augh! We've been ghostbusted!'. Sometimes the connection is reestablished, leading to the wonderful 2 ships/1 slot bug. If this happens, quit immediately to prevent corruption of player stats (Chanting the mantra "mutual exclusion, mutual exclusion" may improve your luck). SYMPTOM: You see "GOD->ALL Foo (F0) was kill n.xx for the GhostBusters". This happens mostly to non-local players whenever a 747 at LaGuardia ingests a bird. The frantic pilot/tower/Audubon Society radio traffic creates power spikes that disrupt a PDP-11 gateway located in the Bronx. DIAGNOSIS: none Terence ------------------------------ Date: Sun, 21 Apr 91 02:44:49 -0400 (EDT) From: "Terence M. Chang" To: Bulletin Board Administration Subject: Re: wait Q If the number you see in the wait queue window is 0, 1, or 2, then it is correct. The number you see when you first get on the queue is correct. Due to technical details I don't want to get into (basically a flawed multiprocess synchronization scheme), when people get off the queue not all other queued processes find out about it, resulting in incorrect wait numbers. The code for the wait queue is generally pretty flimsy -- at least it's better than "Game is full -- bye!". There are many niceties I would have liked to seen done with the queue code, such as showing queued players who's presently on, or showing queued players messages sent to the ALL board. None of this will happen without some serious overhauling, unfortunately. Terence ------------------------------ Newsgroups: alt.games.xtrek From: terence@bronco.ece.cmu.edu (Terence Chang) Subject: Banning Netrek (excessive network usage?) Date: Fri, 4 Oct 1991 21:12:30 GMT Quoted below with permission is an excerpt from an e-mail message I received: > My name is Calvin Tarlton, and I am a student down here at NCSU. I was > told you might be able to help me out. The game Xtrek was recently outlawed > here because it "uses too much network bandwidth" I was wondering if you > have any statistics on exactly how much of a strain it puts on the net. > Calvin > cctarlto@eos.ncsu.edu This is the second query about Netrek's network usage that I have received. Right now, I only have the following numbers available: ======================================================================= Protocol: TCP/IP, Internet connection From the client machine's point of view: 650 bytes (5200 bits) raw data/sec inbound 27 packets/sec inbound 37 bytes (296 bits) raw data/sec outbound 4.8 packets/sec outbound ======================================================================= I would like to know if anybody can convert my numbers into useful information -- that is, the actual amount of bandwidth used including TCP/IP overhead, and how much this usage compares to other activities (such as sending a 1024x800 X window to a remote host that updates 5 times/sec, reading netnews, or telnetting). Also I'd like some measure of the "capacity" of various kinds of networks. Does the game use too much network bandwidth? Thanks, Terence Chang ------------------------------ From: tom@lightning.Berkeley.EDU (Tom Holub) Newsgroups: alt.games.xtrek Subject: Re: xrek on shared machines Date: 22 Oct 91 04:49:50 GMT In article <1991Oct21.015712.24128@watdragon.waterloo.edu> wganderson@violet.uwaterloo.ca (Warren G. Anderson) writes: >Well, I must say, you folks have certainly got my interest. I was wondering, >what does xtrek do to your load average. Would it be a serious no-no to >run it on shared machines? The reason I ask is that all the client binaries >seem to be for work stations. Is there some reason there are no binaries >for other platforms? Specifically, I'd like to run it on a DEC 5500 with >ultrix 4.1 which serves a bunch (around 20) HP x-terminals. But this >machine is fairly heavily used (ie 10 people on right now, at 10:00 pm >on a Sunday), so I wouldn't want to load it unnecessarily. Xtrek isn't terribly CPU-intensive (except in last-planet defenses and starbase attacks), but it's very net-intensive (especially in last- planet defenses and starbase attacks). One Xtrek process shouldn't kill your cluster, certainly. If there's just one net node for 20 terminals, 3 or 4 could kill your net, though. -Tom ------------------------------ From: bav@hobbes.ksu.ksu.edu (Brick Verser) Newsgroups: alt.games.xtrek Subject: Netrek's network resource usage Date: 18 Nov 91 11:17:51 GMT I had nnstat running tonight when about 6 folks were playing netrek from here to foghorn. During the peak 30 minute interval we sent or received on port 4091 (200699 mod 65536) 105K packets and 12M bytes. Works out to 58 packets/sec and 6610 bytes/sec. If you assume most of the packets going out from here were 40 byte acks then the average incoming packet is 184 bytes. At 5 updates/sec, each netrek client will use about 7000 bps of bandwidth. So a 56KB line (if you are so unfortunate) will be completely saturated with 8 netrek players. Additional trivia. 3% of our external TCP traffic the last 4 days was to port 4091. That's 995897 packets and 104595067 bytes in 342789 seconds. Port 2592 (other "normal" netrek) got .7% of the total. And port 5854 on our own Matt got .8% of the total. The clear winner here is "chaos" mode netrek (bogging down foghorn instead of Matt, thank you very much-- Matt's load was up around 10 most of the evening tonight without netrek running, paging 600-800KB/sec in 32M; an upgrade is coming). --Brick ------------------------------ From: jmn@crown.Berkeley.EDU (J. Mark Noworolski) Newsgroups: rec.games.netrek Subject: Re: Network and CPU load due to Netrek. Date: 10 Nov 1993 21:40:55 GMT edgarm@cii3112-14.its.rpi.edu (Marc Edgar) writes: >Greetings, >I am curious to know how much load netrek places on a network, that is, >how many kbytes/sec are transmitted to each client? This one I can probably answer. Some time ago I hacked a client to collect some of these stats... Here's a summary: Server -> Client network usage: (actually now with shortpackets this is probably slightly lower) Maximum CPS during normal play: 3588 bytes per sec Standard deviation: 918 Total bytes received 1795888, average CPS: 803.0 Client -> Server network usage: Maximum CPS out during normal play: 168 bytes per sec <------------ !!!!!! Standard deviation out: 21 Total bytes sent 20580, average CPS: 18.0 <----------- !!!!!!! >I'd also be interested in how much cpu does netrek take? That is, >how many games could I be running on a single machine before >the lag was noticable assuming a good network connection. (Choose >your favorite machine.) I dont know about this one but I can say that a dec3100 seems capable of handling one full INL game as long as people are not logging in and out while it is going on (and as long as it doesn't need to swap). Figure on about 300kbytes for each player playing in the game (usually you have 16 players). If anything swaps then server lag will probably get hosed in a big way. Maybe somebody else can answer these questions for you better. Passing Wind ------------------------------ End of NET BEHAVIOUR ********************