Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by SAS_Storebror

  1. Yesterday for the first time in my IL-2 life, I've suddenly lost connection to our server as a client side issue. We've been playing together with two players, I've been the only one to get booted. My Internet connection was fine (been using Teamspeak in parallel, no interruption, checked the router, no interruption) as was the server's connection. My connection to the server was fine as well all the time (remote desktop open in parallel), it's just been the IL-2 Client <-> Server connection that dropped all of a sudden. This reminded me of one very nasty feature of IL-2 Great Battles: Tons of logfiles, but not a single useful one. That's odd. We could track so many issues if we just had logs like we do e.g. in IL-2 1946. But we don't. On the same note, am I the only one who has to clear the editor in the forum's "reply" field each and every time? Any time I enter the "reply" field, I get some random content thrown in with a bottom line saying "your previous content has been restored" - very annoying. Mike
  2. Saying that a program is singlethreaded as an abbreviation for a program that technically uses multiple threads, but puts all the CPU heavy tasks into a single one, is quite common. If it wasn't, then IL-2 1946 was a multicore winner Nevertheless, let's agree on "all the main work is done in a single thread", okay? Concerning net replication: Sure, we don't know how it's being done. Nevertheless it's no rocket science. For instance, we know how network replication is being done in IL-2 1946 (well at least I do). The key to success is that the server doesn't need to care for whether or not the client receives it's packets. You send a stream of packets together with an auto-incrementing index. If everything goes well, the client receives them all within a reasonable timeframe. If not, the client goes out of sync and has to wait until the next "key" datagram drops in, which contains all the data required to get everyone back in sync again. Clients connecting to the server have to wait for the next key datagram as well, for the very same reason. That key datagram can come e.g. every 10 seconds, that's absolutely sufficient. Both of these tasks can be completely decoupled from the remaining server logic, since in the opposite direction it works exactly the same way (clients send key datagrams every 10 seconds and inbetween, just small update packets). The Server has five completely independent threads: One deals with the server-internal logic. One simply receives and forwards any client update packet to all other clients, fire and forget, and puts them in a local stream for the internal server logic. One processes the update packet stream and applies it to the server's world. One takes snapshots of the current world as the server has it, every 10 seconds. One sends a key datagram with the latest world snapshot to all clients, every 10 seconds. Mike
  3. Sorry but --- no. The network part is covered by the 2% CPU load thread, not by the 92% one. Furthermore, from a CPU usage (and hence performance) point of view, it almost doesn't matter how many clients there are connected to the dedicated server. Almost means: If the CPU load is 65% with 10 users connected, it's 60% when no one is connected at all in the very same situation. The key to successful multithreading is to get thread concurrency handled correctly, which means don't create any race conditions, but keep things independent on as many threads as possible. This comes true to networking stuff in the very same manner like it does for anything else. Truth is that a single bottleneck in synchronization can kill your whole concurrency concept. Mike
  4. Crossing the fingers didn't help much, we have the next two crashes: Aug 08 08:52 PM - uptime 94:46 hours Aug 08 11:16 PM - uptime 2:24 hours Now the interesting part of these two crashes is that we've monitored the system status in parallel, and at the time of the crashes there were 3 (first crash) / 2 (second crash) DServer.exe processes running. At the moment I have no clue what might cause multiple DServer.exe processes to spawn. Mike
  5. Just for reference: I'm not saying that the Client (Il-2.exe) doesn't make use of multiple cores. I simply haven't tested this yet. All I'm saying is that DServer.exe cannot make use of more than one core to any significant amount. General consensus in terms of multi core CPUs seems to have been that DX11 adds reasonable support for up to 4 cores and DX12 goes somewhat beyond that, with an improved resource allocation among threads with heavy CPU usage. Now if the Client can make good use of 4 cores with DX11, then I don't think that it's worth the effort to take the step to DX12 (yet), especially taking the limited development resources of the Team into account. On the dedicated server the issues are completely different. Here we're not fighting any DX11 vs DX12 battle, this is much more a matter of sheer concurrency within a native application (whichever framework there is behind it). Mike
  6. No matter how much Jason keeps being annoyed, the truth stays the same. Yes, IL-2 runs multiple threads. Problem is: Only one of them is the CPU hog. Analyzed here, easy to reproduce for each and everyone on his own: Mike
  7. Alright in that case, if you get more for the same price, why not? And I agree that the more AI you have, the more you wish your CPU was an i7-8086K I thought of a price difference rather in the 50-70% range, which would not justify a 19% speed gain but 0% definitely does Mike
  8. On the other hand, a 7700K has 2583 single thread passmark points @4.2 GHz, overclocking to 4.5 GHz is a 7% gain in clock rate, which even under perfect circumstances gives you no more than 3.5% speed increase, which would mean 2675 passmark points. Compared to our "dry stock" 4770 with 2253 passmark points that's 19% speed gain. I would tend to say that if one of both CPUs gets exhausted, the other is likely to do so, too. It'd be quite hard to match that margin. For instance, if our CPU would be beefed at a Tick Delay of 20ms, yours would show 17. That'd be too much for reliably hosting the mission either case. Mike
  9. Funny thing is that even though nothing changed, our server is running for about 90 hours without crashes now. I'll keep my fingers crossed. Mike
  10. Get the Sysinternals suite from Microsoft Technet and crank up the Process Explorer (64 Bit Version). Double-click your process (IL-2.exe for the Client, DServer.exe for the dedicated server) and open up the "Threads" tab. That'll give you an idea. Mike
  11. I beg to differ. Jason apparently talks about the game Client. Maybe that one makes better use of Multiple Cores and Threads, didn't care too much so far. What I'm talking about is the dedicated server aka "DServer.exe". That one is multithreaded and as such makes use of multiple cores too, however take a look at this yourself: How much multicore support or multithreading is there in DServer.exe when one thread consumes more then 92% of the total CPU power used by DServer? The next biggest consumer is the network stack with 2%, anything else is just negligible. @edit: Note that the CPU usage percentage is calculated for all (virtual) cores. Since the system depicted here uses an i7-4770 with 4 physical cores and hyperthreading, the real usage per virtual core is the given values times 8. This means that the "big" thread from DServer in the picture above consumes 59% of the CPU power he can get from that core. Mike
  12. Because nothing beats the quantity and quality of mods available for 4.12.2, hands down. Asura's DGEN is far from being on the same level like BAT. Mike
  13. No thanks. Subscription is a bad idea. I think it's a brilliant idea. Mike
  14. No sir. What we have now is strictly single thread. At least on the dedicated server that is. The limit is 50 simulations per second (+/- 0.2 or so) and a tick delay of 20 milliseconds (actually it starts getting quirky at around 17-18 milliseconds tick delay). If you compare those numbers with the CPU load caused by dserver.exe, you will soon notice that exactly at the time when dserver.exe reaches a load of 100% on one core/thread, you reach the magic 20 milliseconds tick delay (and that's a linear figure from 0 milliseconds tick delay = 0 % CPU load, over 10 milliseconds tick delay = 50% CPU load to 20 milliseconds tick delay = 100% CPU load, all adjusted to a single core and thread). So anything that happens on a dedicated server right now, if it's relevant it happens on one single thread. *cough* https://lualanes.github.io/lanes/ Mike
  15. I'm not coconut, nevertheless for reference: The Server we're using for The Flying Ass Clowns has been rented at Hetzner (https://www.hetzner.com), it's an i7-4770 with 32GB RAM, 2x2TB Enterprise HDD in RAID 1, with 1GB/s connection clocked at 20TB/month transfer volume. As mentioned by coconut, most hosting providers don't include the Windows Server License per default (they do for virtual systems, but not for dedicated ones), so that comes on top of it. Mike
  16. No worries @Jade_Monkey, take all the time you need - I'm glad to wait for quality products like this Mike
  17. From a Server Operator's point of view let me add that currently the "lots of AI" we can handle on a reasonably well powered dedicated server (speaking of around 2200-2500 single thread passmark points here) is not even remotely in the range of "64" as stated above or anywhere along the numbers IL-2 1946 could handle. With a dozen active AI ground units, 8 AI fighters and 4 AI bombers, the BoS DServer is living on it's edge. Let me further add that it's not just AI planes that matter. The order of impact on the CPU for a dedicated server is like this: AI bombers AI fighters Trains Other AI Vehicles (Tanks, cars etc.) Human Player planes Human Player tanks AAA Other stuff (smoke effects, flares, things like Complex Triggers, Check Zones etc...) The first half of that list matters to an extent where you really have to think twice about each and every such object you want to put on a map/mission. I'd really be happy if something could be done about that, whatever it is. From the Patch 3.005c release notes I understand that some multiplayer performance related changes are to be evaluated by beta testers. Let's hope that they really found some significant improvements there and that it's working well without breaking too many other things. Mike
  18. If tanks were a known issue before 3.005c (I never saw any dev statement telling so) I'd be wondering why they let us struggle with such issues for so long now. Removing all tanks from any mission definitely is no feasible workaround. It breaks mission logic and for certain servers it would completely kill the objectives. I could deal with temporarily removing player driveable tanks, but that seems unrelated. Mike
  19. Thanks a lot Kadin, so that's the reason - or at least one of - for the doubles. Now we still have the singles and quadruples Crashes related to tanks... interesting theory. Let's see what we have at The Flying Ass Clowns. First off, we've had two crashes last night: Aug 04 7:33 PM - uptime 42:48 hours Aug 04 10:06 PM - uptime 2:33 hours ...lo and behold, the 7:33 PM crash was the first Winter map crash (the other one was Autumn again) - hooray, celebrate! Let's look at the end of the logs of our missions, latest first, to see where there's something tank related in there: Aug 04 10:06 PM crash: T:575033 AType:12 ID:475136 TYPE:SPAD 13.C1 COUNTRY:101 NAME:Spad XIII PID:-1 POS(105215.391,111.877,87116.656) T:575033 AType:12 ID:774144 TYPE:BotPilot_Spad13 COUNTRY:101 NAME:BotPilot_Spad13 PID:475136 POS(105215.227,111.699,87116.500) T:575033 AType:4 PLID:475136 PID:774144 BUL:400 SH:0 BOMB:0 RCT:0 (105215.391,111.877,87116.656) T:575041 AType:13 AID:594944 COUNTRY:101 ENABLED:1 BC(0,3,2) Tank related: NO Aug 04 7:33 PM crash: T:454561 AType:13 AID:592896 COUNTRY:201 ENABLED:1 BC(0,0,0) T:454590 AType:12 ID:775184 TYPE:KV-1s ChTZ(1943) COUNTRY:101 NAME:KV1 PID:-1 POS(96445.977,91.896,82386.672) T:454590 AType:12 ID:515088 TYPE:BotDriver_KV1 COUNTRY:101 NAME:BotDriver_KV1 PID:775184 POS(96443.938,92.696,82386.453) T:454590 AType:10 PLID:775184 PID:515088 BUL:0 SH:0 BOMB:0 RCT:0 (96445.977,91.921,82386.672) IDS:a4a28a30-5b9e-409a-9d95-2a492ea685b9 LOGIN:1fbb56cd-3fb7-4e6e-809a-7a1cd292a1ba NAME:ST_Malesan TYPE:KV-1s ChTZ(1943) COUNTRY:101 FORM:0 FIELD:0 INAIR:1 PARENT:-1 ISPL:1 ISTSTART:1 PAYLOAD:0 FUEL:0.000 SKIN: WM:0 Tank related: YES (last lines refer to KV-1) Aug 03 12:55 AM crash: T:576955 AType:4 PLID:819200 PID:442368 BUL:2800 SH:0 BOMB:0 RCT:0 (95433.320,1528.296,76588.047) T:576955 AType:12 ID:763904 TYPE:Spitfire Mk.IXe COUNTRY:101 NAME:Spitfire IXe PID:-1 POS(104654.344,112.283,86329.820) T:576955 AType:12 ID:909312 TYPE:BotPilot_Spit9 COUNTRY:101 NAME:BotPilot_Spit9 PID:763904 POS(104653.039,111.927,86329.813) T:576955 AType:4 PLID:763904 PID:909312 BUL:740 SH:0 BOMB:0 RCT:0 (104654.344,112.283,86329.820) Tank related: NO Aug 01 9:31 PM crash: T:576921 AType:16 BOTID:750616 POS(105357.570,111.196,86546.289) T:576923 AType:16 BOTID:842775 POS(94459.359,160.379,75066.406) T:576924 AType:4 PLID:654361 PID:800793 BUL:0 SH:0 BOMB:0 RCT:0 (0.000,0.000,0.000) T:576929 AType:16 BOTID:800793 POS(94436.992,164.530,75254.672) Tank related: YES (BOTID:800793 is T-34) Jul 31 9:14 PM crash: T:587609 AType:4 PLID:1056768 PID:696320 BUL:600 SH:0 BOMB:10 RCT:0 (82298.898,4988.423,81607.750) T:587609 AType:12 ID:539648 TYPE:Yak-1B ser.127 COUNTRY:101 NAME:Yak-1b Ser.127 PID:-1 POS(105171.023,111.900,87089.148) T:587609 AType:12 ID:781312 TYPE:BotPilot_LaGG3 COUNTRY:101 NAME:BotPilot_LaGG3 PID:539648 POS(105170.344,111.928,87088.672) T:587609 AType:4 PLID:539648 PID:781312 BUL:360 SH:0 BOMB:0 RCT:0 (105171.023,111.900,87089.148) Tank related: NO Jul 28 4:45 PM crash: T:354077 AType:16 BOTID:332825 POS(96022.430,100.515,81314.594) T:354079 AType:16 BOTID:599055 POS(94149.211,159.294,73999.406) T:354083 AType:2 DMG:1.000 AID:-1 TID:841743 POS(94147.914,158.732,73999.281) T:354085 AType:3 AID:-1 TID:841743 POS(94147.914,158.732,73999.281) Tank related: YES (BOTID:599055 is PzIII) Jul 26 10:11 PM crash: T:574334 AType:4 PLID:437248 PID:899072 BUL:1620 SH:0 BOMB:0 RCT:0 (104657.000,111.883,86435.031) T:574334 AType:12 ID:302080 TYPE:Il-2 mod.1942 COUNTRY:101 NAME:Rake PID:-1 POS(120636.000,250.088,131345.797) T:574334 AType:12 ID:701440 TYPE:BotPilot_Il2 COUNTRY:101 NAME:BotPilot_Il2 PID:302080 POS(120636.422,250.381,131346.438) T:574334 AType:4 PLID:302080 PID:701440 BUL:1580 SH:0 BOMB:4 RCT:0 (120636.000,250.088,131345.797) Tank related: NO Jul 26 10:07 PM crash: T:3673 AType:12 ID:194563 TYPE:T-34/76 STZ(1942) COUNTRY:101 NAME:T34 PID:-1 POS(96445.781,92.211,82386.648) T:3673 AType:12 ID:195587 TYPE:BotDriver_T34 COUNTRY:101 NAME:BotDriver_T34 PID:194563 POS(96444.406,92.811,82386.750) T:3673 AType:10 PLID:194563 PID:195587 BUL:0 SH:0 BOMB:0 RCT:0 (96445.781,92.266,82386.648) IDS:a2c53c09-f320-4f9e-a4d3-3e0d4a054f15 LOGIN:54010b30-950a-46b7-999d-f4b1d856f75b NAME:AeroAce TYPE:T-34/76 STZ(1942) COUNTRY:101 FORM:0 FIELD:0 INAIR:1 PARENT:-1 ISPL:1 ISTSTART:1 PAYLOAD:29 FUEL:0.000 SKIN: WM:0 T:0 AType:15 VER:17 T:4730 AType:22 PID:194563 POS(96441.094, 91.936, 82386.109) Tank related: YES (last lines refer to T-34) Jul 26 10:05 PM crash: T:645 AType:20 USERID:a54efbbc-c70c-424d-966d-6cb52fe5a1aa USERNICKID:ce80d746-efb6-4a5e-8d7a-6db98b20d45f T:1447 AType:12 ID:194562 TYPE:T-34/76 STZ(1942) COUNTRY:101 NAME:T34 PID:-1 POS(96445.781,92.206,82386.648) T:1447 AType:12 ID:195586 TYPE:BotDriver_T34 COUNTRY:101 NAME:BotDriver_T34 PID:194562 POS(96444.406,92.806,82386.750) T:1447 AType:10 PLID:194562 PID:195586 BUL:0 SH:0 BOMB:0 RCT:0 (96445.781,92.266,82386.648) IDS:a2c53c09-f320-4f9e-a4d3-3e0d4a054f15 LOGIN:54010b30-950a-46b7-999d-f4b1d856f75b NAME:AeroAce TYPE:T-34/76 STZ(1942) COUNTRY:101 FORM:0 FIELD:0 INAIR:1 PARENT:-1 ISPL:1 ISTSTART:1 PAYLOAD:0 FUEL:0.000 SKIN: WM:0 Tank related: YES (last lines refer to T-34) Jul 25 7:59 PM crash: T:574307 AType:4 PLID:408650 PID:439370 BUL:1308 SH:0 BOMB:0 RCT:0 (105492.813,194.553,85441.859) T:574307 AType:4 PLID:485451 PID:341067 BUL:0 SH:0 BOMB:0 RCT:0 (105013.508,112.059,86937.563) T:574311 AType:16 BOTID:341067 POS(105010.516,111.955,86935.781) T:574314 AType:16 BOTID:439370 POS(105509.016,199.294,85426.109) Tank related: NO Jul 25 6:48 PM crash: T:210317 AType:1 AMMO:explosion AID:1368084 TID:1393664 T:210318 AType:1 AMMO:SHELL_GER_20x82_HE AID:1368084 TID:1393664 T:210320 AType:1 AMMO:explosion AID:1368084 TID:1393664 T:210338 AType:13 AID:688128 COUNTRY:101 ENABLED:1 BC(0,11,4) Tank related: NO Jul 25 6:40 PM crash: T:15270 AType:12 ID:401417 TYPE:BotGunner_Bf110G2 COUNTRY:201 NAME:BotGunner_Bf110G2 PID:400393 POS(99066.422,92.305,51926.016) T:15270 AType:3 AID:-1 TID:401417 POS(99062.859,100.203,51919.992) T:15278 AType:16 BOTID:394249 POS(99068.742,98.440,51931.566) T:15290 AType:6 PID:393225 POS(99066.594, 99.266, 51926.984) Tank related: NO 12 crashes within 11 days since 3.005c came out, 5 of them have tank related things at the end of the logs, 7 don't. No clear picture if you ask me. Mike
  20. ...and has just been posted 11 hours ago already.
  21. I know what setting it is (ChatLogUpdateEnabled IIRC), however I didn't notice this causing any crashes as the crash frequency was the very same before I used SturmovikServerControl. Nevertheless, I'll disable that feature. Mike
  • Create New...