visceralsyn

In this thread, Dwarden says to use BAF/PMC Lite, he does not explain why or why not use the full. Thread ...Syn...

Some other thread mentions, do not install BAF and PMC for dedicated server. BAF-LITE, and PMC-LITE will both work with clients with the fulls, but the full expansions cause problems for the dedicated server. ...Syn...

From the looks of your commandline, you've installed ArmA2 after you installed OA. Not sure if he has to use absolute path in his commandline because OA should be in ArmA2's Expansion folder. Since you state you've already re-installed, then one more should not hurt. Remove both ArmA2, then OA, then install ArmA2 first, do not patch, then install OA, then patch them both. You will then have 'Combined Operations', and would not need to add anything to commandline, except bonified mods. Not sure of the installation process for those with Steam. ...Syn...

Execellent question, I wish I had the answer for. Commenting it out, produced the least amount of AI running stutter, 2nd best was 24~32. @djczing, MTU is ISP limited, ethernet is 1500. I tested mine with a windows machine: ping xxx.xxx.xxx.xxx -f -l 1472 Produced 0 fragmented packets, with a ping to my ISP's homepage, Comcast.com. Sadly, Gigabit-Ethernet's jumbo-frames, cannot be used over the internet. Still not sure of, on the whole smaller vs larger packets deal, if ethernet's fragmenting packets larger than the MTU, or padding packets smaller than the MTU is actually happening, with UDP. ...Syn... ...Syn...

Ping is how long it takes your computer to send and receive a message. High and low pings are highly objective. 300ms or more, might be considered High, while anything under 100ms, may be considered low. Note, Ping is location based. If you are in the midwest United States, and send a ping to a server on either the east or west coast. The response time will be lower ( also read faster ) than if you ping a server in europe, or Asia. Or a simple google search for ping nets this wikipedia article I gots nothing on the police pulling over cars, which sounds like you were multiplaying, some other game and not ArmA². ...Syn...

Commenting out MaxSizeNonguaranteed provides the best solution to AI Stutter. It is positively less. ...Syn...

Whats an 'idear' ? Since math is elusive, let me put something down on: 204800 * 64Byte (MaxSizeGuaranteed) = 100Mbps When the packet's size is adjustable, you have complete control of how much bandwidth you can use. Sounds like a great idea to me! If some people are smart enough to use math. Thats nice, thats your choice If during research you discover that the server can and will use more bandwidth during, if configured to do so. Obviously, you did no such research. I'm at least trying other things, and not guessing what it should do. If I knew 32 people who has this game, I'm pretty sure we would put money together to rent a dedicated server on a 100Mbps internet connection, and not my piddly 2.2Mbps-UP Cable connection. I will add, the testing done yesterday with the MaxSizeGuaranteed set to 32, I ended up restarting, at 64, and MaxMsgSend to 104200, which again, equals 100Mbps, for the math-challenged peoples. Removed bandwidth in general as part of the serving problem. 2 Lan clients recieved a steady 256Kbps. Later switched to Internet, 2Mbps up. Which also means mathematically less MaxMsgSend.... and got similiar bandwidth usage, approx. 256Kbps per client, oddly enough on internet the bandwidth fluctuated more than on LAN. ...Syn...

Is your sole purpose in life is the stand in the middle of town crying 'Bad netcode' ???

This is retarded, since you do not know, there should be no need to open ports for a client application. If a client is behind a router, and most people do use routers, routers/NAT is a firewall. Running software firewalls does not provide more protection, it provides an additional obstacle for communication. Most users of Windows XP Sp2 or Sp3 have the Microsoft Firewall and a 3rd party firewall active, and wonder why they have connection issues. If the service is on, the product is on, not disabled via the control panel. So its in fact not 'a numpty or evil', your statement is. Maybe do some research on firewalls, NAT and TCP/IP in general, before making crass statements that you cannot back up with any facts. ...Syn...

Currently running ArmA² server, not Operation Arrowhead or Combine Arms, from Memphis, TN. If you are not on the west coast, you should get a sub 75ms ping to my server. Running on 16Mbps down / 2.2Mbps up Comcast Cable. And have been doing a few things to work some of the AI-Stutter out. Servername: Syn's ArmA² ...Syn...

