Problems solved
It turned out that the problem wasn't really that range calculation function. While it is the most expensive function in the whole server, the OS kernel also plays an important role. It has to deliver the data to and from the network cards, and that can take a lot of system resources.
So most of the delay was associated with the networking. Our host figured out that enabling Device polling, as it was on the old server, might help. And he was 100% right, now with about 150 connections, the server uses ~2% of the CPU, rather than 5%.
Tomorrow I will be able to see how much CPU it will take with around 500 connections, and if we are lucky, it should be under 10%
Unrelated to this, I implemented a few new things lately, and I think the players will have a nice surprise once they will be merged with the new server. One of the new things is a special cape, and the other thing is a secret.
So most of the delay was associated with the networking. Our host figured out that enabling Device polling, as it was on the old server, might help. And he was 100% right, now with about 150 connections, the server uses ~2% of the CPU, rather than 5%.
Tomorrow I will be able to see how much CPU it will take with around 500 connections, and if we are lucky, it should be under 10%
Unrelated to this, I implemented a few new things lately, and I think the players will have a nice surprise once they will be merged with the new server. One of the new things is a special cape, and the other thing is a secret.
posted by Radu at 1:47 AM
1 Comments:
Actually, we were not using true "device polling" feature in FreeBSD 4.x but the link0 feature included in the NIC (and NIC driver).
Taken from man fxp : Some chip revisions have loadable microcode which can be used to reduce the interrupt load on the host cpu. Not all boards have microcode support. Setting the link0 flag with ifconfig(8) will download the microcode to the chip if it is available.
Post a Comment
<< Home