Was habt ihr für Arbeits-PCs/Laptops?
-
Ich darf vermutlich das Schlusslicht präsentieren: Laptop mit Core i5 4200 (Dual-Core + HT) und 8 GB Ram. Dazu eine 512 GB HDD mit 8 GB SSD Cache.
Wir entwickeln zum Glück hauptsächlich Java, so dass ein kompletter Build "nur" 3 Minuten dauert, aber gefühlt dauert alles um die 3 Minuten: Hochfahren, Office starten, Browser starten, Eclipse starten, SVN update, VM starten... Da vergehen am Anfang des Tages schon mal 15-20 Minuten bis man loslegen kann.
-
Tobiking2 schrieb:
Ich darf vermutlich das Schlusslicht präsentieren: Laptop mit Core i5 4200 (Dual-Core + HT) und 8 GB Ram. Dazu eine 512 GB HDD mit 8 GB SSD Cache.
Wir entwickeln zum Glück hauptsächlich Java, so dass ein kompletter Build "nur" 3 Minuten dauert, aber gefühlt dauert alles um die 3 Minuten: Hochfahren, Office starten, Browser starten, Eclipse starten, SVN update, VM starten... Da vergehen am Anfang des Tages schon mal 15-20 Minuten bis man loslegen kann.
Kannst du deinem Chef nicht darlegen, dass 15min*250Arbeitstage = 62,5h = 2 Arbeitswochenlohn brutto das größere Übel als eine ordentliche SSD ist?
MfG SideWinder
-
Tobiking2 schrieb:
Da vergehen am Anfang des Tages schon mal 15-20 Minuten bis man loslegen kann.
Glaub mir, da gibt es schlimmeres. In einer Firma brauchte ich 5-15 (im Schnitt bei mehr als 10) Minuten Compilezeit für ein einzelnes Teilprojekt, etwa 3,5 Stunden für das Gesamtprojekt.
Gleichzeitig war der Speicherplatz so begrenzt das wir nur jeweils 3 VMs neben der Entwicklungsumgebung auf den Rechner halten konnten, diese waren für die Verbindung zu ein paar Kunden (mit unterschiedlichen VPN-Clients bestückt) ausgelegt. Der Austausch einer VM blockierte den Rechner für etwa 2-3 Stunden. Man wurde ständig vom Chef angemacht warum man sich noch nicht um einen Kunden gekümmert hätte, man müsste doch wissen welche VM man braucht (Leider war meine Glaskugel defekt)...
Selbst einigermaßen gute, aktuelle Standard-PCs hätten damals wohl gereicht um die Wartezeiten zu halbieren. Aber wie heißt es so schön: "Wir müssen Sparen, koste es was es wolle".
Mein jetziger Chef mag zwar in gewissen Grenzen auch sparen (3 Jahre alte, gebrauchte Workstations). Aber im Verhältnis zu damals sind meine Geräte in dieser Firma sogar noch nach dem anschließenden ausmustern besser...
-
SideWinder schrieb:
Tobiking2 schrieb:
Ich darf vermutlich das Schlusslicht präsentieren: Laptop mit Core i5 4200 (Dual-Core + HT) und 8 GB Ram. Dazu eine 512 GB HDD mit 8 GB SSD Cache.
Wir entwickeln zum Glück hauptsächlich Java, so dass ein kompletter Build "nur" 3 Minuten dauert, aber gefühlt dauert alles um die 3 Minuten: Hochfahren, Office starten, Browser starten, Eclipse starten, SVN update, VM starten... Da vergehen am Anfang des Tages schon mal 15-20 Minuten bis man loslegen kann.
Kannst du deinem Chef nicht darlegen, dass 15min*250Arbeitstage = 62,5h = 2 Arbeitswochenlohn brutto das größere Übel als eine ordentliche SSD ist?
Haben wir schon versucht. Allerdings haben wir das Problem, dass wir als Diensterleister beim Kunden auf Hardware des Kunden entwickeln, und der Verantwortliche beim Kunden keine Chance gegen die fixen Prozesse der IT hat. Die sehen nicht vor das ein funktionierender Laptop ausgetauscht wird. Da geht es in großen Konzernen leider zu oft unglaublich bürokratisch zu.
-
Danke für den Input Leute, coole Sache!
Bei uns hat es sich in den letzten 1,5 Jahren tatsächlich gebessert - früher flogen teilweise echt oft genug auch noch Laptops mit 4GB RAM durch die Gegend, die man dann erstmal zurückweisen musste, weil man damit nicht mal ein Repository klonen kann.
Mittlerweile sind sie wenigstens alle auf 16 GB aufgerüstet und haben eine 256 GB SSD.
Ist irgendwie auch etwas wenig, aber die meisten Entwickler sind einem Projekt zugeordnet, da kann man dann schon Ordnung halten.
Die CPUs sind irgendwelche dual-core i5s. Etwas lahm, aber schon OK.Wie ist denn Euer Setup bezüglich Software dann? Benutzt ihr VMs? Irgendwie schreckt mich bei den etwas die langsame I/O ab - macht ja eigentlich den SSD-Vorteil fast wieder zunichte.
-
Software ist bei uns quasi dem Entwickler überlassen. Viele verwenden Eclipse, viele Visual Studio, ein paar XCode. Vermutlich noch 1-2 weitere die von ein paar ganz wenigen verwendet werden.
OS ist ebenso wahlfrei, Windows, OS X oder irgend ne Linux Distro.
Ich verwende Visual Studio, weil ich es schon lange kenne und halbwegs angenehm finde. Linux Builds probiere ich mit GCC über "Bash on Ubuntu on Windows" aus. Das geht ganz gut. Nicht wirklich schnell, aber erträglich. Und ich muss nicht blöd rum-syncen oder mit VM Shared Folders rummachen.
VM brauche ich dadurch meistens keine. Die meisten Entwickler die mit Linux arbeiten haben allerdings ne Windows VM wo dann Visual Studio drauf ist, damit sie Windows Builds machen können (und ggf. debuggen).
Für AIX, Solaris, Linux PPC etc. haben wir Maschinen wo sich jeder Entwickler einloggen kann (Ad-Hoc Tests, Debuggen etc.) bzw. über fertige Scripts Remote-Build auf diesen Systemen ausführen kann.
Und wenn sehr spezifische VMs (spezielle OS Versionen) benötigt werden haben wir für x86 Zeugs noch OpenNebula wo man sich relativ unkompliziert und vor allem schnell was zusammenklicken kann. Für die "Exoten" ist was Ähnliches in Planung.
schlepptopp schrieb:
Benutzt ihr VMs? Irgendwie schreckt mich bei den etwas die langsame I/O ab - macht ja eigentlich den SSD-Vorteil fast wieder zunichte.
Was man so liest, und was sich mit meiner (begrenzten) Erfahrung deckt, ist die IO Performance bei Hyper-V sehr gut -- zumindest wenn man "fat" provisionierte VHDX verwendet (=*nicht* dynamisch). Dafür ist die "Integration" halt Kacke wenn man z.B. Linux als Gast verwendet. Also so Sachen wie Shared-Clipboard ... tjo, Pech, geht halt nicht. (Windows Gäste hauen aber echt super hin.)
VirtualBox scheint dagegen wirklich recht lahm zu sein was IO angeht.
-
hustbaer schrieb:
schlepptopp schrieb:
Benutzt ihr VMs? Irgendwie schreckt mich bei den etwas die langsame I/O ab - macht ja eigentlich den SSD-Vorteil fast wieder zunichte.
Was man so liest, und was sich mit meiner (begrenzten) Erfahrung deckt, ist die IO Performance bei Hyper-V sehr gut -- zumindest wenn man "fat" provisionierte VHDX verwendet (=*nicht* dynamisch). Dafür ist die "Integration" halt Kacke wenn man z.B. Linux als Gast verwendet. Also so Sachen wie Shared-Clipboard ... tjo, Pech, geht halt nicht. (Windows Gäste hauen aber echt super hin.)
VirtualBox scheint dagegen wirklich recht lahm zu sein was IO angeht.
Dafür gibt's doch die IOMMU-Virtualisierungsfunktion in Hardware (Kurz VT-d).
Wozu soll man also noch in Software virtualisieren, wenn es die CPU viel performanter kann?VirtualBox oder Co braucht man dann nur noch als Klebstoff dazwischen.
-
Tobiking2 schrieb:
Da vergehen am Anfang des Tages schon mal 15-20 Minuten bis man loslegen kann.
Kannst du nicht den Rechner in den Ruhezustand (bzw. Energiesparmodus) versetzen (anstatt komplett runterzufahren)? Habe ich bei meinem letzten Rechner auch immer so gemacht (nur wenn dann wieder ein Windows-Update mit Neustart anstand, hatte ich mal wieder eine längere Frühstückspause...).
-
Xeon E5-1560 v3 / 3,5 Ghz
64 GB RAM
1x SSD 1TB
1x SSD 500GB
GF GTX 970
2x 24'' FullHDProzessorkerne idlen oft darum, aber Graka koennte schon noch besser sein.
-
Hardwarevirtualiser schrieb:
Dafür gibt's doch die IOMMU-Virtualisierungsfunktion in Hardware (Kurz VT-d).
Wozu soll man also noch in Software virtualisieren, wenn es die CPU viel performanter kann?VirtualBox oder Co braucht man dann nur noch als Klebstoff dazwischen.
Mit "IO" hab' ich hauptsächlich (local) Disk IO mit virtual HDD Files (VHD, VMDX, ...) gemeint.
Da muss der Hypervisor Zugriffe auf die virtuelle HDD/SSD des Gastsystems in Zugriffe auf ein virtual HDD File übersetzen. Speziell bei dynamisch wachsenden virtual HDD Files ist das sehr aufwendig.Das ist wesentlich mehr als nur "Kleber" zwischen zwei Hardwareteilen.
Soweit ich weiss kann dir eine IOMMU dabei nicht mal helfen - die hilft nur wenn Hardware 1:1 an ein Gast-System "weitergereicht" wird. Diesen Teil des Problems löst man bei Disk IO sehr gut durch spezielle Treiber. Die plaudern dann über spezielle Interfaces "direkt" mit dem Hypervisor. Was quasi den ganzen Overhead der simulierten Hardware entfernt.
-
hustbaer schrieb:
Hardwarevirtualiser schrieb:
Dafür gibt's doch die IOMMU-Virtualisierungsfunktion in Hardware (Kurz VT-d).
Wozu soll man also noch in Software virtualisieren, wenn es die CPU viel performanter kann?VirtualBox oder Co braucht man dann nur noch als Klebstoff dazwischen.
Mit "IO" hab' ich hauptsächlich (local) Disk IO mit virtual HDD Files (VHD, VMDX, ...) gemeint.
Da muss der Hypervisor Zugriffe auf die virtuelle HDD/SSD des Gastsystems in Zugriffe auf ein virtual HDD File übersetzen. Speziell bei dynamisch wachsenden virtual HDD Files ist das sehr aufwendig.Das ist wesentlich mehr als nur "Kleber" zwischen zwei Hardwareteilen.
Soweit ich weiss kann dir eine IOMMU dabei nicht mal helfen - die hilft nur wenn Hardware 1:1 an ein Gast-System "weitergereicht" wird. Diesen Teil des Problems löst man bei Disk IO sehr gut durch spezielle Treiber. Die plaudern dann über spezielle Interfaces "direkt" mit dem Hypervisor. Was quasi den ganzen Overhead der simulierten Hardware entfernt.
Mit IOMMU kannst du eine Hardware, z.B. ein Festplattencontroller direkt an das Gastsystem weiterreichen und das kann dann darauf natürlich direkt, also raw zugreifen.
Wo ist da jetzt die Performancehürde?
-
Hardwarevirtualisierer schrieb:
Mit IOMMU kannst du eine Hardware, z.B. ein Festplattencontroller direkt an das Gastsystem weiterreichen und das kann dann darauf natürlich direkt, also raw zugreifen.
Wo ist da jetzt die Performancehürde?Klar kann man das, hab ich ja geschrieben. Tut man bloss nicht, weil es nicht praktikabel ist. Du willst nicht pro VM einen eigenen SATA Controller + eigene SSD einbauen. Du willst das über virtual Disk Files machen. Und da hilft dir die IOMMU nicht, und genau da ist dann das Performanceproblem. Oder eben auch nicht (bzw. kaum), wenn man paravirtualisierte Treiber + preallocated virtual Disk Files verwendet.
Klar, du kannst sinnfreie realitätsfremde Beispiele bringen und dann behaupten dass es dabei keine Performanceeinbussen gibt. Die Behauptung mag dann stimmen, nur ist sie halt eben sinnfrei und realitätsfremd.
-
Man könnte die Datenträger auch via iSCSI einbinden und die Datenträger direkt auf dem Hostrechner verwalten, auf dem auch die VM ausgeführt werden.
-
Klar. Aber wozu? Meinst du dass das schneller ist als über nen paravirtualisierte Treiber?
Was funktionieren kann ist wenn man über iSCSI geht, die virtuellen Disks aber von einem echten iSCSI Storage verwalten lässt. Nur dann braucht man - vorausgesetzt es gibt mehr als nur 1-2 Entwickler die das machen wollen - ne richtig dicke Netzwerkinfrastruktur und nen ebenso dicken iSCSI Storage.
-
hustbaer schrieb:
Klar. Aber wozu? Meinst du dass das schneller ist als über nen paravirtualisierte Treiber?
Was funktionieren kann ist wenn man über iSCSI geht, die virtuellen Disks aber von einem echten iSCSI Storage verwalten lässt. Nur dann braucht man - vorausgesetzt es gibt mehr als nur 1-2 Entwickler die das machen wollen - ne richtig dicke Netzwerkinfrastruktur und nen ebenso dicken iSCSI Storage.Die Disks sind nicht virtualisiert, sondern echte Platten, die per iSCSI in die VM eingebunden werden.
Eine Netzwerkinfrastruktur brauchst du da auch nicht, das Zeug läuft über ein virtualisiertes Netz auf dem gleichen Rechner. Also maximale Bandbreite.
-
Womit wir wieder bei sinnfrei wären. Ich will nicht eine SSD/HDD pro VM in meinem Rechner haben.
Und selbst wenn, wäre direkter Zugriff auf diese via paravirtualisiertem Treiber sicher schneller als wenn man sinnlos über iSCSI geht.Ich weiss aber ehrlich gesagt nicht worüber wir hier eigentlich diskutieren. Worum gehts? Ist doch alles vollkommen realitätsfremd.
