Feedback on the new router setup

[Wille]

Occasional long world saves are due to the server running the backup procedure.

If Palma can elaborate on the memory reasoning, we could take a look. However there is currently no evidence of memory being faulty. Windows has recorded no related events, programs don't freeze or act abnormally. Tiny percent of the 'crashes' have actually been the server software crashing, and even those are due to exceptions caused by the game world content. Network is the one that keeps acting up.

Antivirus, firewall etc software is being managed and they aren't intervening with the shard.

[Mike]

Well I guess all the usual culprits have been deal with. Have you checked if you've got bats or something?

[Tyrion]

Occasional long world saves are due to the server running the backup procedure.

If Palma can elaborate on the memory reasoning, we could take a look. However there is currently no evidence of memory being faulty. Windows has recorded no related events, programs don't freeze or act abnormally. Tiny percent of the 'crashes' have actually been the server software crashing, and even those are due to exceptions caused by the game world content. Network is the one that keeps acting up.

Antivirus, firewall etc software is being managed and they aren't intervening with the shard.

Has to be the ISP then. . . . . . . Why is a dedicated server out of the question again? Is it a cost thing or something else? There are companies that could host the server for us and offer a better option speed wise as it relates to 2d / 3d. Boris has stated before that it seems to be a promise or some other nostalgic reasons. Doesn't make any sense to avoid using an option that has not be tried before to see if it resolves the issues the server has.

[Wille]

As long as the server runs it'll be ran by the Danes who started it, locally. Simple as that. =)

[Mag'etherian]

Yeerrr,

I'll just add that prior to router switch, I wasn't having all these d/c issues that most everyone else was suffering. (Ontario, Canada here) Now with the new router, while playing yesterday, I was constantly d/c'ing. My opinion, it seems more unstable now. However, that could also be on my end. I will see how today goes and if I keep d/c'ing like yesterday then I'll report back.

*EDIT* Let me just add. Before the switch, I would rarely d/c. Not nearly as much as everyone else was though. Just randomly, but not all that often like others. However, yesterday I was d/c'ing a lot.

[Talerco Pious]

I'm getting a lot less DCs than before the router change. Finland here.

[Jessica]

I'm getting a lot less DCs than before the router change. Finland here.

Now been 5 hours online without DC + no DC's today for me. Finland aswell

[samuel reco]

I'm getting a lot less DCs than before the router change. Finland here.

Now been 5 hours online without DC + no DC's today for me. Finland aswell

same

[Palma]

It's hard to resume and copy links etc, it's based on experience and similiar problems... but I'll try to invent something to make sense.

Let's say the client connects to the server by TCP, TCP is handled by memory like everything else. So let's say you got a memory thing damaged, when the connection currently in progress tries to get a bit of memory usage for a specific connection (let's say a player), if it's the damaged one, it might have a "break", and take longer to get that ammount, meanwhile the client times out or looses connection.
The problem you got being specific clients and not the whole lot at once, prooves that it ain't network related.
Well could be, but then a whole area of players would get disconnected at once. Like all Portugal at the same time, all Sweden, etc.
It might be network related, but you say you changed router right? It's likely not the ISP disconnecting specific clients. The lines are made to support gazilions.

The computers on the other hand, are likely to have the problems.

If it was disk got stuck once in a while and with a "spike", you'd get all players disconnected.
Could be your graphics board, but not likely as the only services you probably have running is the server.exe thing and pulls nothing out of the graphics board, therefore not overheating and that stuff.
Could be motherboard, but same as would happen with the disk example.

RAM is the one that can spike, but eventually the PC grabs other bits memory, but in that small period, some TCP stops being handled, and players loose connection.

Unless of course you got your router using UDP, then the problem is simple, change it to TCP
UDP is basically sending packages ignoring the ones that get delayed, while TCP waits for the ones that are delayed.

Hope it helps

[Palma]

Found a bit of text that doesn't really help this case, but helps understanding the relation between TCP and memory usage etc. I'm very vague in my description, I dunno the terms lol. I just understand the logic

2.3 Complicated Memory Management

Current TCP/IP implementations use a complicated memory management mechanism. This system exists for a number of reasons. First, a multi-layered protocol stack means packet headers are added (or removed) as the packet moves downward (or upward) through the stack. This should be done easily and efficiently, without excessive copying. Second, buffer memory inside the operating system kernel is a scarce resource; it must be managed in a space-efficient fashion. This is especially true for older systems with limited physical memory.

To meet these two requirements, mechanisms such as the Berkeley Unix mbuf have been used. An mbuf can directly hold a small amount of data, and mbufs can be chained to manage larger data sets. Chaining makes adding and removing packet headers easy. The mbuf abstraction is not cheap, however: 15% of the processing time for small TCP packets is consumed by mbuf management [Kay & Pasquale 1993]. Additionally, to take advantage of the mbuf abstraction, user data must be copied into and out of mbufs, which consumes even more time in the data transfer critical path. This copying means that nearly one-quarter of the small-packet processing time in a commercial TCP/IP stack is spent on memory management issues. Reducing the overhead of memory management is therefore critical to improving communications performance.