Jump to content

Nadar

Members
  • Posts

    49
  • Joined

  • Days Won

    1

Nadar last won the day on May 4 2015

Nadar had the most liked content!

Reputation

12 Good
  1. I have the H100iGTX and sent you a USBPcap trace (Wireshark compatible). The problem was that it captured everything on the root hub in question, including mouse and keyboard events, so some filterint was needed. There's not a lot of possibilities for capturing USB via software on Windows as far as I can see, if you like me to try something else just name it. AIDA64 is payware only offering "trials" which is probably full of nagware and other nasties. I'd rather not install that.
  2. The USB trace I sent you earlier was useless? I can do another, but I simply don't know how to get a usable trace with a software capturer.
  3. I'm not interested in discussing this, never have been, I just tried to explain why badly written software, like CL, can and very likely will have a performance impact even on relatively powerful computers. The netcode discussion was completely irrelevant here, and I admit that I should have refrained from commenting on that.
  4. It's hard to prove a negative. I'll try to explain once more: While core parking is a real issue, especially with the AMD Bulldozer architecture, many in the gaming community seems to think this is the sole cause of the type of lag called stuttering. This is what I consider the "myth" part. The fact is that the stuttering can be cause by a whole ray of different things related to the game machine resources. Lag can be divided into two main "branches", one originating from high network or server latency and one originating from insufficient computer resources (e.g CPU, GPU, RAM, motherboard bus transfer rate). While core parking CAN cause such issues on some platforms, it's unlikely to be the cause except from on the AMD Bulldozer architecture where Windows' CPU scheduler has a bug. This bug can be fixed by installing hotfix kb2646060. Core parking is otherwise unlikely to cause issues because it by design only parks cores when the CPU is under light load conditions, which is not typical of a gaming situation. You can read more about it here. When it comes to your assuption about the games using only two cores, you're wrong (that is, it's over simplified). The games, or any software, does not "use" cores. The software simply asks Windows for CPU time, and the Windows CPU scheduler assigns CPU time from whatever core it sees fit. The problem is that each thread runs in it's own memory scope which can't easily be switched between cores. To use multiple cores effectivly the software therefore has to be written in such a way that the CPU load is effectively distributed over several threads. From the programmers perspective it's easier just to let everything, or atleast, all the heavy computing, happen in one thread, since you don't have to deal with semaphores and shared memory. So, to say that a badly written software just uses one core can be true, but when it comes to how multiple threads use multiple cores that's entirely up to Windows. As pointed out before, stuttering is just one "type" of lag. I'm not saying that the symptoms attributed to "bad net code" is a myth, the myth is that it's somehow caused by Dice's inability to write a bug free "net code". As stated above, the issues are BY DESIGN in the sense that when you combine client side hit detection with predicion algorithms and the factors in latency (both client, network and server), you WILL see such issues. There's nothing Dice can do to "fix" that other than to redesign the whole system, all they can do is try to fine-tune the experience (as is what they do by introducing e.g the smoothing factor or increase server tick rates). Increasing server tick rates reduces server latency, so it will lessen the symptoms some, depending on how big part of the total latency comes from the server. Adjusting the "network smoothing" is simply a way to adjust how much prediction the client will do -the setting has been there the whole time, Dice just exposed it to the users to let them tweak it themselves. This whole mess started back in BF2 when they started the whole "prediction" mess. The funny thing for those of us remembering before that, the whining about the net code was just as bad before they did that, but the symptoms were different. Back then you had to lead the shots more, to compensate for latency, and high pingers would suffer badly. It also meant that snipers wouldn't always get a kill even though they had the enemy in the crosshairs, simply because what they say was somewhat outdated information. To remedy this, client hit detection and prediction was introduced, leading to all kinds of strange behaviour since the client both predicts where something is about to move AND deciding if it's a hit, meaning that you can be killed for being somewhere you never has been. In short, I agree that Dice got it wrong, I just disagree that the problem is "badly written net code". The problem is listening to whining snipers that don't always get their kills and then ruining the game for everyone else. It's "by design". As explained above, it's a bit more complicated that that. Badly written software, like CL, often doesn't respect the CPU scheduler and hands back it's CPU shares when they are not needed (but spends them looping for example). That leads to the scheduler thinking the software needs more CPU shares, and diverts more resources to this software - which it ofcourse again just wastes on some waiting loop. This will lead to one or more cores (depending on threading, my guess is that CL is not threaded) reaching 100% utilization which is really just wasted doing nothing. This means any threads unlucky enough to live on the same core, will be severely starved for resources. Because of semaphores, other threads in the same application will often end up waiting for the threads starved for CPU to release their locks, and everything slows down a lot. Simply looking at total CPU utilization is too simple, for that number to give meaning you have to assume that all software respects the scheduler and only uses the shares it needs. Therefore it's very possible for CL to severly slow down a computer even though there seems to be available CPU resources. I see the same happening on my computers running CL all the time, the whole system becomes slow and closing (not minimizing) CL is what resolves the issue.
  5. This is going even further off topic... You can't simply state that I'm incorrect, you can state that you think I'm incorrect. There's no absolute proof available here. I'm aware of the core parking feature, and I explained why I think it's very unlikely to cause issues. There are so many names for different kind of lag, I consider "lag" to be the umbrella concept for them all. It seems to me that you think lag only applies to network induced lag, but that's certainly not the way it's been used traditionally. "The netcode" argument is another one of those urban myths as I see it. The behaviour is by design, it's all due to client hit detection and lag compensation - the result of which gives what many that doesn't understand how it works and only see the symptoms call "bad netcode". Any btw, 600 hours is just BF4. In Battlefield in total I have several thousand hours.
  6. I have over 600 hours of play time in BF4 and have heard the "core parking" claim many times. I've yet to spot any difference whatsoever, and considers this more of an urban myth than a real issue. It's to me very unrealistic that Windows would, even if it could, park cores while they were in use. That aside, CL's high CPU and RAM usage could easily create lag conditions on a not too powerful computer. That CL has memory leaks is simply a fact, I've established that a long time ago. Just let it run, and it eventually will crash. I think the longest I've had it run in one go is somewhere around 48 hours. Another thing is that such a small program, with so few tasks should only use a very few CPU cycles once in a while to check on things if it were made correcly. It shouldn't be able to reach 1% on all but the very weakest CPU's imo. What strikes me is that, as far as I could read, nowhere in the linked thread did it say that disabling core parking solved the problem. Still yet, you concluded that this was the problem, despide CL using resources like a mad bat out of hell. This discussion is so off topic to this thread that it constitutes spam. Is there are point to your argument except that we are stupid for wanting the USB protocol spesification?
  7. I'm sorry, but I think it's you who don't understand. Corsair sells us hardware that depends on "free" software to use. The software isn't really free, but you pay for it when you pay for the hardware. This software doesn't work properly, and hasn't done so in years. They show no interest or capability to solve the issues (it's hard to tell which it is). We who bought the hardware are stuck with a product we can't use, so we ask for a desciption of how to communicate with the hardware we have bought to compensate for the fact that the broken software renders the hardware useless. I struggle to see how that has anything to do with not having a sense of business. To me, as a customer, it's of no interest whatsoever how Corsair made the software, it's a part of a product I bought and it doesn't work. What deals and agreements they would have made is completely irrelevant for me, I only have an agreement with Corsair (by purchasing products from them). If Corsair lacked the knowledge to produce the software themselves, they should hire someone to make it for them. It's obvious to me that such an agreement would give Corsair all IP rights to the software, anything else would be a grave error on Corsairs part. On top of this, we're not asking for the source code for the CL software, but simply how to communicate with the hardware. To have signed a deal that makes that a secret, would seem to me to be extremely short sighted. When you combine this with the fact that the software hasn't been fixed within anything resembling a reasonable time frame, I see only two possible solutions: Corsair renegotiates the deal and secure the necessary rights, or they recall all the products. To me it's that simple.
  8. I just lie as I always do when someone tries to force information from me that's none of their business, I just dislike being put through that. A onetime email address is probably also the smart thing here, as this seems like a company that will spam you forever. That aside, I'm still confused about their terms of evaluation/trial and the different versions. It seems to me like the only free option is a limited version called "evaluation" for the eclipse version "special" for the classic IDE. Just to warn anyone that want to go down this path, I tried to install the "classic IDE" version, and it failed to install on a 64 bit system. Hopefully the Eclipse version will work on modern OS'es.
  9. I looked at the IDE download mostly out of curiousity (I'm not going to teach myself assembly for this). I haven't actually tried to install it, but it doesn't look very free to me. The only download available is the professional evaluation - which gives me until June 10. - after giving a ridiculous amount of information during registration. Is it license.dat from the page you linked to that makes it a free version, or is "free" simply the name (from freescale)?
  10. I doubt they will ever release anything tbh. - but I have a H100i GTX (that CL doesn't manage to "read" properly either), so I could do capture/testing if anyone need that.
  11. Since you won't rephrase, I'll just have to guess.. first you're probably trying to insult someone by saying that whoever being the "software hacker" you're referring to isn't experienced enough. First I wonder "experienced enough" by who's standards? Is there suddenly a hacking competition here? Second, you're wrong - CFSworks was the one that interpreted the protocol for the H100i. I was the one that commented that Corsair should share the full protocol. The reason for this is simply that it's so much simpler to make a software where you know the full protocol and doesn't have to guess and make trials and errors. It also reduces the chance of possibly damaging some of the hardware, even though that is probably pretty low risk anyway. It's also much more logical to get that information from the source with a complete description that covers all hardware, instead of someone having to buy all supported hardware to figure it all out. I also can't see any reason for Corsair not to do this, they sell the hardware, which we have paid for, and "give away" the software, so it's not like having some alternative software would hurt their sales. Quite the opposite. The to the really cryptic bit: ".theres tons of software programs that allow one to code as they like". Here I have no clue what you mean, are you referring to all the different development softwares out there, or what exactly are you trying to say? The only thing I can answer is that it doesn't matter in what language/compiler or IDE/editor you use, you have to know what to tell the Corsair Link hardware to achieve what you want. This isn't about using someone else's code, but to have a protocol description (that is, a document that describes commands/replies to the hardware). Alternatively we'd have to develop our own hardware, and what would be the point of buying the Corsair Link devices then? About "the norm is to use someones elses hard work for their benefit." again I don't know who's norms you are referring to, but this is completely beside the point in this discussion. To repeat myself, I really don't care about the source code for the existing software. I only want to know how to correctly, completely and safely communicate with the hardware. Btw., who's benefit are you talking about? We, the customers', benefit by being able to use the hardware we've bought? Or do you suggest that someone would want to make an alternative software to the free Corsair Link software and then sell that for money? If so, I'd just like to wish them good luck with wasting their time... I seriously don't think you understand the different concepts here.
  12. What are you trying to say? What you just wrote makes no sense to me..
  13. You didn't understand much of what I said, did you? I'm not talking about the software, but the protocol to communicate with the hardware called Corsair Link the we have bought and can't use. Btw, if your son runs this software on Linux he's either a great magician or he's using some emulation software like Wine or a virtualisation software with a Windows VM like I am.
  14. I'm not exactly glued to this forum, so I might have missed those replies - but the last time I read about it there were some excuses about being able to disclose other companies propretary protocols, and that they would do their best to be able to share or something like that. I'm sorry, but that just isn't a proper answer to me. I'm only asking about the Corsair Link protocol, to communicate with the "commander". I don't need access to the source code for the current Corsair Link software, which reads all kind of proprietary hardware device information. To be honest, I'd much rather code something simple and working, then trying to "fix" the software as it is today. All I would be interested in is something taking a minimum of resources, stable that would do it's job without a over-designed, resource hogging, crashing GUI. Personally I wouldn't even care about the LED part, I just want a programmable, reliable fan controller - which is what I thought I bought. I just want a chance to use the hardware I've bought. I don't actually care that much that the software is crap, if we could only have the choice to make our own. I honestly don't think that's asking to much. *edited the confusing typo above
  15. Great job. It's really sad that Corsair choose not to share this information with us, given that the available software is Windows only and full of bugs and misdesign. It's really about time to release this protocol Corsair, so we can use the hardware we've bought.
×
×
  • Create New...