HUGE... Do not put the dedicated server bandwidth tuning lines in a client's *.cfg. It does cause a ton of additional stutter, and likely the cause of all the stutter I got near towns. 2 hours in Benny 2.066 and fps at 25, removed a few ai teams, 12v12 insteada 16v16. Not doing the 100Mbps LAN config, back to 2Mbps config, I have 2 LAN, and 1 Internet clients. Each seem to be getting about 256Kbps each, server bandwidth is staying right around 768Kbps. ...Syn...

I'm getting something similiar to that on 100Mbps LAN. The server FPS is very low, but still in double digits. Its ok for the the other LAN client, but mine is stuttery in and near towns. I'm going to leave the MaxSizeNonguarantee'd commented out, and raise MaxSizeGuaranteed and lower MaxMsgSend, until it stops, or I see no change. since i'm currently doing: MaxMsgSend=102400; MaxSizeGuaranteed=128; going to: MaxMsgSend=51200; MaxSizeGuaranteed=256; Again, for 100Mbps LAN. Weirdly enuff the server monitor has yet to register over 256Kbps out for both clients. I'd also be very interested in that stripped down, possible benchmark-mission. ...Syn...

Really hard to say, if commenting out the MaxSizeNonguaranteed line is a benefit. Still see the AI stutter a bit around the 1km mark. But its not consistent. I got a second local client, and my client lined up for weekend testing. Guess we'll see how it goes saturday. ...Syn...

I've got no idea what causes De-Sync, other than a mission initializing. during a session it should not de-sync. I suggest a lower MaxMsgSend, and higher MaxSizeGuaranteed. MaxMsgSend=102400; MaxSizeGuaranteed=128; I do my testing with both client PC, and Dedicated server pc on a 1Gbps LAN. With MaxMsgSend setting, and MaxBandwidth I set my server for the internet connection, which is 2.2Mbps ( I only set for 2Mbps ). Again, you must configure your server for its bandwidth or like the above statement, makes little sense. ...Syn... ---------- Post added at 06:53 PM ---------- Previous post was at 06:50 PM ---------- Go for a more conservative Max/MinBandwidth setting, like 20 or 25Mbps. Either of which are still significantly more than my piddly 2.2Mbps upload speed. ...Syn...

You would need to set your server, in accordance with the bandwidth availible to your server. If there is little to no AI, then scripts would be the next resource to bog down the processor. If you have the stutter of other units, and you have the MinErrorToSend=0.001; then the next parameter to start working with is the packetsize regarding unit updates. MaxSizeNonguaranteed. AI units are not the only cause of processor usage, from what I'm finding the stutter everyone hates is a cause of UDP, dropping packets that are out of order. But AI units aren't the only thing that needs updates. Test of commenting out the MaxSizeNonguaranteed, so far CPU usage is down, just over 3 hours later. ...Syn...

Yes, 204,800 64byte packets equals 100Mbps. Do note, thats not counting for overhead, 100Mbps is impossible to reach on a 100Mbps LAN connection. After some more scouring the internet for more information on UDP, I think i can nail down the stuttery AI. UDP, while connectionless, also does not guarantee delivery or order. So if a client receives packets out of order, it drops it. Since unit location updates fall under MaxSizeNonguaranteed, I have commented the line out. In case its buffering to fill the packet, instead of just sending the information. Currently testing my server with: MaxMsgSend=8192; MaxSizeGuaranteed=32; // MaxSizeNonguaranteed=; MinBandwidth=2000000; MaxBandwidth=2200000; MinErrorToSend=0.001; I got to fire it up this morning, seems to be less CPU utilization on Warfare BE 2.066. Will monitor CPU usage during the day, when I get off, will try to get some clients in it. To double check AI stutter, which I noted, was amazingly less when I started the mission. ...Syn...

Smaller packet sizes, with the MinErrorToSend, has provided less stutter in MP. That last 100Mbps LAN test where I got 12Mbps was the last time I did a LAN test, all changes have been using the 2Mbps uppipe, and my brit gamin bud. If I was to do a 100Mbps LAN config it would be: MaxMsgSend=204800; MaxSizeGuaranteed=64; MaxSizeNonguaranteed=32; MinBandwidth=92000000; MaxBandwidth=100000000; MinErrorToSend=0.001; // Any lower is just as bad as 0.1 Which should leave room for overhead. And, I might get to test that this weekend. For now, I'm trying to find where I read, setting packets as large as they can be is for file transferring, and Gaming should use much smaller packet sizes. Then to determine, how much like TCP, UDP is. Kelly's setting didn't make much sense to me either. And, no-one has gone thru and explained the config's tuning options. Which have the exact same information since Operation Flashpoint. ...Syn...

