Jump to content


  • Content count

  • Joined

  • Last visited

About old_Sneakers

  • Rank
    Fireteam Leader

Recent Profile Visitors

843 profile views
  1. CPU Under Utilized

    I made this thread some year ago and even though MUCH has improved a LOT there still are issues. http://forums.joinsquad.com/topic/23717-cpu-performance-monitor-on-6-core-47-ghz-squad-problem-in-a-nutshell/?tab=comments#comment-257681 /edit When I say a lot I mean A LOT. Hat off to devs for the new animation system and other new sub systems.
  2. Looks like hyper threading is in!

    Use windows monitoring to log your utilization, no way you can tell what the game is doing with your cpu unless you log it for 1-3 hours.
  3. Problem is players that think vehicles in urban combat can dominate the battlefield, they cant/dont on their own. Btr/hmmv are glasscannons that are best used at long range from a concieled (sp) position supporting infantry. The anvil and Hammer. The friendly infantry flank and encircle enemy infantry that your heavy weapons Hammer to death. IF you you die repeatadly in a vehicle your not using it properly.
  4. Why play this game?

    Hopefully they don't go down this route.
  5. Combat vehicle guide ! Caution very long text !!

    Sadly have to agree with this. Best way to deal with vehicles is the way it is done in PR. You make Vehicle squads, and most often it is reserved for people who are regulars on the server and known to be "decent" in x y z vehicle. The vehicles are 20 tickets, (some less though) and often you see them get wasted without inflicting any ticketloss for the enemy. The BTR/crow HMMV for example in the right hands on the right map can rack up 30-50 kills without much effort other then tactical positioning and having situational awereness. Why people run vehicles into to tighttly packed compounds (without infantry support) and other stupidity is beyond me. Miss PR vehicle discipline.
  6. Netcoding is off ???

    Indeed. BF3 ran on 15hz during its launch and on 64 player servers with close range fighting people were dying behind cover and during trades none stop. I still have nightmares from OP Metro, and I have not touched a BF game since BF3 debacle. With that said, in BF4 the server client can run all the way up to 144hz and from what I heard DICE have basically removed the problem. Squad being a slower paced game with larger scale 144hz is probably not needed to create a coherent feeling to fire fights, but 25 is clearly too low. 50hz+ should be minimum. 144hz is 6.9ms ~7ms between ticks, add to that a ~35ms ping.
  7. Netcoding is off ???

    I have noticed the RPG issue as well, more then one time. Same situation as OP describes. Same range, and stationary target. First rpg7/m72 LAW shot dissapears, goes right through the vehicle while the second round detonates. I noticed this under V7. I have also noticed (rare) occasions of an RPG7 round sticking to a vehicle when fired at close range, expending all its "fuel" and then detonating 1-2 seconds later doing full damage. Have never observed this using the m72 LAW. I also noticed the "hitreg" generally being worse in V8 compared to V7. Tick rate changes? Lowered message rate to pool from sub systems? Some weapons such as: SVD and other 7.62 rounds have confirmed issues. SVD for example require 2x shots to the head to kill, while any 5.56 to the head will be a one shot one kill. As others have mentioned, the hit reg issues could be 100% caused by server tick rates, same as problems in battlefield 3 before they raised that in BF4. I often notice you need 2 bursts to kill people even if the first burst have "multiple" blood splatter indicating more then one hit connecting. This is very noticeable when you use the PPsh gun for example. It has such a high rate of fire that you can empty half the magazine before people actually die. I have also been in situations were i shot people from behind but they seem to take 0 dmg, then they turn around and "1 shot" you. I have also noticed odd behaviour using .50 cal BMG / 12.7mm kornet HMGs on infantry FROM CLOSE RANGE <30 meters . Often you need more then one hit to drop people EVEN though in V7 one hit would be an instant kill, maybe it has been changed or also related to netcode/hitreg issues? Generally speaking, I found less situations were hit reg was an issue under V7 compared to V8. Under V7 it was extremely rare for me. With that said, I rather have ~40 more FPS in V8 + hit reg issues then 40 less FPS in V7 and almost no hit reg issues.
  8. Hmm if u make a parallel animation system with fewer variables u could turn down message rates in theory and reduce draw calls. But i think it would induce a sense of lag since the draw call reduction would come from reduced message rates to sub systems? For everyone else on the server using the regular animation system it would look like the amd users were lagging since they pool with fewer ticks. If u keep message rate to sub system the same then the effect on amd sys would be local only and give no drawcalls benefits since client server messaging would be the same. Dice tried this (kind of) in bf3 using prediction algorithms. This resulted in "dead behind corner" and "killed behind cover" when the algorithm failed to predict actual player client position.
  9. For these tests it is better to deactivate the physical cores and have HT turned off. You do not want OS logic to become an unnecessarily large variable in this test. Turn off 3 cores and observe cpu utilization behavior with windows monitor logging. The fps isnt interesting whats interesting is how the cpu is being used by the app under certain conditions. For example a cpu with 100 Gflop but with 1.5× ipc at same clock will out perform a cpu with 300 Gflop with 1.0x ipc. This is a problem in squad at the moment. The scalability of hardware is focused on one thing, brute force single thread. As dev pointed out this could be something the UE devs will solve on their own.
  10. It is a dilemma for sure. Scalability to me is synonymous to writing it heavily threaded. But there is no reason to manhandle the engine into doing things the UE devs themselves will make native further down the line. The obvious problem i see is in 2-3 patches down the line, especially when small arms ballistics with penetration are being introduced we will see exponential growth in draw calls and be back at v7 situation again. You can write pop music songs that sound good in the car and with ear plugs, or you can write a concerto that scales all the way from the ear plug device down to Albert Hall. ABBA vs Mozart.
  11. Gonna run another 72p server test when I get home and log the cpu usage and post new SS. I suspect that nothing has changed in the way the engine handles threads though and that the gains come purly from optimization in draw calls to the cpu. Less overhead achieved with c++ code for netcode, animation and positioning. This helps all cpus but is no magic fix for AMD cpus, IF what I suspect is true. /edit 1.5 hour run of SQUAD V8 on 72p server. This SS shows the "all cores average", I can break it down into individual cores as the OP but it shows quite identical core utilization to V7. Quiet safe to say that ALL performance increases we seen so far, which are IMPRESSIVE (applaud the devs on it really I do!) came from c++ code optimizations in animation and netcode. Cleaner code that runs more efficient with less draw calls and overhead. I am not seeing the added parallelism though, even though I am sure it is there for the sub systems. Still this puts AMD CPUs in a bad spot since they lack the brute force IPC of Intel cpus to carry it on one core. /edit2 The dip in the graph is loading a new map.
  12. September 2016 Monthly Recap

    Can't wait for the V8 performance update!
  13. V8 will be a big tell if the devs have the technical know-how within the team to salvage this. It took DICE several years to add the needed parallelism to Frostbite+its shitty netcode to unlock that engine fully.
  14. How will this run on my laptop?

    Given that the 5820K has a lower IPC and lower stock clocks then the 6700K in your lappie. The Laptop will run the game in this alpha stage noticeably better, given same clock. You should see 60 frames on >54-64 man servers most of the time. 72 man server I hear people with highly OCed 6700ks (4.8 ghz) have drops to 40s often. The GPU will not be a bottleneck for this game (at the moment) unless UHD resolution with added AA from injector.
  15. Feels like you are defending the utter lack-luster state the game is in so far, performance-wise. As I hinted before, they are gonna need a magic bullet to get their modified engine to run on more then one leg (run..I mean skipping along like a gimp). Squad is not only single core heavy mate, it basically runs on one single core alone, literally. As you say it might be out of alpha stage and into a gold state in 2017 and it cannot be running like a dog in a wheelchair by that time. Having the engine "basically" run on a single core like this is unacceptable for a 100 player fps with 10 km square maps packed with players, individual ballistic calcs, helis, physics, animations, sophisticated net code and so on. This will never work. No machine will be strong enough to handle this without more parallellism. Talking about IPC as if the difference is 200% going from Westmere to Skylake is ridiculous. The truth is closer to 40-45% which I admit is significant in a single threaded application but its not a wide enough gap once parallellism is brought into the picture to make one "ancient" in comparison to the other. Bottom line is we need more parallellism in the code for this game to go anywhere. In this state no cpu will be strong enough to carry this mess on a single core. 144 hz screens 120 hz screens You might as well go back and get your old 60 hz tft from 2002, because you won't see no 60+ fps ever.