Problem running batchmode

[Damian Sobczak]

Hi :)

I think I've found another bug in beta6.

I was trying to run  my project in batchmode on Windows Server 2008 R2 based VPS, but it did'nt started propertly. It takes about 7MB of RAM and after a while it starts to load 100% of CPU. Normally this project takes about 200MB of RAM and 1-5% of CPU. Of course I cannot log into it by te client. When I'm running it on my dev machines in batchmode it is ok. It only happens on this VPS where there is no graphics card at all. The logs are like below:

Initialize engine version: 4.0.0f5

Forcing GfxDevice: 4

NullGfxDevice:

Version:  NULL 1.0 [1.0]

Renderer: Null Device

Vendor:   Unity Technologies

On uLink 1.2 every worked fine on this VPS machine.

I tried the same with Snowbox demo project. It should take about 25MB of RAM (the Server1 and Server2 scenes), but it takes 7MB and not working propertly. On devmachines batchmode works well.

[Aidin Abedi]

Hello Damian,

Please try opening the file "Assets\Plugins\uLink\Utility Scripts\uLinkTargetFrameRateFix.cs" and change line 2 from:

#define FIX_APPLICAION_TARGETFRAMERATE

To:

//#define FIX_APPLICAION_TARGETFRAMERATE

And let me know if it helped.

Cheers,

Aidin

--
 
 

[Damian Sobczak]

Hello Aidin,

I've changed this line, but it didn't helped.

Btw. I'm using Unity 4.0.0.5f

[Aidin Abedi]

Are you sure that uLink 1.2 (on Unity 4) worked fine in this VPS?

What VPS hosting service are you using and can you find out which virtual machine software they are using?

Another thing you could try is adding the following line just before initializing the server (or connecting the client) in the project:

uLink.Network.config.timeMeasurementFunction = uLink.NetworkTimeMeasurementFunction.TickCount;

--
 
 

[Ashkan Saeedi Mazdeh]

Aidin

Is this timing functionality something hand coded with less drifting or is just a .NET StopWatch?

I was thinking of this problem of having a server running for a long time and using unity's time function.

 

Cheers

--
 
 

--

Ashkan Saeedi Mazdeh

co-founder MindHammergames

Skype: ashkan_gc

cell: +(98)9193046544

LinkedIn http://ir.linkedin.com/in/ashkansaeedimazdeh

http://mindhammergames.com

[Aidin Abedi]

The reason uLink 1.3 switched default time measurement function from TickCount to Stopwatch is because, in some VM environments TickCount is more subject to drifting due to the way it is implemented in Windows (using interrupts). It's generally easier for VM software to hook Stopwatch (which uses QueryPerformanceCounter) into calling the host hardware's timer and hence avoid additional clock drifting due to virtualization. So in short, Stopwatch is usually subject to less drifting but not as widely tested as TickCount in uLink, yet.

It may also be good to know that, on windows uLink doesn't actually use Stopwatch (even if it's the selected time measurement function) but instead calls QueryPerformanceCounter directly due to a bug in both mono's and .NET's implementation of Stopwatch in windows. So on windows, if you choose Stopwatch, uLink actually calls QueryPerformanceCounter (with timeGetTime as fallback) - which is exactly what Unity also does internally.

Even thought Unity has a high precision timer internally, the external API unfortunately converts it to a single floating point (as you mentioned Ashkan) - therefore it is not wise to use Time.time/realtimeSinceStartup/timeSinceLevelLoad for high precision calculations in long time running servers. The physics engine and I believe other time Unity built-in timing functionality (such as Invoke etc) still accesses the internal high precision timer but for you own high precision timing calculations it is better to call uLink.Network.time instead of Time.time.

--
 
 

[Damian Sobczak]

I've tried to add this line just before server initialization but it
still doesn't work.

I'm sure that this same piece of code works well with uLink 1.2
project compiled in Unity 4, because it is running on this VPS right
now.

I'm using VPS hosted by myself in my organization's serverroom. We are
using VMWare 5 for virtualization.

2012/11/20 Aidin Abedi <aidin...@gmail.com>:

> --
>
>

[Damian Sobczak]

Hello again.

The solution is trivial :)

I've changed Architecture in Unity's Build Settings from x86_64 (x64 in previous versions) to x86 and the server started propertly. I presume it's because of uLink.dll is compiled in x86 architecture and Unity's x64 executable is not able to propertly run this dll in virtual machine environment and/or Windows Server 2008 R2. My dev machines are Win7 based so maybe the  OS is the problem?

For now the client connects to the server which I can see in server's logs.

[Aidin Abedi]

Hello Damian,

uLink.dll is neither compiled as 32 or 64-bit, it's a pure architecture-independent (Any CPU) .NET managed assembly. I'm suspecting that uLink 1.3 is using something in the .NET framework which has a bug (or something making it VMware/Win2008R2 unfriendly) in Unity 4's Mono x64, and which uLink 1.2 previously didn't use.

In the zip file below, we've prepared and built 4 different simple servers (using different uLink and Unity versions). Please try them in your VMware/Windows Server 2008 R2 environment and report which of them is showing this 100% CPU issue:

http://download.muchdifferent.com/ulink/64bitSimpleServers.zip

Sincerely,

Aidin

--
 
 

[Damian Sobczak]

A and B are ok, while C and D show this CPU/RAM issue.

[Aidin Abedi]

Thank you Damian!

We've built 3 additional standalone players below, to see if we can narrow the issue down even more. Please report if any of them still has the issue.

http://download.muchdifferent.com/ulink/64bitSimpleServers2.zip

--
 
 

[Damian Sobczak]

All of them, E, F and G have the issue.

Regards,

Damian

[Aidin Abedi]

It seems the issue is not at all related to uLink (whether 1.2 or 1.3). But instead has generally to do with Unity 4.0's standalone x64 builds on VMware + Windows Server 2008 R2. Below are the different configurations of the 64-bit standalone players:

A: Unity 3.5 + uLink 1.3

B: Unity 3.5 + uLink 1.2

C: Unity 4.0 + uLink 1.3

D: Unity 4.0 + uLink 1.2

E: Unity 4.0 + simple script (targetFrameRate = 60; runInBackground = true), no uLink

F: Unity 4.0 + simple script (targetFrameRate = 60; runInBackground = false), no uLink

G: Unity 4.0 + uLink 1.2, (stripped away Camera, GUI, all code but calling Network.InitializeServer)

We strongly encourage you to contact Unity Technologies, or at minimum just file a bug report, regarding the issue. I've attached the simplest Unity project (F), with it's simple script (which only calls "Application.targetFrameRate = 60;").

Sincerely,

Aidin

--
 
 

[Damian Sobczak]

I tried creating empty project in Unity 4 with one empty script doing nothing and I can confirm that this is Unity's bug.

Thank you Aidin for your help. I'm happy that it's not uLink issue :)

I've reported the bug to Unity and wrote about it on their forum.

Thank you once again!

Sincerely,

Damian