Alphahelix

I am experience a rather strange phenomenon. unRAID cannot see my Chelsio CC2-N320E-SR card. But if I remove my two VGA cards (GTX 760 & GTX 1060) it can can see the Chelsio card. Not only can see it, but it works as intended. I have asked around at my work, and possible root causes has arised and fallen. to name a few: * the PCIe x16 populated by the VGAs will disable the populated Chelsio PCIe. - as my system is a dual CPU system, and the VGAs are on CPU0 PCIe and the Chelsio are on CPU1 PCIe, it cant be related to this error. * the Chelsio does not get enough power. - my PSU delivers up to 1200watts, and I only draw 600watts, so there shuold be more than enough watts to go arround. * the PCIe are defective. - I have tried to reposition my LSI card in all slots, all work. My system overview: unRAID version: 6.6.6 Mainboard: Supermicro X9DRi-LN4F+ CPU: 2x Xeon E5-2690 V2 RAM: 24x16GB reg. ecc VGA1: GTX 760 VGA2: GTX 1060 NIC: Chelsio CC2-N320E-SR Any thoughts are welcome. I am grateful for any help I can get to solve this problem. Thanks P.S I forgot to mention that I cant even see the chelsio card in the tools system devices

@off topic here sorry cant help myself. But do you guys and girls thinkit would come with the slogan: Version 6.6.7 one step ahead of the devil! ? Sent from my SM-G955F using Tapatalk

I like your humor... And thank again for the clarification.

It could be the developer of the plugin wanted to make sure the plugin is ready for the next OS version. Sent from my SM-G955F using Tapatalk

Thank you for the elaboration. Again I am far from an expert. So excuse my ignorance, but if I via shell or Krusader was to copy from one or more locations to two (to keep it simple) independent disks. Would it then half the speed? I always assumed (maybe incorrectly) that the parity worked by read then write. And in Turbo mode it would read from from all disks to calculate the parity, and it was done in the RAM. I just trying to understand it all. /Alphahelix

First I do not know if this is the right place to post this idea, as it kind of sits between unRAID OS and Turbo write. But here goes: The scenario: Turbo write is active and the share you are transferring files to is covering more than one drive. Then it should be possible to have all the drive the share spans to be able to receive data at once. This would be beneficial when transferring large amount of data, like when mover is initiated. I cant see if this is would be beneficial without Turbo write, but it should be. This would benefit write speed a lot as multiple disk as written too at the same time. Without being an expert, so I may be wrong in my assumption here, the only trade off is that the unRAID OS must calculate what data goes where on what disk. So CPU time should go up. Also there could be a lack before data is written. I do not know if my theory is sound, but it should increase writing data to shares spanning multiple disks. /Alphahelix

I had similar experience once, also with SeaBIOS, I got so frustrated that I left the PC in anger and did something else (washed the dishes) and when I came back it had booted into windows. So try and leave for 30min. The worst that can happen is that it doesn't work.

I know this is an old thread, but I hope it is OK to ask questions anyway. First of all nice build. And good thinking of the mods to optimize the airflow with alu-tape. I have a question regarding the temperatures, did your quick fix reduce the drive temps?

As an ex-Lab-Tech, I chose a methodical approach. So with reference to my motherboard manual I found the memory configuration for, per module setup and added first one module booted it, tested it, shut it off, then two modules. By the time I was done all modules was inserted and it worked. Or so it seemed, after a few days the error came back. I then re-seated the CPU's. now the error disappeared, for good this time. I don't know if this will fix your problem, but I do think its worth a try.

I have a Tyan s7012 with 144gb ddr3 reg. Ecc and two x5660 all residing in a cosmos s case. I know x5660 is not x5680. But let me know if you are interested. Greetings from Copenhagen, Denmark. Sent from my SM-G955F using Tapatalk

I have only skimmed the thread so sorry if this has been suggested earlier... But I have successfully corrected a RAM error before by re-seating CPU and RAM. Just a suggestion.

I have tried myself, but no luck. BUT I have heard that the temp folder in unRAID can use 50% of the free RAM. I do not know if that is something you can use. I see it as the best way to test in you scenario, especially because after a reboot all data in RAM is cleared.

Looks to me like the cards are working 9.89 Gbits/sec is in my book close enough. I think you should look at your storage in both ends. Maybe you could try and create a 11Gb RAM drive on both of the and and send a 10Gb file to test. That way you can test: RAM->RAM SSD->RAM HDD->RAM RAM->SSD RAM->HDD With that you can see where to put your shares. Just remember to run a few test for each and average the values. Just remember that one big file is most of the time faster than many smaller ones.

The amount of RAM of the receiving unRAID can play a role here. I see in my system that unRAID blast away full speed until my RAM is filled. As Johnni.Black mention the speed of your SSD is also a possibility. Yet with 10Gbe you should see arround 1Gb/sec (theoretical max is 1,25Gb/sec) when filling up the RAM. But only if the sending unRAID can read the data fast enough. So as I see it it can be both the read speed and the write speed that is the bottleneck.

I recently upgraded to 384Gb. (reg. ecc) The reason is that my plan is to run 2-3 photoshop VMs (each with 64Gb RAM) that my local photoclub can connect to via remote desktop. Until I fix the slow disk speed I plan on putting the 50Gb vdisk in RAM and a script copying it to the RAM then power up VMs at startup. That way I also ensure fresh image every boot. So I will be using most of my resources on the VMs.

Thank you! now it makes sense to me.

I don't seem to be able to find them... I even tried to download the script file again. from https://github.com/danioj/unraid-autovmbackup/blob/master/unraid-autovmbackup-0-4.sh But I could have overseen er newer revision than the 3 year old one from the link.

Did you find the error for this? I see similar behavior. I know my disk access is more than fast enough, so the bottleneck must be another place. Could it be that the docker container is set to only use 50% of the CPU? If so anyone know where to double check and correct?

@kron I found this site, maybe it can help. Yet I will warn against modding the BIOS. But maybe it can help you. https://forums.servethehome.com/index.php?threads/nvme-boot-with-supermicro-x9da7-x9dri-f.13245/ I know it is not 100% the same board you and I have, but I believe it is very close. It looks like it is short 2 LAN ports and 8 DIMM sockets and a different PCIe socket configuration.

Thanks for your assistance.

Just out of curiosity. What BIOS version do you use? Also where do you see the bifurcationoption? I am hoping to enable this on my board. /Alphahelix Sent from my SM-G955F using Tapatalk

I myself are using the handbreake docker. I dont know if that suits your need Sent from my SM-G955F using Tapatalk

It looks like this has been fixed now. I forgot to remove the card from my test machine. And only when I did system device check for another thing I noticed this card popping up. I plugged in a USB2 storage device and unRAID showed it as an usable device. I have not made a thorough test yet, but it looks like this chip is usable. /Alphahelix

According to this site: https://www.cyberciti.biz/faq/linux-checking-sas-sata-disks-behind-adaptec-raid-controllers/ you can extract it (true manually) from terminal/SSH. I would not call it not working properly, as it sounds like it will corrupt data or not being able to see disks or read/write data. But I can agree to not alerting properly.

Hi JeepeeMajoor I know this is an old post, but maybe others in the future can use the info. You can use the Fractal Design Define XL R2. You have to drill some holes to secure the board. But it will fit. You can even have 140x25mm fans in the top, though you only have like ½mm between the fan and the EPS/ATX connectors. But it will fit! See the attached photo