Compared the the Cisco nexus 5672 switched I have been installing recently it is... They are 30" !! And you need decent clearance port side as well for the qsfp adapters.Haha 20" is not short depth
Intel Xeon D-1500 Series Discussion
- Thread starter Patrick
- Start date
Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.
Its not to protect from Static - its to protect my life. Scratching the dining room table brings out poltergeist wife and is punishable by death.
Be happy . that she does allow You to use the dining table as build center. Some would see this as major leap forward...cf the floor in the back room...
Just an update here - we got confirmation that the Xeon D-1541 based Gigabyte MD10-DS3 will arrive in the next few hours.
GIGABYTE - Server Motherboard - BGA 1667 - MB10-DS3 (rev. 1.3)
Edit - Taiwan to US hours got crossed, still a few hours but more like 20-24.
GIGABYTE - Server Motherboard - BGA 1667 - MB10-DS3 (rev. 1.3)
Edit - Taiwan to US hours got crossed, still a few hours but more like 20-24.
Last edited:
I signed up just to "Like" your post!
I have been in a discussion with Patrick on that board and that it appears to be impossible to order/purchase it in Germany (I haven't found a shop with parts available yet, as of yesterday). The availability jumped from May'16 to tomorrow (31.03.) for one of the shops I watch - so we'll see what happens.
I'm planning to play with SR-IOV & network related topics like VEB and VEPA (for isolation of VM communication) and was glad I found the blog post on STH that mentioned that the Xeon-D 1540/1520 have SR-IOV limitations that are hopefully not carried on to the D-1518. I have good access to Enterprise network gear (Alcatel-Lucent Enterprise OmniSwitch) and was looking for a board with SFP+ (for DACs or optical connections).
As it might be of interest for some of you: There are 10GBaseT SFP+ transceivers becoming available now! I'm not working with that company (ProLabs), but thought it would be interesting for you to know.
ProLabs - 10G Copper Transceivers with OEM Compatibility
A couple of notes on the X10SDV-TP8F:
I loaded Ubuntu 16.04 daily last night. Came up perfectly and recognized all 8 NICs (2x i210s, 4x i350s and 2x 10Gbe). There was an annoyingly long pause by the installer at "detecting devices" - I estimated 90 seconds. Don't really understand that but I'm speculating that it was trying to figure out which NIC had a live internet connection.
Since the manual isn't published yet i had to guess on the NIC order. Appears that the leftmost two (facing from the rear) are the i210s with port 0 on the bottom (typical for SM). The next four are the i350s. The 10Gbe are sorta obvious as they are SFP+.
I did notice an oddity with the new Linux NIC renaming scheme. Firstly, it only seems to permit 4 "on MB" NICs, named "eno1", eno2", "eno3" and "en04". The other for get named "rename1", "rename2", etc. It was designed to "ensure" stable naming across reboots - but it doesn't. The names shift around across reboots, probably because of probe-response time randomness, which makes it impossible to get a clean startup across boots. For now I disabled the "new" naming and went back to MAC-based binding to eth[0-7].
I also successfully set up booting to a ZFS mirror rpool. This is still not supported directly in the installer (boo) and I had to follow the method published for 15.10. But it does appear to work. We'll see if it will still be stable after a kernel update.
I loaded Ubuntu 16.04 daily last night. Came up perfectly and recognized all 8 NICs (2x i210s, 4x i350s and 2x 10Gbe). There was an annoyingly long pause by the installer at "detecting devices" - I estimated 90 seconds. Don't really understand that but I'm speculating that it was trying to figure out which NIC had a live internet connection.
Since the manual isn't published yet i had to guess on the NIC order. Appears that the leftmost two (facing from the rear) are the i210s with port 0 on the bottom (typical for SM). The next four are the i350s. The 10Gbe are sorta obvious as they are SFP+.
I did notice an oddity with the new Linux NIC renaming scheme. Firstly, it only seems to permit 4 "on MB" NICs, named "eno1", eno2", "eno3" and "en04". The other for get named "rename1", "rename2", etc. It was designed to "ensure" stable naming across reboots - but it doesn't. The names shift around across reboots, probably because of probe-response time randomness, which makes it impossible to get a clean startup across boots. For now I disabled the "new" naming and went back to MAC-based binding to eth[0-7].
I also successfully set up booting to a ZFS mirror rpool. This is still not supported directly in the installer (boo) and I had to follow the method published for 15.10. But it does appear to work. We'll see if it will still be stable after a kernel update.
ProLabs has it on their pricelist for $500, the rest depends on your relationship with a distributor (aka the discount).
Yes they are. And no it doesn't. They are not silent - or really even close to silent - but the MB holds them at about 5k RPM and they give a nice dull hum at that speed.
Not bedroom quiet, might not want it right next to you, but from across a small room it's good enough. For me it doesn't matter because they all live in the garage.
Not bedroom quiet, might not want it right next to you, but from across a small room it's good enough. For me it doesn't matter because they all live in the garage.
Looking around a bit, it appears that the randomness on the NIC naming might be a BIOS bug.
According to this, the BIOS is supposed to report onboard device ordering in SMBIOS type 41 records. It appears (though I have no way to test) that the on-die NICs (i210 #1, #2 and 10Gbe #1 and #2) and the i350 external NICs are assigned duplicate order values. This is consistent with four of the NICs getting name "renameN" by udev - and the randomness is based on which NICs get which name "e.g., eno1 vs rename5, etc.".
I'll open a trouble ticket with SM.
According to this, the BIOS is supposed to report onboard device ordering in SMBIOS type 41 records. It appears (though I have no way to test) that the on-die NICs (i210 #1, #2 and 10Gbe #1 and #2) and the i350 external NICs are assigned duplicate order values. This is consistent with four of the NICs getting name "renameN" by udev - and the randomness is based on which NICs get which name "e.g., eno1 vs rename5, etc.".
I'll open a trouble ticket with SM.
I'm looking to build a low power always on system, and I'm having trouble finding data to compare the different versions of the xeon-d power usage wise. Does anyone know what the idle /maxed power consumption is for a D-1541? The D-1528 board review lists the stats.. Haven't found any similar information for the other SOCs.
Supermicro X10SDV-6C+-TLN4F Review – Xeon D-1528 mITX
But also note the suspicion is that the wave 2 1521/1541 is less hungry than initial chips 1520/1540
Last edited:
@kiwimonk - If the systems are always on and idle, the power differences are negligible. Broadwell is very good at spinning down unused cores so I would optimize on the maximum single and multi-threaded performance you think you will need. If the D-1518 will work performance wise, get that over a D-1541. If the D-1541 has the performance you need, that is the chip you should get. At idle they will all be relatively similar.
I don't need much in terms of performance, so I'm leaning towards the D-1528. Basically it's going to replace my nas, so Raid 6 BTRFS.. Probably with ESXi on the metal and Xpenology managing the drives. The power where I live is the most expensive power in the US, so draw is a huge concern for me. Sounds like the D series are all close enough to not really worry about it. I guess the other attractive thing about the D-1528 is the upfront cost. Thanks for the info.. This site is the only one I've found really focusing on this amazing new platform.
My X10SDV-4C-7TP4F is scheduled to ship on 4/7 right now. I believe I was one of the first people to purchase it on WiredZone as I bought it before it was even publicly linked on their site so I'll be sure to post about it when I get it. It's probably the last component I need to finish my build but I'll be sure to post some pics/details about it when it gets here .
.Is this a general trend for all E5+ (32nm or later/lower) or just Broadwell?
Like car engines turning off cylinders to save juice?
Still bouncing off the fence of what to get because of these pesky watt prices here...