robest

Members
 View Profile  See their activity

  • Posts

    20

  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

robest's Achievements

Noob

Noob (1/14)

0

Reputation

  1. robest
    Yep. That's fixed it. Obviously disabling write through is not ideal, but it's no worse than what they've been using for the last five years on the ShareCentres. Many thanks for your help - it's much appreciated. Apologies for raising as Bug, grateful that we got to the bottom of it. Cheers Rob
  2. robest
    Ha. I had got as far as 'strict sync = no' and was just trying to work out where to set that in Unraid / if it was safe... Will try it now.
  3. robest
    Ok, I get that the sync write is slower, but not why it’s slower on unraid vs the other NAS (given that the unraid box has the ssd cache). Does the sync write bypass the ssd cache? Do I assume that the sharecentre nas had sync writes disabled? How do I disable sync writes on Unraid? sorry for all the questions, just need to work out what to do in the office tomorrow now that our shiny new server is performing much worse than the crappy old sharecentre NAS!!
  4. robest
    Ok. Many thanks for looking in to this. What’s the implication for me though? All out of luck using Revit with unraid? Don’t understand why the performance is fine with a normal Windows share or with our old DLink sharecentre nas...
  5. robest
    and with attachment dmserver-diagnostics-20200512-1701.zip
  6. robest
    Not when I originally configured the server, but yes when you suggested it. Behaviour still the same unfortunately. See attached for latest diagnostics. root@dmserver:~# ifconfig eth0 eth0: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST> mtu 1500 ether 90:2b:34:52:99:35 txqueuelen 1000 (Ethernet) RX packets 159919875 bytes 28388361452 (26.4 GiB) RX errors 0 dropped 14 overruns 0 frame 0 TX packets 195545365 bytes 278563143532 (259.4 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
  7. robest
    Sorry, I should have been clearer - I tried those settings on the architecture Unraid server, and it didn't help (although it was strange the the MTU was 1986, I hadn't set it to that). But the other (Unraid) server also had those settings (unbonded, mtu to 1500, no host access) and it was exhibiting exactly the same behaviour. My concern is that two different servers, on two different networks, with two differenet clients, are showing the exact same behaviour. Of course, I'm the common factor, so it could be something I've done, but apart from the host access setting, the architecture Unraid configuration is pretty vanilla.
  8. robest
    Thanks for replying. It's appreciated. The reason I posted it under bugs, is that this is clearly not expected behaviour, although I am happy to admit it could either be Revit or Unraid at fault. Given that the behaviour is only observed when Revit saves to Unraid, and is absolutely fine when saving to (eg) windows share, Sharecentre etc, and I haven't found any other reports of Revit behaving like this, my suspicion lies with Unraid, but it's only a suspicion. What the mechanism might be though I'm not sure. I guess there is some diffference between Unraid and a pure windows share (as experienced by Revit) that is causing the problem). I've tried those suggestions on the Arch server, but unfortunately they didn't help. The other server exhibits the same behaviour and already had those settings set. I'd be grateful if there are any other suggestions (disk tuning settings?? etc) or possible diagnostic approaches I could try.
  9. robest
    Here are the diagnostics from while Revit was unresponsive. For what it's worth, the problem can be reproduced using the trial versoin of Revit 2021 and the included Sample Services example file. https://www.autodesk.com/products/revit/overview (Open Revit, open Sample Service file from welcome screen, save as to unraid share, saves completes but then Revit hangs for 30s. This is only a 29Mb file - most of our files are 100-200Mb, hence the long hang times). dmserver-diagnostics-20200512-1344.zip
  10. robest started following [6.8.3] docker image huge amount of unnecessary writes on cache and Revit hangs when saving large file to Unraid share
  11. robest
    Have recently installed a new Unraid server in our architecture office, but now have a major problem. Whenever we save a large (10's or 100's MB) file from Autodesk Revit to an Unraid share, Revit hangs after the save for some time proportional to the file size (up to 5+ minutes for 100MB+ file). Exact behaviour is click Save, green progress bar gets to 100%, then program hangs ("not responding" / greyed out) then it comes back. We have replicated this across two different unraid servers (both running 6.8.2) on two completely different networks from multiple different Windows 10 clients. One unraid server has AMD cpu, the other intel. Both have very good resources (16GB or 32GB memory, fast drives etc) There is no generally underlying performance issues - large (3GB) files copy happily across the network at 112MB/s etc. Same behaviour on shares with or without cache enabled Same behaviour with or without Docker enabled Same behaviour with multiple versions of Revit (2018, 2020) etc Latest patches for wndows, Revit etc. Revit has no problems saving to DLink ShareCentre NAS or Windows shares. First time using Unraid with Revit. New server in arch office still on demo license. Same behaviour with my other server (licensed) used for different business. Both diagnostics attached - dmserver is the Arch office server. Put as Urgent as it is a showstopper for us in the office. We will need to abandon Unraid in the next day or so if we can't improve this. Appreciate it's an edge case for you in terms of the software involved, so you may want to downgrade to Minor. Not sure how to diagnose this further. Are there some settings we can try? dmserver-diagnostics-20200512-1236.zip butterflyserver-diagnostics-20200512-1237.zip
  12. robest
    A bit more info: originally when I was setting this up I had disabled all dockers etc. Then when I thought I'd got it sorted (ie fixed the MTU issue) I had re-enabled everything - including motionEye recording 4 video streams. If I stop the motionEye docker, I get better performance (but "only" 700-800Mb/s rather than the 1Gb/s I was getting before). However - the motionEye docker has it's own NIC, and it's own share with cache disabled, and there's plenty of horsepower in the CPU, so I'm still a bit surprised at the performance drop. I'd have thought the video recording to the hard drives wouldn't have affected a write to the cache (nvme ssd).
  13. robest
    (Forgot to add, put all the MTU back to 1500)
  14. robest started following Problem with 10gbe, unstable Web connection??
  15. robest
    Well, this is strange. Installing the 10Gbe card seemed to mess up half my dockers, so spent some time fixing those, and upgrading to latest Unraid release (was previously 6.7.x). Everything working ok, so I thought I'd check the file xfer speed again. Now, reads are up to 1.1GB/s (great!) but writes have dropped to 110MB/s (what?!?). I've run iPerf, I'm getting full 10Gbit/s in both directions. Watched the Dashboard during the transfer (a 7Gb file) and the traffic is definitely coming in on eth0, the 10Gbe card. Source drive is a SSD, can get 2GB/s off it to another local SSD, so that's not the issue. Both PC and server are connected to the same DLink DGS-1510-28X switch each in a SPF+ port (one via DAC, one via fibre link). Occasionally I see the writes go up to 250MB/s but mostly stuck at the 100 ish mark. Double checked the switch, no dropped packets. What on earth is going on now? (Diagnostics attached) butterflyserver-diagnostics-20200503-2120.zip
  16. robest
    One last update for now - iperf is showing 10Gbit/s in both directions now, and I've got fast SSDs both ends, so still not sure why reads are slow.
  17. robest
    Ok, so one issue was that I was setting the MTU to 9014 on Win10 and unraid, which I then set on the switch as well, but on the switch I was setting 'maximum frame size' to 9014, which apparently is wrong - the frame size is larger. Fixing that means I can have jumbo frame renabled now without packet loss. But it hasn't improved the transfer speed from the medium results I was getting - 1GB/s writes but 400-500Mb/s reads.