I'm not sure what your point is, Jman. If you do not define the bandwidth requirements, then the application does what it wants. retarded? Altering the MaxMsgSend, and the packet size, I managed to configure the server to use 100Mbps-LAN, and it sent me 12Mbps to just me alone. Do what you will of others' information, or do your own research? ...Syn...

Do some research... If you set your MaxMsgSend lower, you will limit the bandwidth the server uses. Find the smallest packet the server will send, then set the MaxMsgSend to use the maximum bandwidth you have. Bandwidth shouldn't be an issue, because you have so much. But if you do not determine the optimal usage of said bandwidth, then its wasted. With the guideline, that for TCP, 64byte packets are the smallest that it uses, before it determines its a fragmented packet. UDP *should* be able to go smaller, because it doesn't acknowledge. I'm currently down to MaxMsgSend=4096; MaxSizeGuaranteed=64, and MaxSizeNonguaranteed=32; 2Mbps upload pipe to work with. PacketsPerSecond Tool Try that to see what I'm talking about, PPS and MaxMsgSend, should be the same term. ...Syn...

Goss, Something is wrong there, My Xeon E3110 Wolfdale @ 3.0ghz ( dual core ) with 4GB of DDR²@800mhz running Mandriva 2010.1 ( 2.6.31.13 )got 11fps. ...Syn...

Because everywhere else, I'm finding that large packets are for file transferring, and that gaming wants to use smaller packets. More Smaller packets, vs Less Larger packets. and thats where I've been playing around. I do note, that it seems to be less strain on the cpu with more smaller packets, than with packets larger than 512Bytes. but with the Larger packets, I see the server bandwidth stay closer to my 2Mbps upload. With the smaller packets, it seems to fluctuate alot more on the lesser than 2Mbps upload speed. Hard to judge, other than to keep testing different settings. ...Syn...

Well... Since you have posted the pipe is 100Mbps, why would you use 15Mbps as a minbandwidth? Even guessing for overhead should be between 88 and 92Mbps. Bandwidth is typically the issue, you should have little to no problems. I've been doing some research on the MaxMsgSend, and the MaxSizeGuaranteed, MaxSizeNonguaranteed. If MaxMsgSend is actually how many packets the server can send, in one simulation cycle, and MaxSizeGuaranteed is the packet. Then MaxMsgSend can be a very high number. Example 100Mbps can send 12,207 1,024byte packets. Somewhere I read that smaller packets is better for gaming than larger packets, and that larger packets are better for file transferring. But, thats using TCP, UDP is mostly used for gaming, and is connectionless and does not ack. With this, I have been experimenting with: MaxMsgSend=2048; MaxSizeGuaranteed=128; MaxSizeNonguaranteed=64; Because my upload speed is 2.2Mbps, which should be capable of 2148 packets at 128byte size. Giving myself a little headroom, there. Then I also read somewhere, that TCP treats packets smaller than 64bytes, as a fragmented packet. Which would be bad for gaming, but again we're using UDP here. So, with that in mind, MaxSizeNonguaranteed shouldn't be less than 64bytes. Hopefully someone else has more information, because mostly, the config file lets you fine tune network settings, and not really how the cpu runs the server. Pretty much go with the fastest CPU you can get and goo-gob's of ram! ...Syn...

Should be in contact with Valve, or checking the Steam Support Forums. Purchased through Steam, then thats where your support is at. ...Syn...

Typos not corrected, are a problem. If english is not a persons' first language, then you've effectively ruled out help from alot of people, cuz typo's make things non decipherable. Winders Web Server is probably not the best OS to run a non-web server application server. Juss sayin... Try creating a user account, that only has full access to the ArmA server, and nothing else. Use only that account to admin the ArmA server, try it at like User, before Power User. Make sure to add it to the RDP allowed users list too. ...Syn...

Right, mapping keys to buttons is rocket science. Using the SST is even easy. In the end its not even close to doing taxes. I used the in-game menu to map buttons to keys, axis' to whatever. Not sure what all the hoopla is, about this 50% throttle deal. ...Syn...