---------------------------------------------------------------------- On tweaking dynAMIte, it's servers and clients, and Amigas in general. Includes hints for AGA users. ---------------------------------------------------------------------- 1.Intro: You all know, lags spoil the game, especially in dynAMIte. Q.: "Who is responsible?" ------------------------- Well, many things. For example: The net, the number of hops (doing a "traceroute" from your client to the server reveals it), the way dynAMIte works, the server's cpu, the server machine being used for other things simultaneously, the performance and performance stability of the client. And so on. With dynAMIte 1.7, as it seems ATM, a new feature, called "pingwatch" will be introduced to the server side. Depending on the heart of the sysop, and his courage to set pingwatch to a working value, "1", for example, this will kick out players that lag too much. Yeah, finally it is possible, and hopefully it will prevent some games from being quit-killed, and make games a bit more enjoyable. 2.Q.: "So I better take care, what can I do about lag?" ----------------------------------------------------- Well, unfortunately that's complicated, and largely depends on you. Settings and performance of your system can still be improved sometimes, the net can't. Although one may change to a faster ISP. So these are my suggestions: Servers: ======== Short correspondence yesterday, with the sysop of "Humppa", revealed that his 040-25-server overloads CPU at 7 players, maybe already with 6. So as a sysop take care your server can handle the maximum allowed player count, not just by upstream, but also by CPU power. Use a CPUload display tool. 100% peaks will cause lag. Also pingwatch can indicate overload. I.e., if people get thrown out by pingwatch with many players, it may be your server is overloaded. In such a case better -do not- alter the pingwatch value, but the maximum allowed player and observer cunt -first-. Of course, if you have to use your server for other things, while games are served, it would be kind to set the servers priority to "1" or "2". Also one can install "Executive", and set the server to "static prio 1". Above suggestions won't prevent all lag, but better than nothing. A short note on server hardware: A "real" server needs more than 64kbit upstream. I.e. ISDNx2, DSL, Cable or a university network. A good network access behind your personal access. And a CPU of 40-33 or 040-40, as it seems to have turned out. Clients & general: ================== If all other players lag for you, you lag for them. And you are quite likely the one spoiling a game. Such happens mostly with poor or too long distance lines in the net. It's unpleasant, but often it's better to leave a server/game instead of spoiling it. Organize someone to set up a server in your own country, if the lines to other countries are always too long/bad. For people not caring about that, or being unaware, pingwatch is meant to be the tool of choice (Payback ;/). There are many players with 040-25/PPC. Those -have- to take care of reducing lag, the CPU is too weak. "PPC version?" Not possible. Some possible measures for all users and sysops, if not applied already: o Moving exec base to Fastmem ("Fastexec", "Blizkick", etc.) (rating: quite important) o Moving SSP to fastmem (rating: most important) o Using a good CopyMemQuick() patch. Copymemquicker 2.8 from Aminet for 020/030, and NewCopymemquicker060 by Sintonen for 040-60. !Some 040 users have to read the manual for NewCMQ060 carefully, since there may be an obstacle.! MCP CMQ is a tad slower imho, so ditch it. (rating: important) o Moving the vector base register "vbr" to fastmem (easily done, slight gain=important) o Moving the ROM to fastmem (what, you haven't yet?, important) o Priorities with Executive: Miami* static/nonschedule, Amarquee* static/nonschedule, dynamite* static/nonschedule o AHI/Sound in dynamite: ------------------------ - Choosing the right AHI mode is up to you. - Channel tooltype (channels=n): Despite of Gelb's assumption, it seems reducing the channel count from the default twelve channels is quite ok, rather a gain in volume and dynamics. Try eight channels. I did not notice any sample loss with that. - Mixing rates above 27kHz seem to be of no use. - Disabling sound, if you dare, gives a significant relief/boost. - Removing the explosion sample seems to relieve the CPU as well. Networking: =========== o The MTU size: --------------- Setting the MTU size to 576 bytes instead of 1500 or 1492(PPoE), either permanently or just for your dynamite session, will have some effects, as there are: - Faster transfer of the packets by each hop. But also more packets to be sent. - Avoidance of split packets, in case the route contains one or more routers that work with 576 bytes MTU size - Maybe less packet loss with error-prone modem connections. That's why default settings for modems always use "cowardly" 576 bytes - reduced transfer speed of large files, due to the increased packet count Well, with minor data rates, as in dynamite, and maybe strange routes, responsiveness may improve. It's up to you if you try this, the outcome depends on the type of application. o VJC (van Jacobsen "compression"): ------------------------------------ Should be switched on usually. It's not a compression, but a "storing and then stripping" of unnecessary header data. T1 (and maybe DSL/Cable, too): I saw recommendations to switch it off. o Data compression via TCP/IP-stack: ------------------------------------ Switch it off. It's just another strain on the old 68k CPU, therefore useless on a loaded CPU ["loaded CPU"=040-25], and useless with V.42bis modem connections. o Strange connections: ---------------------- Usually, in each pair of players, they lag to each other rather equally ("laaag" screamers: read that twice). But, some dynamite players (especially someone nicked "L...") seem to see all that the opponents do in time, while they themselves lag considerably. Whatever is the reason, in case of this phenomenon the lagger should consider fixing this. o Serial interfaces: -------------------- - Built in hardware: Use either Miami's built-in device. Or New8n1.dcevice, with EOF mode turned -off-. Make sure the bitrate works flawless, i.e. is not set too high. Btw., the possible bitrate does -not- depend on the CPU's speed with 020+&fastmem. That's a misinterpretation. Many A1200s are flawed (all AT ones?), and will work with 57.600 only, higher settings will slow down everything due to transfer errors. - Custom hardware (Hypercom etc.): Good. Less interrupts. AGA Users: ========== Well, AGA is slow. But extensive system patching can help -a lot-, without noticable additional instabilty. o AGA screens: -------------- - All should know, high scan rates and "high" depths slow down. So be fair, if it's slow, and it usually is, don't use 7bit depths, but 6bit. - Also avoid 30khz screens, and unnecessary high resolutions, if available at all. Btw., dynAMIte can be set to run on an own screen instead of WB via Mui settings, "inspector". Have a look at "pathetic drivers" on aminet. If you manage to get Fblit & Fscreen running good, you may "upgrade" your dynAMIte screen to 512x384, 7bit and 91Hz by using a mode of that package. o AGA & pure 68k: ----------------- - "Fblit" is a tool of choice. - Additional install "Ftext", - and!! "BlazeWCP", a must! - Finally, "Fscreen" 0.21+ quite likely will increase performance. Though it's beta, it already works and seemingly gives quite a boost with 30khz scan rates and higher screen depths here (maybe MMU required). If you don't know a source for Fscreen, go to #AmigaZeux. o AGA with PPC (what??): ------------------------ It may be that the abandoned outdated CyberGraphics with AGA support will run faster than Fblit on the 68k side. You will have to test it. Ok, this may cover it. Finally, my startup-sequence. You may use it as an example for patch order and patch choice. Arguments may vary. sys:c/blizkick122 c:kick4068exec44.rom noclick extresbuf=55000 module console.device FileSystem.resource FastFileSystem ram-handler romupdate.idtag quiet sys:system/mutools/MuMove4k prepareemul ignoreverify sys:c/Setpatch quiet noromupdate sys:c/Saferpatches install remember >nil: sys:c/segtracker sys:c/loadide reset quiet sys:system/mutools/MuFastzero on movessp ; NOTE: I removed "fastexec" argument, after updating MMUstuff, due to mufastzero complaining "already moved" after warm-reboots. Dunno whats up now with exec place. sys:c/Poolmempatchram >nil: sys:c/poolmem install >nil: sys:c/mathffp-Patch >NIL: ; Hsmathlibs patch sys:c/cmq060 >NIL: sys:c/patchcontrol >NIL: sys:c/setpatchmrgcop Resident C:Assign PURE MakeDir RAM:T RAM:Clipboards RAM:Temp RAM:Temp1 RAM:Temp2 sys:l/env-handler sys:c/BlazeWCP sys:c/fblit >NIL: run >nil: sys:c/Fscreen lace delay=1 prond sys:c/ftext >NIL: sys:c/MCP >NIL: Assign hd: sys: Assign T: RAM:T Assign CLIPS: RAM:Clipboards Assign REXX: sys:rexx defer Assign PRINTERS: DEVS:Printers defer Assign KEYMAPS: DEVS:Keymaps defer Assign LOCALE: SYS:Locale defer Assign LIBS: SYS:Classes ADD Assign HELP: LOCALE:Help defer BindDrivers >nil: Mount DEVS:DOSDrivers/~(#?.info) LoadMonDrvs >nil: SetEnv Language "english" SetEnv Workbench $Workbench SetEnv Kickstart $Kickstart UnSet Workbench UnSet Kickstart AddDataTypes REFRESH QUIET IPrefs sys:c/wbctrl imt=iconfast ConClip Path RAM: C: SYS:Utilities SYS:Rexxc SYS:System S: SYS:Prefs SYS:WBStartup SYS:Tools SYS:Tools/Commodities sys:System/REXXMast/Rexxmast >NIL: Execute S:User-Startup LoadWB simplegels ; (wbprefs=images chip, fblit takes care of that) endcli EOT