# Gentoo on HyperV running SRCDS

## BloodyIron

Hey Folks,

I'm running a Gentoo VM on a HyperV box for the purpose of running a Team Fortress 2 server.

So the server is setup pretty much identically to multiple other servers I've setup except for the HyperV parts. In the earlier parts of setting it up I was using the non-legacy NIC however when I changed the MAC to static I was never able to get the non-legacy NIC working, so I have had to switch to a legacy NIC with dynamic MAC.

The problem is that the tf2 server after a while starts stuttering for all players on the server. I have not yet found a resolution for this beyond rebooting the whole VM, which isn't exactly the best solution. Sometimes it can take only 30 mins before I have to reboot the VM, sometime's it's longer.

I'm pretty sure it's not running out of RAM as htop reports (so far as I can tell) 50% usage. The VM has 1GB allocated.

Anyways, I'm not sure what I can do about this situation as I'm kind of baffled this is happening in the first place.

Any ideas?

----------

## Yuu

Hi BloodyIron,

how much CPU usage do you use when your server : is running fine and when it starts stuttering ? If you have a lot of players, you should consider reducing the maximum number of players.

You should also analyse your network interface before and when the lag appears. For this, you can use tcpdump and/or wireshark. And if you're running an headless server, use tcpdump with -w on the server, then download the .cap file and open-it with wireshark.

Good luck :]

----------

## BloodyIron

The CPU is nowhere near being fully utilized when this happens, it's not related to the number of players in any shape or form as it can happen when only one or two are on, or when it's completely full. I don't think it's a network issue as the VM is directly internet facing.

 *Yuu wrote:*   

> Hi BloodyIron,
> 
> how much CPU usage do you use when your server : is running fine and when it starts stuttering ? If you have a lot of players, you should consider reducing the maximum number of players.
> 
> You should also analyse your network interface before and when the lag appears. For this, you can use tcpdump and/or wireshark. And if you're running an headless server, use tcpdump with -w on the server, then download the .cap file and open-it with wireshark.
> ...

 

----------

## BloodyIron

bump

----------

## BloodyIron

Really, nobody knows about this?

----------

## cach0rr0

 *BloodyIron wrote:*   

> Really, nobody knows about this?

 

HyperV isn't the most common 'round these parts. Don't know how many eyes that happen upon this thread are going to be all that familiar. 

I personally can only really take stabs in the dark. 

The networking thing - I wouldn't look there inasmuch as lost traffic, but it could well be the case a buggy network driver or some virtualization "glue" becomes unstable after a while, or under load unrelated to concurrency. Where *I* would start testing, is taking the game server software out of the equation (e.g. just stop whichever daemon), see if you can recreate the issue by generating a bit of sustained network load. I don't know if your game server uses TCP or UDP, but for testing TCP as a potential cause you could e.g. transfer a handful of relatively large files in rapid succession. For UDP I'm not sure. 

If that yields nothing, I'd look more in the direction of the software itself. Doesn't have to be eating up gobs of memory or disk I/O or CPU to be wigging out. 

Or, you could always try a lower latency kernel (e.g. zen-sources, rt-sources, pf-sources, ck-sources, with BFS and the other round of goodies)

All blind shots in the dark, this is somewhat of an esoteric case on a virtualization platform id wager not too many gentoo users use.

----------

## BloodyIron

thx for the heads up, I've made some adjustments to the tf2 server itself, going to see if that changes anything.

failing that I'll see if the kernel has anything to do with it.

The problem is that it happens after a period longer than 30 minutes, so it would seem a bit of a pain to sustain bandwidth for such a long period, as I would likely want to test for upwards of 5-12 hours. Is there a utility you know of to do something to this effect?

 *cach0rr0 wrote:*   

>  *BloodyIron wrote:*   Really, nobody knows about this? 
> 
> HyperV isn't the most common 'round these parts. Don't know how many eyes that happen upon this thread are going to be all that familiar. 
> 
> I personally can only really take stabs in the dark. 
> ...

 

----------

## cach0rr0

 *BloodyIron wrote:*   

> thx for the heads up, I've made some adjustments to the tf2 server itself, going to see if that changes anything.
> 
> failing that I'll see if the kernel has anything to do with it.
> 
> The problem is that it happens after a period longer than 30 minutes, so it would seem a bit of a pain to sustain bandwidth for such a long period, as I would likely want to test for upwards of 5-12 hours. Is there a utility you know of to do something to this effect?
> ...

 

got another internal box you can use to host a large file? (I say internal so you arent eating external bandwidth just for a test)

```

while true; do wget http://192.168.blah.blah/largefile.iso ; rm ./largefile.iso ; done

```

or if you have e.g. a /music directory with a crapton of files, talking like 30GB of music, do an scp -r to the server and see if you can get it to choke (hopefully you dont run out of disk on t he server first)

you get the idea. I would lean towards testing on a different physical piece of hardware, purely to make it seem as real as possible to the guest OS that it's fetching an externally hosted file, rule out the underlying host OS, etc. 

dmesg is always your friend as well. No real educated way to tell you what to look for in its output, since we havent the foggiest idea even the vicinity of what might be causing it, pretty much `dmesg` once it starts acting up, and hope you get lucky. 

Hopefully it can be easily repro'd with the tf2 server out of the picture, largely since troubleshooting a specific application on the fritz adds a whole other layer of complexity. 

...i don't know if any of that makes sense, i really shouldnt be posting til ive had my nicotine hit.

----------

