Community
Civil 3D Forum
Welcome to Autodesk’s Civil 3D Forums. Share your knowledge, ask questions, and explore popular AutoCAD Civil 3D topics.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

C3D 2012 RAM speed versus response time

31 REPLIES 31
Reply
Message 1 of 32
granite07
2133 Views, 31 Replies

C3D 2012 RAM speed versus response time

Yesterday I accidentally made a discovery

For the past week after working well the Civil 3D software slowed to a crawl for the sampleLine process. The autocad forum had no help for this specific slowdown and an email to a C3D expert found this is a known issue with no real solution other than to split the drawing into several dozen drawings with xref and shortcuts.

So out of frustration I re-tuned the computer (for this machine we paid the extra cost for unlocked hardware and bios after the experience with my locked HP laptop) - it fixed the slowdown. But, now some of the C3D corridor processes are unusably slow; it looks like C3D has a bi-modal optimal hardware configuration.

For a 4x4GB [16GB] dual dual-channel modules the two opposing settings for the memory are:

  1. a fast (CAS) latency of 7 and slower clock speed of 1650Mhz
  2. a faster memory speed 1730Mhz and slow CAS of 9 - I assume if I turned the memory up to 2000Mhz there will be continued improvement but an increasingly worse response time.

I am considering purchasing a third memory set for this machine to try and satisfy both a ~1800Mhz memory speed and CAS latency 7 response time:

What do you think?

Forest Peterson, granite@stanford.edu; build-sheet
Tags (1)
31 REPLIES 31
Message 2 of 32
Sinc
in reply to: granite07

I think you're chasing the wrong thing.  As a single-threaded app that can only utilize one core, RAM speed is not the bottleneck even with 1333 MHz.  Instead, it's at the CPU.  That's why C3D performs so much better with the new 2nd Gen i3/i5/i7 chips...  One of the big improvements in that line of chips was the MMU.

 

Are you REALLY running C3D on Server2008...?  I suspect that might be more the cause of a lot of your problems...  Server2008 does not make an ideal OS for a CAD computer.

Sinc
Message 3 of 32
granite07
in reply to: granite07

Some good points:

  1. Fairly certain Server2008R2 and Win7 have the same core sourceCode (XP and server 2003 were different) "The fundamental difference between Windows 7 and Windows Server 2008 R2 is how tasks are prioritize...Changing Windows Server 2008 R2 to act like its desktop counterpart is nothing more than flicking a switch." have been using the server versions for the past five years without a problem - why, because it is free for students.
  2. The processor is clocked at 3.9Ghz to compensate for the single core; tried 4.2Ghz but did not see much of a change with the 300Mhz increase.
  3. The i3/i5/i7 are marketing designations and have no relation to the actual architecture, they somewhat randomly refer to the very different Nehalem, and Sandy Bridge. But taking the gist of what you are saying I researched and found that the AMD Phenom II and Nehalem have similar memory mamnagement unit (MMU) configurations and so I assume the Sandy Bridge has the improved configuration you noted. But sandybridge is rated for memory up to 1333Mhz while AMD Phenom is rated for up to 2000Mhz - both have possibilities for tuning to higher clocks. I will stop here since I am way out of my area of knowledge and propose finding someone to answer the question of memory if we can form a solid question to ask.

All that said, in theory you could be correct - but in real world use, I found a very big difference in performance for differing C3D functions with the two memory configurations.

Forest Peterson, granite@stanford.edu; build-sheet
Message 4 of 32
Sinc
in reply to: granite07

You are getting yourself into trouble, and chasing ghosts...

 

Yes, "Nehalem" referred to the early i3/i5/i7.  But "Sandy Bridge" is "2nd Gen i3/i5/i7".  Two very different things.  It's also unwise to try direct comparisons between components of Intel and AMD CPUs, since so many things are structured differently.

 

In any case, you are running into very bizarre problems.  They are not typical.  And the thing that is weirdest about what you are doing is that you are trying to use Windows Server as an OS for a CAD workstation.  I would view that as insane, if for no other reason than it takes Windows Server so much longer to boot up and shut down, let alone all the rest.

 

If anything, maybe you should concentrate on what Services you have running.  You may be able to tune Windows Server to behave much like a CAD Workstation, but it's not intended to be used that way, so I suspect you'll have to do a lot of tweaking.  That all seems like wasted time and expense to me.

Sinc
Message 5 of 32
joshuamodglin
in reply to: granite07

Forest,

