Purple, i am unable to help you if the bench mark is continued to be discussed. Please provide a project demonstrating the issues that you are experiencing so we can help identify what is happening, or if it's even possible to be resolved with your hardware, software configuration and program.

@purple,

So basically, the benchmark tool is not a good way to measure performance right now. If you are seeing issues with performance, upload your project that you are seeing issues with so that someone can then review the project or test the project in their environment. This will allow someone to offer some suggestions on what can be done to increase performance on this project or help to identify a possible issue by allowing others to see what you are seeing.

It is now a good way to measure performance with the latest release. The default value has been lowered to a more realistic value from 300 to 30, which should not flood the data channel - unless there are a bunch of other controls running in the background. Release notes here: https://synthiam.com/Community/Questions/8758

Now, let's get back on topic and identify what purple's project is doing that is causing his computer to lock up and freeze due to apparent communication issues.

I agree totally DJ. The project has been requested multiple times from multiple people. Without it, there is nothing more that can be done.

@DJ.... thanks for the clarification, I also get what's going on now.... To be honest, I was also focused on the benchmark control. Like David, I actually haven't seen any degradation in performance in my projects... And my Windows 10 upgrade build (with sluggish computer) was just a coincidence.... I think we are all looking forward to the release of the ezb4 1/2 ....

Any time. I never saw the danger of leaving a high number in the default sample field of the benchmark utility. It's funny because since the release of the ez-b v4 last year, we internally use the benchmark utility with a default count of 300 to see how long it takes before it crashes, because it mostly does. I've only seen less than a handful of ez-b v4's not crash with the default 300 benchmark sample test.

If we put a default number in there, it's a recommended value - something i should not have over looked. The latest release lowers the number to a realistic value.

We'll get purple's project posted up here shortly and give it a good overhaul and get him back on his feet

I have always used the benchmark as a Benchmark! It has never crashed and has always been a good indicator of system speed. This used to run at 65 to 70 adc executions per second. On both v3 and v4 boards. Something has changed. I will put together a project to show you, but it will take some time. And I am sure that it will be met with the same hostility that every issue I have pointed out has been met with, even after it was discovered that there really was a problem. Every time someone on this forum points out a issue , it is always responded to with 'Lets figure out what You are doing wrong'. Everytime.

@Purple, Something has changed as DJ has stated. Others dont see the issue that you are seeing from an actual project perspective. DJ has stated that the Benchmark tool, with the changes to ARC for the new products that are coming out doesn't pause between attempts to access the Analog ports (or really any others) anymore. This is because the new product can handle faster speeds. This will flood your connection and cause issues with the current product. Because of this, what you used to do to gage performance won't work well with this board at this time. The benchmark tool is not a normal function, and thus is irrelevant to your project. If your project is showing slowness, and nobody else is having an issue with slowness, then logically speaking, your project probably has an issue. If you post it and everything looks good with it, then someone will be able to say "yea, I am having the same issue here" or "Nope, no issue here". That will help to determine where the issue is.

I dont think that anyone is saying "Lets figure out what you are doing wrong". I think that people are saying, "Unless I see what you are doing, I cant really help out". Everyone here has tried to be as helpful as possible, but until we can see what you are seeing, it is really hard to help. As stated, the Benchmark tool isnt a good method of determining what is happening because with the improvements in performance on the ARC software that have been put in place (this is a good thing), the bottleneck is now somewhere else in the chain of things that happen to make the robot work. You can see the bottleneck with the Benchmark tool, but that doesn't mean that in a real world scenario this should exist.

If you have seen this issue in the past (which nobody is doubting) then you should have an existing project that demonstrated this issue in a real world scenario. I think everyone wants to see that so that it can be determined where the issue is.