Linux Net Code

[Dwarden 1124]

connectivity itself is waste of line if NIC is some funky onboard something

i can understand all the above...but don't really understand why an onboard NIC is not good..

onboard NIC can easily reach up to 100mb...the only problem with the onboard is that is using cpu cycles...but with today's powerfull or dual core cpus i don't think that should be a prob...

CPU overhead is one of factors as server NICs got own processing unit to offload work

yet they also uses own cache buffers and own memory ...

this usually plays no difference for client usage but in moment u get LOT of concurent traffic it starts to play role

it's not just about speed You can push thru adapter

from different angle look on it as on RAID cards ...

You can get onboard solution which works fine, it's fast, low cpu load (it does some work already in own chip)

and then You get 'pro' solution card, with own processor(s), own caches, own memory able to handle N times more devices and with transfer rates some dozen % higher and lower delay etc.

the cost is like i said somewhere else so no use for normal end users ...

[Mojo 0]

connectivity itself is waste of line if NIC is some funky onboard something

i can understand all the above...but don't really understand why an onboard NIC is not good..

onboard NIC can easily reach up to 100mb...the only problem with the onboard is that is using cpu cycles...but with today's powerfull or dual core cpus i don't think that should be a prob...

The processor utilization on the linux box was pushing 170% - so it is using more than one proc.

They aren't onboard ... PWLA8492MT PRO/1000 MT PCI-X Dual Port GB-LAN Adapters on a Gb/s connection. Max BW shows about 48mb/s down - don't recall the up link, but was less than the download.

2 Dual Core AMD Opteron 2214 processors - just looked the info up to be sure.

2gig RAM

250 gig drives in a raid config.

