Slow Dedicated networking/block-sending

[Wizzard1]

Just a Q for Badspot, or anybody who is at least arm-deep in the code....

Is there any way to increase the rate at which my clients on my dedicated server receive bricks?
I have a persistence, say 70k bricks, and the bricks offscreen load before the onscreen ones, and at a rate of maybe 20-40bricks/second... Just an estimate, might be way off..... I go by what I see.

I'd just like to know, because I jsut souped up my internet, and noticed no speed boost for my clients!

I also have some numbers....
When I connect, over LAN, the connection never seems to go over 40k uploading. I have a 5MB upload cap!! LAN should be around 12.5MB!

What gives, in a nice way? :-D

[Ad Bot]

[Jervan]

I have the same problem with Middle-earth. People complain that it doesn't load fast enough.

What I tried.

I tried lowering the visible distance but it did nothing except for me. When I travelled beyond the "start sight" it loaded them in a pretty cool order, loading when I should see it. This didn't happen for anyone else though.

Solution

Beg BadSpot for a new loading system

Sorry I didn't have a proper solution :(

[Wizzard1]

Seems we are in the same boat! High performance and heavy use servers need a high performance system thats performs as such under heavy use :-D

Badspot- Can anything be done? Now that we have all these bricks, the burdon is having to send them!

Maybe, what we should do, is open a private FTP inside the program.... Have the program keep a snapshot persistence file, and send THAT file to people before they spawn. Just before spawn, they load the persistence, THEN do the current routine for brick-loading with the differential of bricks between the connection snapshot and the spawn time.

I can illustrate more, if you/anybody else needs.

Also, on the topic of persistences/blocks, is there a way to re-write the block saving routine, to occupy less space? I'd like a swing at optimizing it, if I could :-P

That.... And saving with ownership :-P

[Badspot]

Make sure your network settings on your dedicated server are set as high as they can go.
In base/config/server/prefs.cs set
$Pref::Net::PacketRateToClient = 32;
$Pref::Net::PacketRateToServer = 32;
$Pref::Net::PacketSize = 450;
(you must restart the server for these to take effect)

You are receiving the brick data as game packets.  The game packets are rate and size limited to work better over the internet and to be nice to the server's cpu and bandwidth load.  You can't simply load a save file on all of the clients because the ghostIDs won't match up.  Allowing packet sizes beyond 450 or rates higher than 32 has unknown results on network performance of people with lesser connections.  Running an ftp server a the same time as the game is going to screw over everyone who is currently in the game.

There is some room for improvement by sending the bricks in a better sorted order. 

[Wizzard1]

Anything I can do to help that along? I'm willing and I might be able!

Also.... (Might be me being picky on word choice) If I set a packet SIZE above 450... Will that only effect lesser users?

Maybe we need dynamic packet rate... Some send at 32/sec, others at 16, some at 64... Depending on their personal preference (IE their connection).

[Jervan]

Nice idea!

I would be willing to do anything to help the client loading be closer to perfect, it'd help me build bigger :o)

[Zerosan]

compressed packets would be fine too, just for the loading process.

and one thing I also thought about is putting files like sounds, decals, maps etc. on another area, like an ftp and let the client who joins load them from there.
This would provide better speed and removes much weight from the server.

[Badspot]

Each client can already set their own packet rate and packet size.  However, they cannot go above the values set by the server and the current hard-coded max is 450/32. 

Allowing values over 32 packets per second would be a waste once you are in-game because the simulation rate is only 32hz.  Theoretically, you could increase the packet rate for the initial loading and then decrease it, but currently this is not supported.

I can't remember what the exact reasoning is, but the max packet size of 450 is not arbitrary.  I believe it has something to do with the MTU of certain internet routers being ~550.  If you go over the MTU, performance goes to stuff as the hardware tries to break up the packets. 

My main concern with upping the values is that it will screw up the bandwidth throttling and you'll get the situation where when someone with a fat connection joins the server, everyone else lags out while they're raping the bandwidth.  This can already happen to some degree on servers with lesser amounts of bandwidth.  Also there's the general problem of tinkering with something low level like this and having huge unforeseen consequences that are difficult to debug.  I'd be willing to try upping the packet size to 1500 but it would definitely need serious testing.

[StoreClerk]

Woot! I finally got my huge platform of 400x400 1x1 bricks loaded. Too bad I crashed when I looked at them. 

[Jervan]

I'd test it for every bug

[Wizzard1]

I'd be more than happy to let many people test on my FAT 5M Upload pipe :-D

[Zerosan]

I could let it run on a 50MBit Server, only problem is that it runs dedicated under wine.