FlyNet Client uses a lot CPU

DanKH · Post by **DanKH** » Thu Nov 23, 2006 1:13 pm

Hi

Just saw in my process-explorer that the FlyNet Client (in idle condition) uses up till 50% processor time !
That seems to be a lot to me, a bit optimisation might be in order?

Even FS is only demanding round 10% when idle...

Post by **joefremont** » Thu Nov 23, 2006 7:06 pm

I have noticed this also, on single core machines it can use as much as 90% of cpu when FS is minimised. I would think putting a 0.1 second sleep into the clients main loop would do the trick.

FsNovice · Post by **FsNovice** » Thu Nov 23, 2006 8:36 pm

I beg to differ. When i check in normal flight with flynet running. Flynet uses 3,000k of mem and FS uses 170,000 K

I wouldn't call that half, though that may just be my machine?

BFuller · Post by **BFuller** » Thu Nov 23, 2006 8:38 pm

CPU and Memory is two different things.

FsNovice · Post by **FsNovice** » Thu Nov 23, 2006 8:59 pm

Ever so sorry i appologise.

DanKH · Post by **DanKH** » Fri Nov 24, 2006 12:13 am

A 0.1 sec delay in a loop could do something, agreed, but I bet a more thorough optimization would be in order.....

I know this is being called a "beta" though I think that term is a bit devaluated in this situation.... but there are many ways in programming to achieve the same result...50% CPU is A LOT for a small client to use......not one of my other programs uses that much CPU....and available CPU-power is also of essence in FS....

The FlyNET concept is great, really, and I enjoy every minute I'm flying FlyNET (which is every time nowadays)

But robbing off CPU-power doesn't add to the pleasure, especially in a program like FS which we all have our time tweaking to get that one or two extra FPS....

DanKH · Post by **DanKH** » Tue Nov 28, 2006 1:39 pm

One of my colleague over at CBFS-VA nailed the bugger

It is the tracer that is responsible for the high CPU-load, once you disable it, the activity drops down to acceptable levels.

Konny would prefer that we enable tracing...but there is a cost, just so you know it.....

After you have repaired the auto-update, and the numerous other errors in the latest version of the client, you might take a peek into the tracing functionality.

And a small sigh: Pleeeease test the client thoroughly BEFORE you release it.......instead of letting all your users getting frustrated over simple coding errors...

Don't get me wrong here, I am a true believer of this idea, and I think it is a great job you've done. Take these points as advice, not bad critique.

CAPFlyer · Post by **CAPFlyer** » Tue Nov 28, 2006 4:13 pm

Dan, we're the BETA team. We're supposed to be testing it. You're doing exactly what you're supposed to be. That's why it says all over the place that this is public beta.

Post by **cmdrnmartin** » Tue Nov 28, 2006 5:09 pm

DanKH wrote:One of my colleague over at CBFS-VA nailed the bugger
It is the tracer that is responsible for the high CPU-load, once you disable it, the activity drops down to acceptable levels.
Konny would prefer that we enable tracing...but there is a cost, just so you know it.....
After you have repaired the auto-update, and the numerous other errors in the latest version of the client, you might take a peek into the tracing functionality.
And a small sigh: Pleeeease test the client thoroughly BEFORE you release it.......instead of letting all your users getting frustrated over simple coding errors...
Don't get me wrong here, I am a true believer of this idea, and I think it is a great job you've done. Take these points as advice, not bad critique.

Being saying for a long time the tracer causes problems (Look at threads from December of last year). I know Konny is working hard to fix it, reduce the load, since flight tracking is a cool and much wanted feture.

As to the rest of your post, Cappy nailed it. We are a beta. We expect to find bugs, as we push the software to its limits. It's important to give Konny and Dakurt feedback, so they can eliminate the bugs.

tallmike · Post by **tallmike** » Tue Nov 28, 2006 6:08 pm

Im assuming the flight tracker allows your flight to be listed on the flight monitor......is this correct?

Mike.

Post by **cmdrnmartin** » Tue Nov 28, 2006 6:11 pm

Yep, Mike, that's exactly what it does.

It caused crashes on my system, so I disabled the tracker a while ago. If it is related to the CPU cycles its eating, then I think we're making it much simpler for Konny to fix the issue.

DanKH · Post by **DanKH** » Tue Nov 28, 2006 8:01 pm

CAPFlyer wrote:Dan, we're the BETA team. We're supposed to be testing it. You're doing exactly what you're supposed to be. That's why it says all over the place that this is public beta.

Hmm quite a big team of "beta" testers......

recce · Post by **recce** » Tue Nov 28, 2006 8:30 pm

The more beta testers you have the more likely you are to find more issues that would not have previously been discovered. Therefore it's a good thing. Just means that Konny and DaKurt are usually VERY busy.

DanKH · Post by **DanKH** » Tue Nov 28, 2006 8:50 pm

Sorry all, but I simply don't agree with you on the meaning of a Beta.

I've been in the software development branch for approx 10 years now. And my understanding of whats is beta and was released to soon, seems to differ from yours.

But that's quite alright, we're all entitled to have each our own opinion.

The reason I kind of burst out like this, is that I think this concept is so good, and these in my eyes unnecessary errors tend to spoil the pleasure of using the system.

A thing like the auto-update function could easily be tested before releasing it to what I would call public / production, I think the reduction of an aircraft's value to 0 should also have been caught rather quick if one had tested the code just a little bit more.

I'm sorry, but the way this situation has evolved, it LOOKs to me that there has only been a minimum test if any at all other that the file could compile. I looks like the attitude have been a release based on trial and error, and a "well lets just see how it works", "After all it is just a Beta". I do not think it is fair for the users of this system, and it is certainly not a thing that glorifies the project.

I will say it again; don't get me wrong it is supposed to be a positive critique, and hopefully some thing that could inspire in doing things a bit more thorough. That is the way I respect and appreciate.

And please don't insult me with comments like "You're doing exactly what you're suppose to be" I'm not supposed to do anything. But what I do want is to point out some lacking procedures.

I can understand that this is a free-time project and I have the utmost appreciation an admiration for it, but if you like go the whole way, some simple game-rules has to be taken into consideration before anything is thrown into production.

Well guess that's about it

Keep up the good work, And I sincerely hope that you will nail these bugs.

Happy coding.

CAPFlyer · Post by **CAPFlyer** » Wed Nov 29, 2006 1:54 am

Dan, I've been involved with multiple beta teams over the years, both paid and unpaid, and there are three basic kinds - closed, open, and public. A closed test is what you usually see in commercial development where a select number of people do the testing, usually by invitation. An open test is one where the beta's existence is known and most anyone can get in but the total number is limited. One good example of an open test is AOL's "AOLBeta". They only allow a portion of their paying members to join the team, but they are "open" about its existance. A public test is like what FlyNET is doing. They put the program up on a public website open to anyone without condition or qualification and anyone who wants to test can test.

Now, within that you have different types of betas, but this one is more of a "general" beta here where you do a bit of everything, execution, implimentation, and quality testing. Dan, I think you came in expecting a bit more than reality. It's publically posted that this is a beta and beta means that you're going to get problem releases, but by-and-large, these releases have been pretty stable and most of the bugs only show up on some systems and others are relatively minor and are pretty easy to fix (which is what happened today with the release of the 6.2b client).