sending at 48mb/s (don't remember the receive numbers)

Seriously, this isn't a hardware issue. Unless the JIP and other net code issues can be addressed by tossing hardware at it.

[whisper 0]

These are not really issues per se, tbh, as you're simply pushing the engine to its limits. What you're asking for is wider limits, not exactly correcting something that is wrong.

[sickboy 13]

170% cpu usage on the whole box or the ArmA Process?

I can understand if the whole box would eat up 170%... System resources, network/disk/daemons etc, together with ArmA can reach 170% cpu, but otherwise I don't see how you can move past ~100% cpu on the arma process

[daikan 1]

170% cpu usage on the whole box or the ArmA Process?

I can understand if the whole box would eat up 170%... System resources, network/disk/daemons etc, together with ArmA can reach 170% cpu, but otherwise I don't see how you can move past ~100% cpu on the arma process

people tend to mix up cpu load and usage (as displayed in the windoze taskmanager). usage can never exceed 100%.

[Dwarden 1124]

The processor utilization on the linux box was pushing 170% - so it is using more than one proc.

They aren't onboard ... PWLA8492MT PRO/1000 MT PCI-X Dual Port GB-LAN Adapters on a Gb/s connection.  Max BW shows about 48mb/s down - don't recall the up link, but was less than the download.

2 Dual Core AMD Opteron 2214 processors - just looked the info up to be sure.

2gig RAM

250 gig drives in a raid config.

sending at 48mb/s (don't remember the receive numbers)  

Seriously, this isn't a hardware issue.  Unless the JIP and other net code issues can be addressed by tossing hardware at it.

well these NICs are 'qualite' enough (offload processor, 128kB onboard cache*)

as most cards with TCP/IP offloading these should cover most of TCP offload and some basic UDP offload ...

* onboard NICs either got no cache or 8/8, 8/16, 16/16 KB

tho i'm not sure (at all) if these INTEL cards offers advanced UDP offload (like checksum / reassembly etc)

in fact advanced UDP offload was always less important for usual server NIC cards ...

INTEL networks adapters can be configured with with Intel Priority Packet to set highest priority only to specified UDP/TCP ones

---

tho i don't like marketing PR BS of 'Killer NIC' card for gamers

(as end user product it's price is absurd 200,- Euro 333Mhz model K1 and 275,- Euro 400Mhz model M1)

more info at http://www.killernic.com/default.aspx

BUT it may be worth to check it's UDP offloading abilities and programmable layer for server hosting

as this 'may' be area where this card shine with correctly 'programmed' profile for 'nix' game servers

problem with 'Killer' NIC products is that there is way too much PR jumbo mumbo trash talk

while simple techspecs datasheet like Intel/3COM etc. got nowhere

(e.g. it took me hell of time to figure out Killer card fast buffer size and it's only 64KB (plus it's 32+32MB DDR2))...

btw. according to BigFoot theirs lead architect of Killer was working on INTEL design of Server 100 and 1000 cards

(ofc again that may be PR overrated talk)

---

btw. about CPU load at 170%

(i assume you mean first core 100% (running ArmA) and 70% second core (rest of OS tasks)

i doubt it's ArmA utilizing multiple cores in linux dedicated server ...

quite sure that fact would be told by BIS in bold statement

(if i'm wrong please correct me NOW   )

[sickboy 13]

people tend to mix up cpu load and usage (as displayed in the windoze taskmanager). usage can never exceed 100%.

on linux in top, the % is exceeding 100% when multiprocessors are installed, I haven't read your linked wiki page, but I was simply guessing the top tool on linux uses this method as opposed to the windows taskmanager that works only until 100%

[Mojo 0]

170% cpu usage on the whole box or the ArmA Process?

I can understand if the whole box would eat up 170%... System resources, network/disk/daemons etc, together with ArmA can reach 170% cpu, but otherwise I don't see how you can move past ~100% cpu on the arma process

people tend to mix up cpu load and usage (as displayed in the windoze taskmanager). usage can never exceed 100%.

You're right CPU load was 170%

Yet the "at rest" utilization is almost nothing, 1-2%, so I'm still not sure the server wasn't utilizing, at least in some part, both CPUs. Also, what other processes would increase the CPU load while the BI code is running?

We are still tweaking the scripts, changing between SQS and SQF to see how that affects the game play. It seems that JIP really is the worst of the issue causing desync spikes as players join or have ungraceful disconnects. That is what I'd like to see addressed, even if the joining players had to wait for a longer period in a loading/waiting state as the sync occurs, a sort of caching period as it were where data trickles to them when NIC/CPU utilization drops to a predefined threshold.(??) When a player joins they go to a default location, maybe freeze the player in place until the JIP process completes.

As pointed out, things like destroyed trees/buildings add to the process and even though we removed dead bodies after 60 seconds, those changes add up as well. By combining streamlined scripting, optimized server environment and some updates tot he JIP code, I think we could easily provide a smooth environment for 100 to 130 - and we could make the 200 mark - IF BI will help.

If you fine folks have any specific suggestions, I am all ears!

[Dwarden 1124]

what server build You use IC-mojo ? what OS , kernel build etc

[brit~XR 0]

Quote[/b] ]Just wondering if they are working on making the netcode better. Right now the CPU usage on a 2xdual core 1218 box is over 200%, not good. I can run ETQW on that same box full of clients at 20% CPU usage

lol thats funny. first of all you need to run arma on one core as it aint muti theaded and in big games cpu will hit 100% on any cpu. same as ofp really it uses max cpu it can to make game run smoothly. so maps like evo with 30 players will hit 100% cpu

Theres 1thing i noticed that causes alot of lag and thats the join in progress when players connect in game. really sucks when u get 3 or 4 players connecting at same time and desync kicks in. it evens makes my q6600 server look bad

[Mojo 0]

what server build You use IC-mojo ? what OS , kernel build etc

Server build: server-1.08.5064

OS: GNU/Linux

Kernel build: 2.6.9-55.0.9

Oh, one more bit of info - seems that hte lastest build has a glibc error - this may be a permissions thing, I've still to look into it.

[Dwarden 1124]

u mean 5169 ?

[Mojo 0]

u mean 5169 ?

yep, sorry - OK here's the report... we got 82 playing in the server without a problem ... until we suddenly started having everyone with Queen's Gambit installed drop with a Session Lost error.

We increased the minBW to 65mb/s and the max is at 131mb/s - players from EU, AUS and NA and no one reported any other significant issues. In three hours of play we had 1 red chain and two yellow reported and the highest desync we saw was less than 32000 at the red chain. The red chain lasted less than 30 seconds for all players we asked.

We had as close to zero desync as I think we could reasonably expect, we think the session lost was due to the QG somehow - any one have suggestions? What does QG add that could be the trouble there? What are the other possible causes of Session Lost errors?

Here is the copy of my ARMA.CFG:

language="English";

adapter=-1;

3D_Performance=1.000000;

Resolution_W=800;

Resolution_H=600;

Resolution_Bpp=32;

MaxMsgSend=192;

MaxSizeGuaranteed=512;

MaxSizeNonguaranteed=192;

MinBandwidth=65536000

MaxBandwidth=131072000;

MinErrorToSend=0.011;

MaxCustomFileSize=0;

[HitmanFF 6]

we think the session lost was due to the QG somehow - any one have suggestions? What does QG add that could be the trouble there? What are the other possible causes of Session Lost errors?

It's very likely that the session lost issue indeed is cause by QG. Check this post for information

[Johnnie_Walker 0]

We had as close to zero desync as I think we could reasonably expect

Do you mean you had no issues with jip lag?

[Mojo 0]

We had as close to zero desync as I think we could reasonably expect

Do you mean you had no issues with jip lag?

JIP - yeah there was a bit, but minor - there wasn't any major stuff there were a few folks who had maps that didn't update to reflect new territories taken. But we're actually happy about the over all performance

Over all - there wasn't any debilitating JIP lag

[armatech 8]

@mojo as stated i have had QB and the hot-fix for 3 weeks this means for 3 battles with out a problem what so ever until last week every one keep blaming the QG exspantion when it simply cant be try as until last week on the server i have not had a single disconnect nor issues on other servers in-fact i don't even run the QG mod folder when on the server so the only thing there is the porto island and lets face the facts that it was maid by bis any how so it would not cause issues. what i don't understand is why dose the file check not pick up porto island as it detects all other custom addons a bit strange if you ask me (*no one did i know*) any how i still believe there is issues with the XML systems on the server or just simply ArmA cant do what it says on the tin with the amount of players supported.

[Dwarden 1124]

armatech that would indicate issue with latest server betas

[Mojo 0]

armatech that would indicate issue with latest server betas

This is kind of where I was heading in the "investigation" I've added the accepted fix to the cfg.

OnDifferentData="{}" and RegularCheck="{}"

I'm hoping that these two additions will address the 'Session Lost' error .. We'll see come Sat. and I'll post the results.

[Mojo 0]

We have abandoned linux as our new server host only runs Windows .. 1.15 issues cropped up, they were network related, but I don't know what the underlying cause was.

http://www.flashpoint1985.com/cgi-bin....1314969

Posted about it there.