I'd be interesting if they were detecting VMs for, or just the presence of, clock jitter, skew and drift. I don't know much about CS:GO but I wonder if it might adversely affect game play network data.

It might be interesting for you to track those in the VM and sync tightly with NTP. Besides Windows' own NTP client perhaps one might experiment with something like:

http://www.bytefusion.com/products/ntm/ptnt/whatispresentense.htm

On 27 Feb 2017, at 17:26, Brandon Ganem wrote:

I've emailed and attempted to submit tickets. Asking valve is a heck of a
lot easier said than done.

On Mon, Feb 27, 2017 at 8:22 PM, taii...@gmx.com <taii...@gmx.com> wrote:

You guys really should ask valve :<
Something worth doing for better latency is an IOMMU attached networking
device.
The best choice for performance/latency is an SR-IOV networking device set
up with the new libvirt method (so the mac address stays the same)


On 02/27/2017 08:19 PM, Brandon Ganem wrote:

I've got a pretty normal network setup where i'm bridged to my wired. I can reproduce every time I play, somewhere between 15 minutes and 45 minutes.
It's happened 5 or so times now.

On Mon, Feb 27, 2017 at 8:17 PM, Scott <shewl...@unleashed-web.org> <shewl...@unleashed-web.org> wrote:


Why not just nat?

scott

On Feb 27, 2017 8:10 PM, "Ethan Bugden" <ethan...@gmail.com> <ethan...@gmail.com> wrote:


I got kicked after ~45 mins of DMing again, waited a couple minutes then it said "Your connection to matchmaking servers is not reliable" or similar attempting to find a game, while it let me join a local server. Repaired steam service and it let me on official servers yet again... wonder if it's due to networking differences. I use ARP proxy between my wireless card and
a TAP device.

On Mon, Feb 27, 2017 at 2:06 PM, Brandon Ganem <brandonga...@gmail.com> <brandonga...@gmail.com>
wrote:


Just got kicked again from a casual game. I had not been running it as admin, but doing so just now was not enough to let me back into a game.

I'll do my best to find some contact points with Valve and reference
this thread as well. Thanks again!

On Sun, Feb 26, 2017 at 9:59 PM, Ethan Bugden <ethan...@gmail.com> <ethan...@gmail.com>
wrote:


Just to clarify, you did repair the steam service in an elevated
command prompt/as admin, not a regular one? I've never had this problem occur and have it not solved by a repair, at least it should work long enough to finish your match. It does sound like this is an actual issue with playing in VMs being flagged in the first place though. I just did another 45mins of Valve DM in my VM without issues, I'll keep playing in VM when I play to gather some more info. I call qemu through the CLI, my CPU
line is: -cpu host,hv_time,hv_vapic,hv_relaxed,hv_spinlocks=0x1fff, I
don't hide KVM. I think we'd probably get better results emailing the VAC
and/or CSGO teams than submitting a ticket. We only want to use one
instance of the game, so hopefully if they're at least aware of this use case they can keep it in mind during future developments. Or if they fixed
the native client that would be nice....

On Mon, Feb 27, 2017 at 1:43 PM, Brandon Ganem <brandonga...@gmail.com> <brandonga...@gmail.com>
wrote:


I'll give it a go again if I get kicked after these changes. Thanks
for your help!

On Sun, Feb 26, 2017 at 9:41 PM, taii...@gmx.com <taii...@gmx.com> <taii...@gmx.com>
wrote:


Damn, like I said you should submit a support ticket with valve.

I am sure there is a way, no matter how hard the web 2.0 companies
try to make it.


On 02/26/2017 09:39 PM, Brandon Ganem wrote:


Updated to the following:
   <features>
     <acpi/>
     <hyperv>
       <relaxed state='on'/>
       <vapic state='on'/>
       <spinlocks state='on' retries='8191'/>
     </hyperv>
     <kvm>
       <hidden state='on'/>
     </kvm>
   </features>
   <cpu mode='host-passthrough'>
     <topology sockets='1' cores='6' threads='2'/>
   </cpu>
   <clock offset='localtime'>
     <timer name='hypervclock' present='yes'/>
   </clock>

So far i'm in a game, but it typically takes anywhere from 30
minutes to an
hour to get VAC'd based on the last 3 attempts.

On Sun, Feb 26, 2017 at 9:34 PM, taii...@gmx.com <taii...@gmx.com> <taii...@gmx.com>
wrote:

You need to use a newer version of libvirt that has the vendor tag

workaround to be able to get past that, it should also give you
better
performance to use all the hyperv enhancements.

This
<vendor_id state='on' value='whatever'/>
needs to be supported but I forgot which version added it


On 02/26/2017 09:30 PM, Brandon Ganem wrote:

Looks like I've got the opposite of all of that enabled, probably

was for
code 43 issues. I'll update to recommended hyper-v settings and
see.

On Sun, Feb 26, 2017 at 9:12 PM, taii...@gmx.com <taii...@gmx.com> <taii...@gmx.com>
wrote:

Did you try the hyperV clock? it could be a timer issue.


 _______________________________________________
vfio-users mailing listvfio-users@redhat.comhttps://www.redhat.com/mailman/listinfo/vfio-users



_______________________________________________
vfio-users mailing listvfio-users@redhat.comhttps://www.redhat.com/mailman/listinfo/vfio-users





_______________________________________________
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users
_______________________________________________
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users

Reply via email to