What do you have that actually is defined in the drawing containing the Sample Lines?

Are you currently using data shortcuts/references to manage the design data?

How large is the alignment that you are sampling?

Are you sampling a corridor also? If so, does it reside in the same drawing?

Josh Modglin
Advanced Technologies Solutions Logo
Message 6 of 32
granite07
in reply to: granite07

The sample lines are in the worst case scenario as best I can tell. The criteria you asked for I am guessing are the things that can be done to resolve sample line performance problems; validating that this is a well known problem.

 

The point is that I accidentally solved the sampleLine performance issue by tuning the memory. And today I am going to test different memory settings to see the behavior on the sampleLine and corridor function. Do you have any suggestions to help ensure the test results are usefull.

 

 Also - what is your opinion for this idea; on the autocad c3d help wiki a performance page that summarizes the topic like this and at the bottom of the page a table where anyone that cares can place hardware and software configurations that work well for them like this table.  When I built my computer I researched configurations and found very little except for this website http://www.c3dbenelux.org who made an exception so I could join and review the test results. even now I am still finding major new information like "Sandy Bridge has a exceptionally improved memory unit", nice. But in real world use what does it mean. If we post to the table what we 'feel' works and post some index scores then we can compare, learn, and form a more effective community.

Forest Peterson, granite@stanford.edu; build-sheet
Message 7 of 32
joshuamodglin
in reply to: granite07

I am not surprised that tweaking the memory would have some impact in performance.

 

However, in the time, effort, and money spent on adjusting, tweaking, and improving hardware configuration (above what you find in multiple blogs and even posts here from Autodesk employees) versus the performance improvement gained through that process seems minimal and even costly compared to looking at project/data workflow.

 

 

Josh Modglin
Advanced Technologies Solutions Logo
Message 8 of 32
granite07
in reply to: joshuamodglin

What do you mean? In most cases several people are collaborating and their work has a workflow so I see your point - in this specific case I am working by myself so the workflow is nonexistent; unless you mean workflow as in first build the entire model then last build sampleLines and when it locks-up on the last sampleLine hand the C3D model off - it is now complete. I did that but did sampleLines before payItem mapping so maybe I should have done payItem mapping before sampleLines then run QTO reports. But the point is that the model becomes unusable at some point.

 

For context, this specific case is using a location-based model, there are 450+ surfaces, 77 corridors, 10 alignments, and many sampleLines. The workflow for a location-based C3D model is without doubt complicated and I am not going to test it to show how complicated or if it is even possible. Hardware tests are costly only once - after that it is returned thousands of times. If I find through considerable time, effort, and cost that C3D 'likes' 1800Mhz memory with a CAS 7 and this is replicatable for everyone then there is no cost beyond myself. And, if it mitigates the need to orchestrate workflows more complicated than the flea-flicker play - good.

Forest Peterson, granite@stanford.edu; build-sheet
Message 9 of 32
granite07
in reply to: granite07

To keep this subjective and give some real values, attached is a video of the process I will use to test the sampleLine and corridor performance.

 

These are the steps I propose to use for the 2 opposing memory configurations: documentation is with CamStudio screen capture and 4 measured metrics are save time for sampleLine and corridor, time to map payItem, time to rename surface - measured in seconds from video. The test machine specifications are here.

  1. show computer properties (this view was asked for by Gavini in an email exchange several months ago)
  2. show advanced system settings performance visual effects, advanced, and virtual memory(Gavini)
  3. show device manager graphics properties driver (Gavini)
  4. show C3D performance tuner and manual tune (Gavini)
  5. show device manager graphics driver (Gavini)
  6. build a 'test' sample line 99CL1>NB>07 - this step took 80 seconds + 330 seconds to save (the temp drops from 47°C to 39°C, I turned on a floor fan pointed at the open case)
  7. Map sampleLine with objects (mistake due to mismatch in locations)
  8. assign a payItem to 99CL1>NB>07 corridor code code set style - several seconds
  9. rename a corridor surface - several seconds
  10. save - 70 seconds
  11. run geekbench score (universally accessible index allows comparing these results with other configurations)
  12. show CPU-z configuration (often asked for in forum threads)
  13. done - total duration per test 730 seconds (12 minutes)
  14. post results to this table; the video is 1GB so it is in a 160MB zip
  15. summary: this test was supposed to have a quick sampleLine time but it did not so maybe my memory observation is not the whole story - this is a different but similar configuration to what did work.

seem complete, through, degree, documented, and allows a 3rd party to repeat

