MainFramesWindow slows down when run Send Frames fuzzing
Hi. I have an issue with the MainFrameWindows(object name canFrameView). When I have connected GVRET on serial connection and use send frames Fuzzing, set ID Scanning: Seqential and IDs Start 0x000 to End 0x7FF. When start fuzzing I have avg 50-80 frames per second but when sent more than 600-700 frames MainFrameWindows very slow down to 5-15 frames per second. If I cleared frames, the speed send frames back to 50-80. I check the performance of my pc but use CPU and RAM is under 50%. Maybe the issue is in settings but I think the problem is in the buffer this MainFrameWindows. Does someone know how to solve this problem?
I noticed that when I disable auto scroll main frame, frame per second slow down only for a few seconds and back to 50-80 frames per second.
My first guess is that your 50% CPU figure might be deceptive. On a multi-core CPU you will get lies like this. If you have 4 cores/threads and two are pegged out at 100% used it will tell you that your CPU usage is 50%. That's sort of true but can lead you to thinking that things should be working differently than they are. SavvyCAN is likely to only use about 1-2 threads normally. The nature of the fuzzer is that it has to hook a timer and fire timer ticks very rapidly so it knows when to send your fuzzing traffic. Oddly enough, this can be way more processor intensive than you would expect, even on a modern multi-core machine. Adding the two together, it is possible that this combination of things ends up being too much and the tasks get delayed.
So, I think a good first step is to please list your CPU specs (# of cores, speed, model). Also, which operating system version are you using? Windows, MacOS, Linux? Which version?
But, come to think of it, I'm not sure I've ever tried to rapidly fuzz while also capturing. 700 frames per second incoming isn't that fast nor is 80 frames per second sending. So, I would not expect it to get this bogged down.
I tested on two notebooks and one PC. First Acer have i7-7500U(2.7GHz, 2 cores, 4 threads), 8GB RAM with Windows 10 x64. Second Dell i7-6700HQ(2.6GHz 4 cores, 8 threads), 16GB RAM with Windows 10 x64. PC i7-9700K(3.6Ghz 8 cores, 8 threads), 48GB RAM with Windows 10 x64. All of them avg 20-50 percent use when starting fuzzing. I noticed the app slow down when sending frames between 700-3500 frames. After 3500 frames speed back to 80-90 frames per second only when I disable auto scroll. Maybe you can add an optional button to disable Tx frames view and when the app receives Rx stop fuzzing? Thanks for the answer.
I just tried this out. I used an ESP32 running ESP32RET and I installed loopback wires between two CAN buses on the same board. I then set up fuzzing from id 1 to 1024 and set the main screen to auto scroll. I was able to get up to around 2000 frames per second without any drastic slow downs. The machines you're using are plenty recent and fast enough so I wouldn't expect that to be any issue at all. Unfortunately it seems to work OK for me so I'm as of yet unable to pinpoint the cause for you. Though, I am running Linux. I will have to try Windows when I get a chance and see if that changes things. I know the way high speed timers work is different between Windows and Linux so maybe there's a chance this interferes. No resolution so far but I did look into it. I'll keep it in mind and try to get to the bottom of it. But, I don't have any real advise yet except to not use auto scroll until this can be solved.
Ok, I understand but can you add an optional button in fuzzing to disable frames Tx in MainWindowView and add a function automatic stop send frames when received Rx during sending to electronic, in the next commit? I have a question SavvyCAN will work on ESP32 ESP-WROOM-32 with two-channel CAN? I ask because I want to test on this ESP WROOM, now I use Arduino Due.