Closed MatinF closed 1 year ago
MatinF
commented
3 years ago Also, it looks like the playback is attempted at a higher rate than the original file. In our case, the original file was approx 1000 frames/second, yet the playback claims ~14000 frames/second - not sure if the 'original frame timing' is simply a bit bugged in the current version.
collin80
commented
3 years ago The lack of stopping is certainly a bug.
As for the number of frames sent, I hope you mean 1400 fps not 14000! That would be a lot of frames! If it's 1400 that's still not ideal but there could be at least a partial explanation. Multi-tasking operating systems don't really like to have tons of interrupts happening or super fast timers. To make matters worse, I try to keep it cross platform so I can't simply reach out to OS specific functions (well, we can do this but it'd have to be done for each and every OS and maintained as the OS vendors change things).
So, generally all I can do is ask it to schedule my task as rapidly as possible while checking how many milliseconds have passed. Then I send out any frames that should have been sent in the interval that has passed. For instance, if the OS schedules the task 2ms after the last time then the code will try to send messages until the timestamp has moved ahead 2ms. Each time the previously sent message is remembered so that in theory it sends starting at the next message from there and only when enough time has passed. There could be some bugs in this code and if your messages are not in timestamp order it's going to do really odd things. But, generally I've found that it's "pretty close" to sending around the nominal rate of the original traffic.
I'm certainly not saying there isn't room for improvement in timing. And, if anyone knows of a more robust way of keeping track of timing and scheduling in a cross platform way I'm all ears. I think currently it wastes a lot of CPU cycles in checking the time very rapidly to try to emulate the original timing. This isn't such a big deal on modern multi-core computers though, I suppose. I have a 12 core machine so even if the frame sender ties up a thread constantly it can't use more than 8% of my CPU time. This would be more problematic on a 2 core machine or perhaps on something like a Raspberry Pi - which people do run SavvyCAN on.
collin80
commented
3 years ago I just tested the playback window with the virtual loopback driver and both stop and pause work even while checking "use original frame timing". Additionally, the original file I loaded took 47.34 seconds. Sending with original timing checked resulted in 47.364 seconds. So, I'd say it was pretty accurate as far as the total timing. I suspect that the CAN driver you used might have caused an issue or the frames per second is getting reported oddly. For me it seems to be functioning properly.
I'm using Ubuntu 21.04 running on a 6 core (12 thread) i7 processor. Processor load is extremely small when running the test so I don't think the CPU is relevant. But, running linux might be.
MatinF
commented
3 years ago I was testing this on a Windows 10 64 bit machine, maybe there's a difference due to the system. I am quite certain it showed 14K fps, though I agree that that's probably not what was happening in reality :-) But not sure if it's something that's possible to diagnose on your end if it's a Windows/Linux difference
Tested as follows:
When doing the above steps, the 'stop' button has no effect - meaning the playback simply continues. In contrast, if using e.g. the 5 ms frequency, the start/stop seems to work as intended.