Forest Peterson, granite@stanford.edu; build-sheet
Message 10 of 32
granite07
in reply to: granite07

Test Results:

 

Notes:

  1. in previous test the alignment sample line list was already open, this takes 70s and is included in the memory low latency test time - meaning the actual spread between times is greater than shown
  2. added a space to name, previous tests only opened and closed name without editing - so the actual time was not measured but the 'feel' of the 10s delay is noticeable compared to the faster processor speed setup
  3. test machine setup here http://cife.stanford.edu/wiki/doku.php?id=cee241:software:settings:tower#tuning

Summary:

By accident I noticed the performance in corridor and sample line differed noticeably with different hardware configuration. After testing, a faster processor and memory speed with slower memory response resulted in good corridor processing but slow sampleLine processing - and the opposite - slower processor and memory speed with faster memory response resulted in slow corridor processing and faster sampleLine processing. Above are the results with context using actual values rather than an arbitrary fast and slow.

 

The final results are not consistent with my initial 'discovery', the sampleLine time was better with a faster processor and slower memory response, but in testing is has the best time with the opposite configuration - I think the difference in 'feel' is in the time to open the alignment sampleLine list rather than the overall sampleLine time. The difference in feel between the settings is noticeable and annoying enough that I took the time to look for a new configuration and then test, document, and post here for comments; essentially each setting results in an opposing function that feels like it 'doesn't work'. The sampleLine is twice as fast, the corridor surface name is five times slower and the corridorSave is twice as fast.

 

I could test further, in greater detail, and generate better test runs for comparisons with better accuracy in the measurements but what is here is sufficient to validate that there is a significant difference in opposing function performance with different hardware settings. Until there is more discussion and reproduction of these results I am not going to test further.

Forest Peterson, granite@stanford.edu; build-sheet
Message 11 of 32
granite07
in reply to: granite07

More testing to remove notes and check repeatability of results.

 

It is more than just memory speed versus memory response time:

  • the HyperTransport speed looks like it controls the sampleLine performance - tested 1800Mhz versus 2300Mhz; comparison video (youtube)
  • the memory response speed (CAS) appears to control the corridor save - tested CAS 9 versus CAS 7; comparison video (youtube)
  • the tested processor speed range from 3.7Ghz to 4.0 Ghz did not appear a significant factor
  • in both comparison videos for HyperTransport and memory notice that the core temperature difference is 5°C to 10°C and is not controlled for so has an unknown effect
  • without further testing to vary the memory speed while CAS and CPU are held constant it is unknown what the effect is but intuitively it is like the CPU and not a significant factor
  • the repeatable results (comparison youtube video link) using this method of measurement for the exact same configuration are within a range of +/- 10%
  • the text in the videos is clear at 1080pHD in full screen

Overall memory response time rules over memory speed, but to achieve the higher response time a faster memory was purchased (2000Mhz CAS9) and then ran at a slower 1600Mhz to achieve the faster response time CAS 7. Presumably this approach can be taken further with detuning faster memory and creating a broader performance curve with improved memory response time and speed. Currently (2011) DDR3 2200Mhz CAS9 is the highest parameter available in 4GB modules; as higher rated memory becomes available C3D functions should improve considerably.

 

Results are documented here in a wiki

Forest Peterson, granite@stanford.edu; build-sheet
Message 12 of 32
davevoith
in reply to: granite07

Seems like you would see a much better performance increase by changing your work flow and splitting up your data into smaller more manageable pieces.

 

Upgrading your ram and overclocking seems like a waste of time for the performance increases you are seeing. 

 

 

Message 13 of 32
granite07
in reply to: davevoith

There are conditions that may prevent that but first let me be clear what you are advising

  • changing your work flow; is this the workflow you are refering too
  • splitting up your data into smaller more manageable pieces; by shortcuts and xrefs?
Forest Peterson, granite@stanford.edu; build-sheet
Message 14 of 32
davevoith
in reply to: granite07

"For context, this specific case is using a location-based model, there are 450+ surfaces, 77 corridors, 10 alignments, and many sampleLines. The workflow for a location-based C3D model is without doubt complicated and I am not going to test it to show how complicated or if it is even possible. "

 

I have never had to manage the enormous amount of data you have but, I would say yes, you should be using dref's and xref's. I don't see any other way with that much data and it is slowing your machine to a crawl.

 

Keep it seperated into smaller much more manageable peices. I am not aware of your project scope or what your goals are with it, so I can't really give any other suggestions. 

 

 

 

 

