| 12 Feb 2025 |
motiejus | Can you elaborate? | 09:07:19 |
K900 | We have debuginfo for most hot path packages | 10:00:19 |
K900 | And you can use that with perf to get proper unwinding without frame pointers | 10:00:33 |
K900 | (at the cost of some post-processing time) | 10:00:41 |
motiejus | Great! I see Python is in the list that has separate debuginfo pkgs; I'll poke around. | 15:56:01 |
motiejus | back to my argument: although the same can be achieved with dbginfo for select packages and is hugely helpful for gdb, but in profiling use case, we don't need to bear the cost of separate dbginfo -- the size and binary is almost the same with frame pointers. :) | 15:56:58 |
motiejus | * back to the original argument about frame pointers: although the same can be achieved with dbginfo for select packages and is hugely helpful for gdb, but in profiling use case, we don't need to bear the cost of separate dbginfo -- the size and binary is almost the same with frame pointers. :) | 16:01:15 |
motiejus | * back to the original argument about frame pointers: yes, the same can be achieved with dbginfo for select packages and is hugely helpful for gdb. However, in profiling use case, we don't need to bear the cost of separate dbginfo -- the size and binary is almost the same with frame pointers. :)e | 16:01:33 |
motiejus | * back to the original argument about frame pointers: yes, the same can be achieved with dbginfo for select packages and is hugely helpful for gdb. However, in profiling use case, we don't need to bear the cost of separate dbginfo -- the size and binary is almost the same with frame pointers. :) | 16:01:39 |
motiejus | e.g. in my case, this flag is not available on OpenMP, of which I'd like to have stack frames of in the flamegraph | 16:03:22 |
| Kira changed their display name from kira to Kira. | 19:59:42 |
@hexa:lossy.network | 02:00.0 System peripheral: Global Unichip Corp. Coral Edge TPU
| 20:15:00 |
@hexa:lossy.network | [ 20.102983] apex 0000:02:00.0: Apex performance not throttled due to temperature
| 20:15:50 |
@hexa:lossy.network | oh thx | 20:15:52 |
@hexa:lossy.network | frigate[8635]: ValueError: Failed to load delegate from libedgetpu.so.1.0
| 20:52:43 |
@hexa:lossy.network | hrm | 20:52:46 |
@hexa:lossy.network | device must be pci not pcie apparently | 20:59:15 |
@hexa:lossy.network | so, it's up and not killing the n100 yet | 20:59:27 |
@hexa:lossy.network | the gpu is 10% busy with video things | 20:59:57 |
@hexa:lossy.network | * the gpu vpu is 10% busy with video things | 21:00:07 |
@hexa:lossy.network | for two cameras at 720p | 21:00:18 |
@hexa:lossy.network | ok, my config is really simple at this point | 21:22:33 |
@hexa:lossy.network | cameras:
Foo:
detect:
enabled: true
ffmpeg:
inputs:
- input_args: preset-rtsp-restream
path: rtsp://127.0.0.1:8554/g3-flex?mp4
roles:
- record
motion:
mask:
- 0,0,223,0,224,27,0,27
Bar:
detect:
enabled: false
ffmpeg:
inputs:
- input_args: preset-rtsp-restream
path: rtsp://127.0.0.1:8554/g3?mp4
roles: []
motion:
mask:
- 0,0,223,0,224,27,0,27
database:
path: /var/lib/frigate/frigate.db
detectors:
coral:
device: pci
enabled: true
type: edgetpu
ffmpeg:
hwaccel_args: preset-vaapi
mqtt:
enabled: false
host: localhost
record:
enabled: false
retain:
days: 2
mode: all
| 21:22:47 |
@hexa:lossy.network | video encode/decode using vaapi with intel quicksync video | 21:23:22 |
@hexa:lossy.network | detection with a coral edgetpu pcie device | 21:23:32 |
@hexa:lossy.network | and I don't see any process that is particular busy all the time | 21:24:11 |
@hexa:lossy.network | load15 is 0.7 | 21:24:18 |
@hexa:lossy.network | motiejus: anything in particular I should add to my setup? | 21:24:32 |
@hexa:lossy.network | I now enabled recordings | 21:32:01 |
@hexa:lossy.network | the frigate.process processes are still only consuming like 3-5%CPU | 21:33:10 |