Slow Performance during Interactive Length Tuning

• Slow Performance during Interactive Length Tuning
  Posted by cjurczak on 09 Oct, 2018 18:02
• I've been using AD for a couple of years, but am using the interactive length tuning for the first time.  The problem is I am seeing very sluggish performance from Altium when this feature is active.  Performance immediately before and after tuning a net is fine, performance takes a noticeable hit while tuning is active. 
  
  If I am tuning a net that is 500 mils long, it make take 10-15 seconds for the serpentine to display, and track lengths to update.  When I left click to confirm, performance is find until I click on the next track to tune. 
  
  I am running AD 18.1.9 Build 240, on my PC with a i7-3770 3.4Ghz, 16GB of RAM, Nvidia Quadro K600, on Windows 7 64-bit.  This PC hasn't given me any trouble with performance up to this point, and I don't think it is the weak link in this case either.  I have monitored the windows Resource Monitor while length tuning, and none of the assets are being taxed.  Notably CPU utilization is below 20%, making me think there is something else gumming up the works so to speak. 
  
  If anyone has any experience like this, or has a possible solution it would be greatly appreciated.  This forum has been a valuable asset in learning AD over the last couple of years, much more so than Altium itself sadly. 
  
  Thanks in advance, I look forward to hearing from some of you on this one!
• #1 Reply
  Posted by ajb on 09 Oct, 2018 19:56
• I'm running an i7-4770, 32GB RAM, and a GTX 660 on Win10x64, and interactive length tuning isn't silky smooth but it's perfectly usable. 
  
  How complex is the board you're dealing with?  Are you tuning tracks that jump between layers or have lots of twists and turns before tuning?
  
  Do you have an SSD?  This isn't the kind of thing you would expect to be influenced by disk performance, but I've run into a number of situations in different applications where an SSD shouldn't have made a difference but apparently did.  Also SSDs are so cheap they're kind of a no-brainer these days.
• #2 Reply
  Posted by cjurczak on 10 Oct, 2018 13:04
• I'd saw the board is fairly complex, but that is only by my limited scope of PCB design.  I'm length tuning DDR3 tracks between two chips and a 400 ball FPGA.
  I am not running a SSD, not sure I can swing that in time for this project.  I expected this to be more processor intense that disk speed.  I'm attaching a screenshot of my resource monitor, and GPU utilization during length tuning.  In this screenshot length tuning begins in the center of the chart, and completes just before the right edge of the chart.  Didn't seem like there was much going on to cause the bottle neck I'm seeing in Altium. 
  
  I'm not going to rule out an SSD as a possible solution, but not sure that is the silver bullet.  Any other evidence or opinions on the matter would be appreciated. 
  
  Questions for those reading, are you running an SSD with AD?  Are you using interactive length tuning feature of AD?

  ---

  
• #3 Reply
  Posted by Siwastaja on 10 Oct, 2018 14:48
• Note that this single "CPU" graph may be normalized so that your "8 cores" (4 with hyperthreading) make up 100% total. If you look at it closely, it appears to me that it tops off to 12.5% quite nicely - which would mean the Altium uses the core completely. So it really seems CPU limited.
  
  I would classify it as a bug in Altium. For me, length matching on similar complexity designs, on a much inferior PC, has worked just fine.
• #4 Reply
  Posted by T3sl4co1l on 10 Oct, 2018 23:10
• Are other actions slow?  Ex: beginning interactive routing; dragging or moving objects; moving through-layer objects (pads, vias); etc.
  
  Tim
• #5 Reply
  Posted by cjurczak on 11 Oct, 2018 15:13
• If Altium is not using multiple cores for length tuning that would make sense.  I have noticed occasionally that getting into any interactive routing mode can hesitate.  And running DRC takes longer than I am used to, but I attributed that to this board being more complicated than most. 
  
  It appears that when DRC runs, I am seeing similar CPU limitation.  See attachment for CPU utilization during DRC running for about 40 seconds.  Is there anything in my system or within Altium that could be limiting my CPU utilization?
  
  

  ---

  
• #6 Reply
  Posted by T3sl4co1l on 11 Oct, 2018 15:19
