PCIe 4.0 M.2 SSD for OBD - Worth it?

Anyone using a fast PCIe 4.0 M.2 SSD for OBD?

I have a standard SATA 2.5inch which is rated for:

  • Read Speed: 560 MBps
  • Write Speed: 530 MBps

PCIe 4.0 M.2 SSD are typically10x plus faster.

  • Read Speed: 7000 MBps
  • Write Speed: 5100 MBps

I would like to know if anyone has used both and whether there is a speed up.... especially when switching between models.

  • I can't compare. My laptop has an M.2 SSD (though PCIe 3.0 if I'm not mistaken). No doubt this is a good investment, certainly when buying a new computer.

    Whether or not it makes a big difference in OBD I couldn't say. Since I am also not happy about the time to open models (certainly when loading the workset) and I'm usually not even handling big models. I have the impression it's better when switching between models in the same workset. But that will probably also be true with other kind of storage device.

  • Since OBD is mostly single thread application, most likely your CPU is the main bottleneck in loading and running OBD. Invest in a decent single threaded cpu (fast base clock) will be a better investment. 

  • Tuan

    'loading and running' ?

    My speed problem with OBD is, as OP says, when switching between files or Models, and sometimes start a plot. Message center talks about 'tiled mode due to memory constraints'? And I have 32 GB RAM ? Suddenly a file can take 20 minutes to plot to pdf.

    My feeling is this is not a hardware thing, but more MicroStation

    Dominic - hope this isn't steeling your thread?

    regards /Thomas Voghera

  • I don't think OBD cares if you have 1TB of RAM unless you do heaps of rendering. There are 3 main steps when you interact with OBD: fetching data, process data and present data. Currently OBD mostly uses only 1 computing thread to do the 2nd step - processing data. And that's where a lot bloat and wait time happening. Overly simplistic example, say it takes OBD 10 sec to load data, 10 sec to process it, and 10 more sec to present the data to you. Better ram and SSD might helps reducing the first 10sec to 5sec, so you shave 5sec out of 30sec. 

    For your specific snapshot, visual edge extraction is one of the few operations benefiting from having loads of RAM, and guess what, loads of CPU threads as well. But that's it. General file opening and day to day modeling / drafting in OBD is still a largely single threaded operation.

    Some more information on the visible edge extraction engine in CE can be found below:

    https://communities.bentley.com/products/microstation/b/microstation_blog/posts/lightning-fast-hidden-line-rendering-in-microstation-connect-edition-update-2

  • Yea... it would be good to see if someone has upgraded.

    To be clear, I am not talking about RAM.

    OBD / Mstn is pretty unique by being very 'hard drive' centric, saving continually to disk. Dont know any other CAD app that does this.

    Yes, Mstn is mostly single-threaded. I can see a lot of its processes will need to wait for the info is safely saved to disk before moving on to the next line. So, although it is usually true that CAD apps being single-threaded tend to benefit most with faster CPUs... it may not be the case here. Anyways, CPU speed-ups have stalled years ago and there is no sign this will recover any time soon... so faster access, multi-threading were seen as the next best thing.

    Loading: I think that moving from HDs to SSDs did speed things up a bit. I've heard that one problem is when there are a lot of files ( I am thinking of all those xsd etc that the Datagroup System uses) a fast SSD helps.

    Switching: Yea, this is a big pain. Mstn is much quicker than Mstn with OBD. So, I think a lot of it is software related? Does OBD save all the DGS etc info to disk when the user switches models? Or does it try to synch or check the DGS info before loading the new model?

    Hmmm: the default is for Mstn to Automatically Save Design Changes. Might be worth looking at turning this off will help speed things up. Not sure if there is an OBD equivalent.