#Mornedhels Proton Docker Image Testing

1 messages · Page 1 of 1 (latest)

slender aspen
#

Thought i would create a thread to organize the effort of running the dedicated server testing with proton to ground and reporting results.

regal tartan
#

jeah, thats a good idea

#

I just searched it via steam and found it

naive tusk
#

Hey, I'd be willing to help / login as well, as I'm interested in a Proton based image as well. I just can't go far in the game as I haven't played it yet / don't want to be spoiled 😄

I'll add the server in the Steam server browser now.

regal tartan
#

jeah same fell_salute
I'm just sitting at spawn

naive tusk
#

Joining now.

slender aspen
#

My experience with the wine based server images didn't require much to experience massive latency issues for all players.

naive tusk
#

I'm ingame now 🙂

regal tartan
#

cool, we are 3 now

#

cpu is about 250%

slender aspen
#

Latency seems stable. I'm seeing if i can get any of my static group to join.

regal tartan
#

with one its 230% or something

#

without proton it was arount 300%

#

not sure what a increased number of users did to that

slender aspen
#

running wine i say about 300% idle and went over 500% with 5 on the server then latency would spike for unknown reasons over 4k and upwards of 50k

naive tusk
regal tartan
naive tusk
#

Apart from latency I'm still suffering from a different problem with my personal setup, as I'm running https://github.com/jsknnr/enshrouded-server on a kubernetes cluster (like many other game servers). I find the game in the steam and ingame server browser, but when I join it fails and logs the the dreaded "error 4" that lots of people have mentioned.

Both UDP ports are properly configured throughout and I've tried and debugged for two evenings now. I've even talked it through with jsknnr but we are clueless what's happening in the game's binary.

Do you have any advice? I'm thinking of switching to a simple Docker based server for this and would then base it on a image using Proton.

regal tartan
#

we are around 280% now

naive tusk
#