Message 15 of 32
granite07
in reply to: davevoith

I made a video of the C3D model http://youtu.be/vfZuGLgVMEc

 

can you watch it and I'd like to discuss if the shortcuts and xref can be used, if it seem possible then I will take a day and give it a try to see what happens - I suspect it will explode into complexity and there will be some issue with linking components together when they reside in two files.

Forest Peterson, granite@stanford.edu; build-sheet
Message 16 of 32
joshuamodglin
in reply to: granite07

Forest,

Since you posted a private message requesting more clarity on what I meant by workflow, I thought I would provide a link to a blog post that explains what both David and I are getting at. The post is at:

http://www.civil4d.com/2009/06/xref-dref-and-plotting/

 

If you do not split up your data (especially the size of your project), you will bog yourself down to the point of choking no matter what kind of hardware you have simply because the software is built for design and thus is VERY accurate requiring large memory computations. This is not a matter of who is working on the project, although that may have an impact on HOW you break the data, but to take advantage of the software's fullest potential.

 

Looking at hardware when your project setup best practices have not been reviewed is the reason your discussion may not being followed or commented on much.

Josh Modglin
Advanced Technologies Solutions Logo
Message 17 of 32
granite07
in reply to: granite07

appreciate your time,

 

Reviewing the civil4D blog the first thing I notice is that xrefs are discussed in the context of plots - this is a VDC model so there are no plots; C3D can remove the plot function as far as I am concerned. The outputs from this C3D model are the quantities csv reports, a surface model for field 4D visualization, and a surface model to test the total station survey and GPS machine control application/performance. Second, there is no linework, at least nothing that is going to affect performance enough to go through the trouble of an xref.

 

I am fairly certain my workflow is following the best practice. I tested shortcuts and did not find a significant benefit from their use; as you suggest in you blog I had the existing surface and the corridor alignments with profiles as shortcuts at one time. After discussion with some experienced C3D experts I decided not to use xrefs for similar reasons.

 

As of right now the C3D project model is complete and the computer worked fine until the sampleLines were built; I think some better RAM and restoring my PCIe harddrive would resolve this too. The only reason it matters for me is that I am simulating the process of handing off the C3D model to the contractor - so if I handed them this model with the sampleLines it would be very slow for them to manipulate the model for construction purposes.

 

I am interested in your suggestion to split the model into multiple models and I assume let the contractor then reassemble it. Since you have suggested it I am now compelled to test your approach but first I must learn exactly what you are saying and learn how to follow your process. I have several questions that will help me setup a test:

  1. How does xref and dref (shortcut?) affect the quantity takeoff function of compute materials and QTO payItems (composite volumes should be fine)
  2. How are corridor targets affected - corridor 1 in dref 1 targets corridor 2 in dref 2
  3. Is it a pain to adjust the superelevation while watching effect on daylighting and targets - do changes in the active file propagate back through the drefs?
  4. Is this correct; deref:surface --> deref:alignment1 --> dref:profile1 --> dref:assemblies --> dref:corridor1 --> compile corridors 1 through n as dref into a final dwg and then add sampleLines and QTO?
  5. Is file backup an issue as dref files change name with incremented version number
  6. I have close to 100 corridors - how many do I place in each corridor dref; all for one alignment
  7. How sure are you that this approach will not explode into complexity and the tradeoff in performance will be offset by a greater chance for mistakes and greater time parsing through the multiple dref files? If adjusting something requires opening and closing a dozen files to update each, It seems plausible that I may as well have waited for a single file to finish the runtime.

It seems that opening two or more instances of C3D at once is mandatory; 

Forest Peterson, granite@stanford.edu; build-sheet
Message 18 of 32
joshuamodglin
in reply to: granite07

Forest,

Your questions show a thoroughness in collecting your thoughts but also show that you haven't done enough personal research on DRefs and Civil 3D workflow. For example, you can't Dref corridors but you can xref them in and cut sample lines from the Xref'd data. You also can't make a change to a referenced object (i.e., Alignment). That is the point of referencing - it leaves the definition to the parent object.

 

There is much out there on the internet (take principles from the material and put it to test on your needs) from AU classes, to Autodesk documentation (although a little old and rusty), to blog postings, to other discussions on this group that providing answers to your questions before you have done this research will be most time consuming. 

 

