View Bug Details

IDProjectCategoryView StatusLast Update
0001621DCP-o-maticBugspublic2023-12-22 22:33
Reportercarl Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
Status acknowledgedResolutionopen 
Summary0001621: Poor performance on AMD threadripper system
Description

2.15.15

TagsNo tags attached.
Branch
Estimated weeks required
Estimated work required

Activities

carl

2019-10-08 00:13

administrator   ~0003459

A quick run of --encoder-stats suggest that the encoder threads are spending 0000064:0000060% of the time asleep.

carl

2019-10-08 00:16

administrator   ~0003460

--queue and a grep of encoder-wake suggest the queue is always very small.

carl

2019-10-09 21:58

administrator   ~0003463

I guess this might need the butler to be used for the DCP transcode so that the ::prepare()s can be done in separate threads.

carl

2019-10-11 11:59

administrator   ~0003469

Maybe we can check to see if this user can reproduce the benchmarks.

Carsten

2019-10-13 21:50

manager   ~0003473

Last edited: 2019-10-13 22:05

It's weird that we have nice benchmark results for both a Threadripper 1950 and a Xeon Gold , but then two reports of very poor performance with similar CPUs...

Maybe they should check with 2.14.x or 2.12.x?

As CPUs with many more cores become now 'standard', wondering wether it would be useful to have more logging/timing options to analyze issues?

  • Carsten

carl

2019-12-12 15:29

administrator   ~0003641

Emailed op to see if he's still having problems.

carl

2020-05-30 20:16

administrator   ~0003834

Last edited: 2020-10-09 16:21

I guess this might need the butler to be used for the DCP transcode so that the ::prepare()s can be done in separate threads.

I can't see (any more) how this would help...! The only immediate idea I have is multiple encoders, each doing a reel. Sample-aligning them is a bit scary though. Although it is a bit weird that even on 48-core VMs we are seeing under-use of encoding threads but only 30-ish fps encoding; surely one core of those machines can decode a video at >30fps? Or maybe not...

Need to check what the decoder thread is doing and make sure there's nothing that could be moved out.

Bug History

Date Modified Username Field Change
2019-10-07 23:36 carl New Bug
2019-10-07 23:37 carl Tag Attached: next
2019-10-08 00:13 carl Note Added: 0003459
2019-10-08 00:16 carl Note Added: 0003460
2019-10-09 21:58 carl Note Added: 0003463
2019-10-11 11:59 carl Note Added: 0003469
2019-10-13 21:50 Carsten Note Added: 0003473
2019-10-13 21:52 Carsten Note Edited: 0003473
2019-10-13 22:05 Carsten Note Edited: 0003473
2019-12-12 15:29 carl Note Added: 0003641
2019-12-17 20:55 carl Tag Detached: next
2020-05-30 20:16 carl Note Added: 0003834
2020-05-30 20:16 carl Note Edited: 0003834
2020-05-30 20:16 carl Note Edited: 0003834
2020-05-30 20:17 carl Note Edited: 0003834
2020-10-09 16:21 carl Note Edited: 0003834
2023-12-22 22:33 carl Status new => acknowledged