• I thought they finally put some multicore code into AD18?  Anyway, every prior version has been strictly single threaded.  Even for the last 10 years (since PCAD became AD) when that's been an obvious limitation...
  
  Tim
• #7 Reply
  Posted by cjurczak on 11 Oct, 2018 15:26
• This was my understanding as well.  To my defense I never worked on a board compatible to my current project on AD 17.  So I don't want to say the problem is AD18 specific, but it doesn't seem to be delivering in my case on being multi-threaded. 
  
  Take a look at this screenshot of the task manager during DRC.  You'll see poor CPU utilization during the running of DRC, but excellent utilization at the very end.  I suspect this spike at the end is the result of the report generation.  Glad we have fast report generation, but not on DRC? Come on, priorities Altium!

  ---

  
• #8 Reply
  Posted by free_electron on 11 Oct, 2018 15:56
• Altium 19 is 64 bit and multicore.
  
  are your rules set properly ? i lot of perceived performance issues are actually caused by rule sets that are very taxing. how you set up rules has a big impact. there are multiple ways to come to the same end result but some ways create a lot of overhead.
  
  Temporarily turn off all rules that are not required in interactive mode (silk clearances, solder clearance, body violations etc. leave only the lenght and diff pairs and clearance rules on.
  
• #9 Reply
  Posted by cjurczak on 11 Oct, 2018 16:44
• AD 18 is also 64-bit and has Multi-Core and Multi-Threading support according to this page on altium.com:  https://www.altium.com/documentation/18.0/display/ADES/NFS_18((Performance+Enhancements+&+New+Rendering+Engine))_AD
  
  I can do some testing with turning off some DRC later, but I'm busy with other things this afternoon.  Other fires that are needing put out so to speak. 
• #10 Reply
  Posted by free_electron on 11 Oct, 2018 20:01
• oops. i meant to type 18. yes 18 is multicore. 19 has a new render engine with massive speed gains. and includes a real field solver and new router for diff pairs and length tuning.
• #11 Reply
  Posted by KaZjjW on 12 Oct, 2018 06:57
• Quote from: cjurczak on 09 Oct, 2018 18:02

  I've been using AD for a couple of years, but am using the interactive length tuning for the first time.  The problem is I am seeing very sluggish performance from Altium when this feature is active.  Performance immediately before and after tuning a net is fine, performance takes a noticeable hit while tuning is active. 
  
  If I am tuning a net that is 500 mils long, it make take 10-15 seconds for the serpentine to display, and track lengths to update.  When I left click to confirm, performance is find until I click on the next track to tune. 
  
  I am running AD 18.1.9 Build 240, on my PC with a i7-3770 3.4Ghz, 16GB of RAM, Nvidia Quadro K600, on Windows 7 64-bit.  This PC hasn't given me any trouble with performance up to this point, and I don't think it is the weak link in this case either.  I have monitored the windows Resource Monitor while length tuning, and none of the assets are being taxed.  Notably CPU utilization is below 20%, making me think there is something else gumming up the works so to speak. 
  
  If anyone has any experience like this, or has a possible solution it would be greatly appreciated.  This forum has been a valuable asset in learning AD over the last couple of years, much more so than Altium itself sadly. 
  
  Thanks in advance, I look forward to hearing from some of you on this one!
  

  
  Hi,
  I have exactly the same problem. Creating a new accordion object works OK, but editing it afterwards is crap. I need sometimes more than twenty seconds to manage to move a vertice of the length tuning.
  Also often I get a software crash message when I try to route a track immediately after creating an accordion or when I try to delete one. Once it started, I then get the same software crash message whenever I deselect a length-tuned track.
  
  Altium 18.1.7, GeForce GTX 1060 6GB, i7-4770 3,40GHz, 16GB RAM, W7 64, SSD
  
  Tried to disable all the rules except the length ones, no change.
  
  It's been at least three major Altium versions with the length tuning tool and it is still broken. I have to route four DDR4 controllers with four memory chips each, this thing is starting to drive me crazy. 
• #12 Reply
  Posted by T3sl4co1l on 12 Oct, 2018 07:44
• I've found that editing accordion segments is crap even just in general. That it likes to snap to some grid or another, rather than actually be adjustable in the same way as the original (on placement) method?  Bizarre.  (Again, AD16ish experience.)
  
  Tim
• #13 Reply
  Posted by cjurczak on 12 Oct, 2018 20:31
• It has been suggested that the problem might be a GPU limitation?  Does anyone know if this could be credible?  I don't see length tuning as a GPU operation, but certainly could be.  Thoughts?
• #14 Reply
  Posted by KaZjjW on 13 Oct, 2018 13:01
• All right, I deleted all the rules and only left the ones for the DDR4 controller I was working on (length and width constraints) and the accordion tuning is already more usable (it went from "utter crap" to "slightly painful"). My rules aren't particularly complicated. I'm using an excel table to calculate the signal lengths and every track is constrained with the net name and the min/max length. I don't see why Altium bothers evaluating all the other rules, especially the ones with other net names..
  
  As for the "accordion size snapping back to original size" problem, a workaround is to disable the snapping (Shift+E) while resizing.
  
  The crash after deleting or deselecting an accordion is still there, but happens less often with less constraints (see attached GIF).
  

  ---

  
• #15 Reply
  Posted by cjurczak on 15 Oct, 2018 15:47
• Good timing, IT department has a new GPU inbound for me to support a 3rd monitor, so maybe I'll see if it helps with the performance issues.  It does seem like AD 17 uses the GPU less than AD 18.  I'm not sure what model of GPU I'll be getting, but if they go with what AD18 recommends it should get the job done, fingers crossed...
• #16 Reply
  Posted by Siwastaja on 17 Oct, 2018 08:51
• Having a computer program "multicore" isn't a simple tick-in-a-box thing, except on marketing Powerpoints.
  
  Actually multithreading a part of code varies between "easy" and "completely impossible". The actual improvement in processing time varies from linear improvement (i.e., 4 threads run in 1/4th time), to no improvement at all, to actually a decrease in performance (threads are always waiting for synchronization, there is only overhead).
  
  Most often, having a program "multithreaded" simply means that some of the different parts of the programs will run in parallel with increased performance.
  
  It does not mean that any single feature, such as the length tuning, would properly parallellize. It's a hard problem and a lot of work often spent better elsewhere than trying to parallelize everything. If everything's working as it should, maybe it parallels well, a rendering function may use another core, and length tuning another, but if the length tuning becomes the bottleneck, and stuck in evaluating some rules in a loop for example, then it doesn't help much. The right way is to see what stalls the algorithm and fix it, not expect great improvement by multithreading.
  
  Seeing one core at 100%, others near zero is a tell-tale sign that some specific part of the algorithm which just runs a processing loop and can't be / wasn't parallelized is stalling.
  
  "Altium is multithreaded" is a completely meaningless claim as is. No practical program runs every feature succesfully parallelized, since it's impossible to do so. Most of the algorithms in the backend are single, blocking operations. Having some of them run in parallel is a great achievement already.
• #17 Reply
  Posted by cjurczak on 17 Oct, 2018 14:16
• Altium Interactive length tuning does utilize 4 of 8 cores, but no where near 100%.  They seemed to have tried to improve performance, but what I am seeing makes the feature difficult to use. 
• #18 Reply
  Posted by cjurczak on 27 Nov, 2018 13:59
• Quick follow up, sorry it took so long, schedules and what not.  I have received a GPU upgrade to an Nvidia Quadro P2000, not what Altium recommends, but what my IT guys would approve.  Performance during interactive length tuning is much improved, but not completely without lag.  Overall performance in 2D is slightly improved, just moving around on a complex board is smoother.  Moving around in 3D is much improved, and smoother than before. 
  
  In my, albeit uneducated, conclusion Altium 18.1.9 is using multiple cores, but not threads.  It is using the GPU for many functions including interactive length tuning.  Overall Altium is doing a better job of using more resources available in a modern PC, but doesn't seem well optimized to fully utilize those resources.  During routine work on a complicated board, I can see utilization on CPUs/GPUs spike, but never fulling use the processing available even though Altium seems to become sluggish briefly. 
  
  Altium is moving in the right direction, but still have room for performance improvements that I hopeful to see in future releases.  Thanks to everyone for your input, and suggestions, this community is very valuable resource for any Altium user!