merkuron

joined 1 year ago
[–] merkuron@alien.top 1 points 1 year ago (1 children)

I’ve had drive failures bring down entire systems. Replace sda and see if the problems continue.

[–] merkuron@alien.top 1 points 1 year ago (1 children)

E3-1230v2 is completely different to an E5v2 or an E5v3. The E3’s were all 4-core dies. E5’s were built from two different dies, both of which had well more than 4 cores. The chipset is different between E3 and E5, the memory controller is different, and the PCIe lane count is different. You can’t directly compare an E3 to an E5.

Idle power can be estimated (CPU+RAM+chipset+drives+GPU), but is also majorly affected by:

  • Efficiency of the PSU: big OEMs were pretty good about putting efficient PSUs in their workstation products, but below 10% of rated load capacity, efficiency will be crap. Exactly how crap, depends on the specific PSU.
  • BIOS settings: there are a dozen different BIOS settings that can dramatically change how the CPU behaves, and the defaults vary for each system. Sometimes the defaults do not allow the processor to throttle all the way back under low load.

Your measured power consumption of 100W at low/no load is about what I’d expect. Can you reach lower? Maybe with the right combination of settings, and switching to slower/lower voltage memory, and making sure that the GPU is also throttling down, you could reach 65-80W idle. But I wouldn’t expect less than that.

[–] merkuron@alien.top 1 points 1 year ago (2 children)

Tried a different cable, just in case you’re capping out at 100Mbps?

[–] merkuron@alien.top 1 points 1 year ago (4 children)

Which protocol are you using to test file transfer? If it’s anything involving encryption, that CPU will be hurt real bad, with no AES-NE.

[–] merkuron@alien.top 1 points 1 year ago

Xeon E3’s are unbuffered DIMMs only.

[–] merkuron@alien.top 1 points 1 year ago

Get an ATX case with lots of drive bays, a SAS HBA (and SAS expander if you want lots of drives), cheap mobo/CPU/RAM and OS of your choice. Spin it up, play with it, settle on an OS you like, and upgrade components as needed.

[–] merkuron@alien.top 1 points 1 year ago

OPNsense, vyos, pfSense, TNSR. TNSR is extremely fast at routing, with some stringent hardware requirements. vyos is Linux-based and very fast at routing virtualized in KVM. The *senses are FreeBSD-based and have their quirks, but if all of your routing is ~Gbit symmetrical, you should be fine.

[–] merkuron@alien.top 1 points 1 year ago

Your rails are too long/your rack is too shallow. You either need rails designed for a shallower rack, or to somehow shorten the outer rails to fit your existing rack.

[–] merkuron@alien.top 1 points 1 year ago

USB by its very nature requires a host device. The connection method you described (PC—>DP—>DP/USBC—>Display) I can only assume works because the display’s USB-C port switches to DP-Alt mode, functioning solely as a DP input port. In this case, there is no host device.

USB-C hubs/docking stations, which provide many ports (HDMI, Ethernet, etc), require that any display signal be transmitted as data on the USB bus. In this case, DP-Alt mode cannot be used, and the PC is the host device. It goes without saying that display images are very bandwidth-intensive, and when using a such a hub, you want to maximize the upstream bandwidth. 5Gbps hubs are OK, 10Gbps are better, 40Gbps (USB4) is optimal.

YMMV on a setup that goes something like:

PC—>USBC—>KVM—>USBC—>Display

or

PC—>USBC—>KVM—>USBC hub—>DP/HDMI—>Display

I don’t know if a KVM knows how to handle this kind of situation. What does your USB switch advertise as capabilities?

[–] merkuron@alien.top 0 points 1 year ago (2 children)

DP to USB-C adapter probably uses DP-alt mode and not true USB-C data transfer.

view more: ‹ prev next ›