Please do some additional personal research and do some testing of blending the principles (you don't have plot sheets but you do have some form of output where-in you want the information to visually be represented in a format for the contractor to quickly understand the design) from what you have read and then post any questions you have at that point.

 

 

Josh Modglin
Advanced Technologies Solutions Logo
Message 19 of 32
granite07
in reply to: joshuamodglin

SOLVED... partially

 

So, I put off trying the divide and conquer approach Josh and - after some research I see that apparently - everyone else is using for civil 3D. In the meantime I hassled OCZ to replace my RMA'd PCIe drive in less than a couple weeks+ and was participating in a separate forum thread focused on performance. A post there suggested scalelistedit and -purge " on the lowest child drawing and work your way up to the parent drawings"; this posts assumption by default that there are child drawing indicated the widespread usage of the divide and conquer approach. I followed this suggestion, removing all but 1:1 and 1':1' scales and purging 10 purgable regapps. In the process I closed and froze all the open layers (maybe a dozen or so out of many)  - then opened just the specific one I am applying payItems. And, now the mouse lag and hesitation is gone that was preventing precisely placing the courser over a line. The immediate problem is solved. It looks like the 0 layer places a big drag on the system, though it is empty of primitives, a bunch of corridor associated styles and some surface attributes are set to the 0 layer. Layer 0 on - problem, layer 0 off - good performance for mouse. But, maybe it was the scales and 10 regapps.

 

The issue is solved partially since this does not address the sampleLines performance or the long runtimes that were the best I could obtain with optimized settings. But, the 1 minute runtimes are acceptable since they are only incurred for each sampleLine - there are 77 and it was only an issue for one site's alignment that had most of the sampleLines - and then most of the delay was just to initially open the alignment, after which the delay was much less for succeding sampleLine edits. I could have simply made the one alignment into two and again, problem solved. This leaves the corridor save runtime - it was nearly instant before the sampleLines were made, so this seems like 'workflow' - be certain everything you want to do with corridors is done before creating sample lines. The payItems can be assigned through the toolspace settings editor to avoid the corridor delay (I just thought of and tested that after suffering through all the corridors). Save the sampleLines for last, just before associating the QTO computeMaterials.

 

Also, I am using an older SSD that while a quality drive and one of the fastest available it is nowhere nearly as fast as the PCIe solid state drive that failed prior to the runtime tests. From the first post to this thread I maintain that a memory with a faster response and faster speed will improve the performance of C3D. I did some research and found that next year DDR4 memory will be available - and should help C3D performance - ending the past few years of hardware issues that the x64 move only partially resolved.

 

I will still test the divide and conquer approach in the next few weeks as time permits, simply so I have been thorough in testing, but otherwise I am completing the QTO and visualization, and moving on.

 

Therefore, from my perspective - a VDC model for quantities csv reports (works with some excel compilations), visualization through nwcout (works fine), and GPS survey and machine control (not tested but research shows it can be improved) without the need for plots and the associated, layouts, sections, tags, and text - the divide and conquer approach, with this machine, is overkill and now unnecessary. Large surfaces and point clouds are clearly good candidates for shortcuts but large scale dividing of the project is not necessary, unless there are collaborating parties where it is then required to have multiple dref and xref.

 

I have succeeded in hurdling over the hardware wall with brute force.

 

 

Forest Peterson, granite@stanford.edu; build-sheet
Message 20 of 32
LeafRiders
in reply to: granite07

I've worked with multiple DataSCs and the performance is improved dramatically. I feel this is something that could be set up with simplicity and logically to help multiple users and speed up  your main design files performance. It's all about  balancing what you're doing. Going to the extreme starts to work against you on this one.

 

Ensuring the user is utilizing all RAM available by adjusting this manually does help, and is probably the single most helpful step that C3D and ACAD users can do to open avoid restrictive hardware.

 

I do like the comment on how we should focus on adjusting the C3D workflow 1st and foremost. I've had success keeping all my surfaces in 1 separte dataSC and all alignments in it's own file as well. Good point on how far you take this stuff. Opening and editing separte files for all aspects continuously... doesn't seem practical. I personally focus on removing large surfaces and my alignments to  separate dataSC files, and my performance is improved.

 

We all need to remember that 70 sample lines is not realistic for most designs. You could have 3x that many and be grinded to a hault. I myself hate that C3D and ACAD can't be more stable and steamlined to focus on production and speed, instead of making sure any Jr. or dummy can open the software and "get by". I think managers even think anyone can draft / design, problem is you need to know how to use the software and setup projects. I'd say 50% of all users, don't know how to do this properly. (just a hunch).

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Rail Community


Autodesk Design & Make Report