Latency is stable on my end at about 34 from Germany (though I'm just idling at spawn).

slender aspen
#

with k8s you would have a service proxy or something for the UDP traffic flows? i doubt it would have any impact on the setup but thats the only significant difference i can think of unless you went hog wild on 18 boutique features to overcomplicate your k8s environment.

regal tartan
#

you could also try using a nodeport and see if that works

slender aspen
#

now grain of salt with me... i am no k8s expert but i did stay at a holiday inn express for what thats worth.

naive tusk
#

Thanks for reacting guys as this thread is really about the Proton Image 😄

My setup is very simple: As my cloud load balancer doesn't support UDP, I use services of type NodePort for all my game servers (Factorio, CoD2, Valheim etc. all work). So it's a setup I'm familiar with. Today I tried the following options to simplify the networking even further, but no dice:

  • using externalTrafficPolicy: Local on the Service to preserve the client source IP (https://kubernetes.io/docs/tutorials/services/source-ip/)
  • using hostPort directly on the Pod and disabling the Service (not recommended but I was wondering if the NodePort / network setup is to blame)
  • setting SERVER_IP env variable in the Deployment to the Pods IP instead of the default 0.0.0.0, because people were talking about problems with multiple network interfaces.
naive tusk
# regal tartan puh, does the enshrouded log file display some more information?

The logs always look the same, here's an example:

[OnlineProviderSteam] finished transition from 'Uninitialized' to 'InGame' (current='InGame')!
[Session] 'HostOnline' (up)!
[Session] finished transition from 'Lobby' to 'Host_Online' (current='Host_Online')!
[server] Load deserialization took 3.40 s
[online] Session accepted with peer ( id ID ).
[online] Added Peer #0.
[ecss] Stats:  Upd:3,588  (16.7ms)  Time:60,006ms  Total:21,979ms  Max:95ms  Avg:6.1ms  +:0  -:0  Ent:579  Pred:0
[online] Session failed for peer #0 with error 4.
[online] Removed Peer #0.
slender aspen
#

what is this test server running on? docker on a vm in your lab running on proxmox or is it hosted in a cloud service? any details on resource allocations to the system?

#

sorry @regal tartan for the above

regal tartan
#

you mean the k8s cluster or my server?

slender aspen
#

your server.

#

the k8s cluster isn't on topic... sorry pfauen

regal tartan
#

it's a dedicated renter server with ubuntu 22.04

#

let me check the exact stats

slender aspen
#

i have atleast 1 of my static who will pop on shortly,.

regal tartan
#

AMD Ryzen 5 3600 6-Core Processor

#

64gb ram

naive tusk
#

Yeah, sorry about that. I was getting desperate because I can't find the reason in the otherwise perfectly working setup. Let's focus on the test here 🙂

slender aspen
# regal tartan AMD Ryzen 5 3600 6-Core Processor

my build is a 16vcpu vm on proxmox with a 1st gen threadripper. 8c16t all allocated off the same numa node along with 24GB of memory. based on your specs i shouldn't have any issues with resource constraint and that was my observation based on performance graphs of the vm and the container.

#

max peak cpu utilization wasn't more than around 500% with wine.

regal tartan
#

well its two layers of virtualization - but the proton image should help to reduce the load

slender aspen
#

one of my static joined so we have 4 players on and latency hasn't changed in any significant way.

regal tartan
#

300-310% now

#

now back to 290%

slender aspen
regal tartan
#

I cleanup the scripts a little and create a new tag for that - proton-dev or something

slender aspen
#

link it here when you are ready please and thank you.

naive tusk
#

I'll give it a test run as well 🙂 Thanks for your hard work!

#

Just contacting a friend to possibly join as well.

regal tartan
#

@slender aspen how big was your group?

slender aspen
#

myself included

regal tartan
#

k, I would like to see what your cpu stats will be. with 4 its about the same with only 1 connected

#

I could also start the same server with the old setup and see the numbers

slender aspen
#

i suspect there was some sort of socket handling issues but i'm no developer either. we had one clown that couldn't figure out how to copy/paste the password properly and every time he tried to join the latency began to climb. minor observation and may only be expected behavior that is amplified by other issues but it was an observation we had.

slender aspen
regal tartan
#

nice, so buckle up - the server is shutting down fell_salute

naive tusk
#

There it goes 💥

regal tartan
#

and it's up again

slender aspen
#

was wondering what was going on... i was waving my wand around like a pickaxe and failing to mine anything at all 🙂

#

is this the wine build rather than the previous which was the proton build?

regal tartan
#

correct

#

its 290% with one

#

340-350% with 2

slender aspen
#

latency seems stable.

#

i wonder if wine had issues with my nic...

#

the vnic assigned to the vm... virtio vs e1000. not sure how that would be but spitballing.

regal tartan
#

could be the double virtualization to increase the impact. Do you use the host cpu settings or does proxmox provide the generic cpu?

slender aspen
#

host cpu was selected.

regal tartan
#

k

slender aspen
#

and double virtualization may have some impact but should not be that significant.

regal tartan
#

well, than only one way to find out. I prepare the image and ping you here

#

and it spikes to 400%

slender aspen
#

thats my thought. give it a go and see how it works.

regal tartan
#

with 4 users connected

#

so it increases by around 30%-40% cpu utilization per connection vs around 10%

#

so for bigger groups defenetly a big improvement

slender aspen
#

i'm going to punch out and wait eagerly for you ping me. i'll ping back on here once i have the container operating and initial observations.

naive tusk
#

That's great news 🙂

regal tartan
#

So thanks for the help fell_love

slender aspen
#

thank you for yours.

naive tusk
#

"feat: add proton image" Exciting! 🙂

regal tartan
#

dev image is available dev-proton @slender aspen

slender aspen
#

Excellent. I'll check it out and report findings. Thank you.

regal tartan
#

well, I also found the first issue: you have to force an update to work properly

#

for now: docker compose exec enshrouded supervisorctl start enshrouded-force-update

naive tusk
#

I've set up a separate and fresh Docker only setup on a Ubuntu 22.04 in Hetzner Cloud and was able to start the server with your new image. Though my old problem still remains, despiting following the advice from here: https://github.com/jsknnr/enshrouded-server/issues/16#issuecomment-1909431315. This is getting really weird. I reused / reimaged the same vm, so maybe somethings wrong with it .. but seems unlikely.

enshrouded  | 2024-01-27 16:26:50.149 supervisord: enshrouded-server [online] Session accepted with peer ( id 76561198019022967 ).
enshrouded  | 2024-01-27 16:26:50.149 supervisord: enshrouded-server [online] Added Peer #0.
enshrouded  | 2024-01-27 16:26:52.961 supervisord: enshrouded-server STEAMPS3 - AsyncTCPSocket created
enshrouded  | 2024-01-27 16:26:52.962 supervisord: message repeated 2 times: [ enshrouded-server STEAMPS3 - AsyncTCPSocket created]
enshrouded  | 2024-01-27 16:27:05.118 supervisord: enshrouded-server [online] Session failed for peer #0 with error 4.
enshrouded  | 2024-01-27 16:27:05.120 supervisord: enshrouded-server STEAMPS3 - AsncTCPSocket destroyed
enshrouded  | 2024-01-27 16:27:05.122 supervisord: message repeated 2 times: [ enshrouded-server STEAMPS3 - AsncTCPSocket destroyed]
enshrouded  | 2024-01-27 16:27:05.122 supervisord: enshrouded-server [online] Removed Peer #0.
#

It seems enshrouded uses a whole variety of different ports? Out of sheer desperation I disabled the Firewall for the server and I can login immediately. Here are the ports used. What am I missing?

root@docker-1:~/enshrouded# netstat -tulpn | grep enshrouded
tcp        0      0 IP:46103         0.0.0.0:*               LISTEN      3485/enshrouded_ser 
udp        0      0 IP:40112         0.0.0.0:*                           3485/enshrouded_ser 
udp        0      0 IP:15637         0.0.0.0:*                           3485/enshrouded_ser 
udp        0      0 IP:57279         0.0.0.0:*                           3485/enshrouded_ser 
udp        0      0 IP:41454         0.0.0.0:*                           3485/enshrouded_ser 
udp        0      0 IP:34479         0.0.0.0:*                           3485/enshrouded_ser 
udp      768      0 IP:35017         0.0.0.0:*                           3485/enshrouded_ser 
udp        0      0 IP:51556         0.0.0.0:*                           3485/enshrouded_ser 
udp        0      0 IP:51713         0.0.0.0:*                           3485/enshrouded_ser
#

Or am I the only one also using outgoing firewall rules in addition to incoming? 😄

slender aspen
slender aspen
#

server appears to be operational. connecting to it now. no issues with creating the container through compose.

regal tartan
slender aspen
#

1 clinet connected is running about 250%

regal tartan
slender aspen
#

latency is stable with 1 client

regal tartan
#

if not provided, it forces an update

slender aspen
#

apparently i have another errand to run... i'll be back in a bit and have the server opened up for testing since my static doesn't seem to be available atm.

regal tartan
slender aspen
#

if a password is provided it writes it the json file. if a password is not provided in subsequent starts it does not remove it

#

Or perhaps it would if I didn't comment out the environment assignment in the compose yaml

regal tartan
#

no, thats by design. I wanted to keep the possibility to set the json by hand.

#

But I should add that in the readme fell_smort

slender aspen
#

with 2 clients the most it got to was 300%

#

latency was solid.

#

memory consumption is very down as well... thats nice.

naive tusk
#

Now that I've figured out the outgoing firewall rules, I updated the jsknnr's Helm Chart to use your dev-proton image. Best of both worlds! 🙂

On my 4 vCPU (shared) 16GB VM the CPU load went from 380% (wine) to 280% (proton) with two players idling at spawn. So great success for me with weak hardware. Thanks so much!