HawP

Kan se ut som at noen av 2011-modellene har radeon i tillegg, så da er neppe det grafikk-problemet aktuelt.

Og kan se ut som at hastigheten på minnet ble økt til 1333 på early 2011, så da må du passe på at brikkene støtter minimum den hastigheten.

For å sjekke hvilken modell du har og kunne finne spesifikasjoner, se her (hvis du får bootet den): https://support.apple.com/no-no/HT201581

bbios skrev (3 timer siden):

Tenkte å prøve doble ram på den og bytte til ssd, er det verdt det? 

Høyst sannsynlig, ja.
I alle fall dersom du har en modell som ikke har en "subtil" feil på det integrerte nvidia skjermkortet, som i alle fall noen av mid-2010 modellene hadde. Viste seg i form av "vilkårlige" krasj (dvs. vanskelig å framprovosere). Mulig feilen var "avhengig" av versjon av OS som ble brukt, for vi merket det ikke før reklamasjonsfristen nærmet seg.

Husker jeg ikke feil er det vel DDR3 1066 SO-DIMM som passer. Vi kjøpte bare en "standard variant" fra komplett (corsair tror jeg), og en samsung SSD (siden det var det den lokale datasjappa hadde).

wil skrev (3 timer siden):

 Linux er ikke for alle.

De som må (eller "må") kjøre programmer laget for Windows vil nok få det litt vanskelig, ja. ?

tigerdyr skrev (9 timer siden):

Personlig har jeg i 5 år kjørt Windows som en VM i Linux (Arch Linux) med PCI-passthrough til et grafikkort dedikert til Windows som gir full hastighet til programmer som bruker graffikkortet.  Det var noe knotete å sette opp den gangen og vet ikke om det har blitt noe nemmere med årene; tror fortsatt man må være obs på valg av grafikkort.  Hvis ikke man driver med 3D-spilling og foto/video-redigering med Adobe-suiten, så ser jeg ingen grunn til man ikke klarer seg fint med Linux og en helt vanlig Windows VM uten PCI-passthrough for windows spesifikke programmer.

Jeg har også en slik vm med Windows, og PCI-passthrough krever litt "ekstra" å sette opp, ja. Er noen betingelser som må være oppfylt.

For de som måtte være interessert er det at CPU, HK og bios/uefi alle må støtte iommu (amd-vi/intel vt-d) og at skjermkortet må være en annen modell enn det som brukes til host siden passthrough "baseres på" pci id, så kortene må ha forskjellig pci id. I tillegg er det en fordel å ha kortet i sin egen "iommu gruppe", slik at det kan "isoleres" (for passthrough) uten at andre enheter "følger med på kjøpet". Men dette avhenger av hvordan HK er designet (ikke hvor forskjellige ting er plassert, men hvordan de "henger sammen"). Når det er sagt er min lille erfaring at det kan virke som at (de fleste) pcie-spor (i alle fall de som er større en x1) havner i sin egen gruppe.
En heads-up for de som måtte få lyst til å prøve dette med en nvidia "desktop" gpu; nvidia sine drivere sjekker om de kjører i en vm og vil i så fall "krangle litt" og gi "error code 43" (mener jeg å huske). Er visstnok mulig å komme seg rundt det, en søkemotor er da din venn.

Forøvrig, og dette er nok også sagt av andre før; når det gjelder Linux og spilling så er det en fullt mulig kombinasjon, også 3D-spill, så sant spillet er laget for Linux. Og dessverre er det jo her den største ulempen er, og det er et "høna og egget"-problem. Steam har en del titler som (også) har en Linux-versjon, men det er helst indie-titler/mindre utgivere eller litt eldre versjoner selv om unntak finnes. Så det er ganske få av de "større" AAA-titlene (eneste jeg vet om/kommer på er Civilization V/VI, Tomb raider (2013) og F1 2017). Men det er mange bra indie-titler, de er bare ikke er så (veldig) kjente (er mitt inntrykk).

Splitter skrev (På 21.5.2020 den 10.35):

Noen her som har prøvd å folde med VM?

Nei, men jeg kjører vm'er med egen fysisk GPU "inni". Men har ikke foldet med det siden det skjermkortet ikke duger spesielt godt til folding, men "oppsettet" er jo det samme siden det bare gjelder å få GPU'en "inni" vm'en (aka. pci passthrough).

Men det er noen forutsetninger som må være på plass for at det skal være mulig. De viktigste er

• Maskinvaren, dvs. cpu+hk+bios/uefi, må alle ha støtte for iommu (vt-d eller amd-v; tror dette er betegnelsene fra hhv. Intel og Amd). Er ikke dette på plass er det ikke mulig å få til.
• Pci-e slot skjermkortet sitter i bør helst være i sin egen "cgroup" (dvs. "isolert" fra annen hw bortsett fra evt. en pci-bridge e.l.), siden alt som er i samme "cgroup" "flyttes" til vm'en enten det skal brukes eller ikke (hvis jeg ikke husker feil). Men dette pleier i praksis å ikke være et problem har jeg inntrykk av.

Har bare erfaring med kvm (Linux) når det gjelder dette, og som jeg tipper er det unraid bruker (uten at jeg har sjekka). Jeg bruker en kernel-parameter for å hindre kernel å tilordne driver til GPU, og bruker enkelt og greit libvirt/virt-manager til å tilordne GPU til vm (libvirt/virt-manager har blitt mye bedre på dette i de nyeste versjonene). Men har ikke testa å ha en vm med både en fysisk og en virtuell GPU.

Når det er sagt så er Nvidia ikke spesielt "glad" i pci-passthrough av deres desktop-GPU'er, for deres Windows-driver sjekker da om den kjører i en vm og gir i så fall "errorcode 43" (mener jeg å huske, har bare lest om det), men kan visst trikses rundt. Vet ikke om samme "restriksjon" også gjelder Linux-driveren.

bmork skrev (På 18.5.2020 den 20.51):

Noen idé om hvor stabilt prefikset er?  Er det koblet til linje-info, eller tildeles det dynamisk fra en pool?  Jeg har mistet troen på de full-atuomatiske omaddresseringene IPv6 var laget for.  Det finnes alltid en aksessliste du må oppdatere manuelt hver eneste gang....

Spurte de om det, siden jeg har fått nytt PD etter router-restarter og det jo vel egentlig ikke er noen grunn til at vi ikke skulle kunne få vårt eget ipv6-prefix (slik jeg har forstått det ut i fra antall mulige prefix) ...
Svaret var (ikke ordrett) at etter deres erfaring var det like statisk som ipv4, men at ipv6 fortsatt er i utviklingsfasen og at det at jeg fikk ny PD kan skyldes pågående endringer på tjenesten.

Så vi får vente og se det an ... kjedelig å "stadig vekk" måtte oppdatere brannmur-regler og andre ip-baserte allow/deny-regler fordi PD endrer seg.

Har du samme SSID på begge routerne (på forskjellige kanaler)? Hvis ikke forsøk det, siden det visstnok gir resultatet du ønsker i følge
https://forums.macrumors.com/threads/why-wont-my-iphone-automatically-connect-to-the-strongest-wifi-network.2057377/

(det er noen ios-versjoner siden, men Apple har antakelig ikke endret så mye på den funksjonaliteten?)

Oj, der fikk jeg jammen i gang AMD GPU'en under Linux også  ?
Men "bare" et RX570 ...

Ja, men det var i forbindelse med at de gjorde endringer i sin infrastruktur. Og jeg ble varslet på forhånd.

Ja, og hadde det ikke vært for at antakelig ganske mange av folderne som har kommet til pga. covid-19 folder med CPU (evt. i tillegg til GPU) ville det nok tatt sin tid og få gjort alle de nye covid-19 CPU WUene ...

Ryzen 3800X, med folding på 12 kjerner estimerer ca. 208000 ca. halvveis på prosjekt 14542. Varierer (typisk) mellom 180k og 200k avhengig av prosjekt.

Lurer på om noe av grunnen til at mange av covid-19 jobber er CPU, er at jeg mener å huske at jeg for lenge siden leste at "fah-core" for cpu er mer fleksibel (eller noe slikt) og at det dermed er enklere å lage jobber til (og kommer derfor raskere i gang) ?

Kan jo for moro alltids ta med TPF på 14542 også: 1m 10s

Var nok bare sprengt kapasitet (el. server-kluss), ja.

Men testet da like godt installasjon av nyeste versjon av klienten på opensuse, og nå ser det faktisk ut til at de har tatt i bruk nyere versjon av openssl. For nå starter klienten uten problem ? (og den fikk WU også)
Så da trenger jeg ikke lenger å kjøre den i en kubuntu-vm ...

Hmm ... tomt for CPU-jobber, eller har vi (foldere verden rundt) sprengt kapasiteten dems igjen ...? ?

Jetfighter skrev (12 timer siden):

Ser at de har en del prosjekter på core 21. Noen spesiell grunn til det?

Det kan være at de i ettertid har oppdaget problemer e.l. med ett eller flere "run", og må kjøre disse på nytt etter evt. å ha fikset/ordnet årsaken. I slike tilfeller må de da kjøre dette på samme core som prosjektet ble startet på.

Nå har forskere i Hong Kong "lagt ut" jobber/WUer som skal bidra til å undersøke om Remdesivir, Ribirine og tilsvarende kan brukes/endres litt på for å kunne brukes til å forhindre at covid-19/SARS-CoV-2 replikerer seg selv (hvis jeg har forstått det riktig).

Ser at min cpu jobber med en slik WU nå ?

War skrev (6 timer siden):

Kjøpt denne nå, så får vi sjekket litt lanes og pci-tall for folding

Spørs om det blir helt slik du tenkte ...
Hvis det er Biostar TB250 BTC D+ så er 7 av 8 slots x1 elektrisk (dvs. mining-tilpasset).

Sitat

1 x PCI-E 3.0 x16 Slot(x16)
7 x PCI-E 2.0 x16 Slot(x1)

Men du kan jo sjekke hvor mye ppd pci 2.0 x1 gir ...

Usikker på hvor mye nytte f@h gjør seg av et høyt antall kjerner/tråder i en slot nå for tida, men da er det jo alltids muligheten til å sette opp flere slots med x antall kjerner/tråder hver.

Jeg folder nå på en 3800X med 12 "logiske kjerner" (aka. tråder), og ppd oppgitt i fahcontrol ligger typisk mellom 160k-200k avhengig av prosjekt, og har siste tida ikke hatt problemer med å få jobber til den (kjører nå med client-type = advanced).

b-real skrev (10 timer siden):

CPU-folding får holde

Nyttig det også, siden noen nye Covid-19 simuleringer er kun for CPU (i alle fall i første omgang). Så de er avhengig av at noen folder på CPU også ?

Det går framover ?

Sitat

We are excited to announce a new batch of small molecule screening simulations are now up and running on Folding@home! These simulations will help prioritize which molecules will be synthesized and assayed by the COVID Moonshot aiming to rapidly developing new therapies against the SARS-CoV-2 main viral protease.

Over 1900 unique crowdsourced small molecule designs building on the DiamondMX fragment hits to the SARS-CoV-2 main viral protease (Mpro) were submitted to the COVID Moonshot project in just a few days! This movie shows all the designs docked into Diamond’s X-ray structures.

Please note that these new projects can only be run on CPUs. They complement the many Folding@home COVID-19 projects that are already running on GPUs, and they allow everyone to join in to help in the fight against COVID-19.

(hentet fra https://foldingathome.org/2020/03/30/covid-19-free-energy-calculations/ )

K N skrev (14 timer siden):

Og snakker vi om da om å sette "client-type" og "advanced" på Expert, that's it?

Ja, enten der eller på den enkelte slot hvis du ikke vil at alle slots skal være av samme "type" (rediger slot, nederst finnes  "extra slot options")

b-real skrev (13 timer siden):

Yep, både client restart og full reboot begge steder. Forandret ingenting. Oh well, tail av log fungerer også..

<!-- HTTP Server -->
<allow v='127.0.0.1 x.x.x.x'/>

Og sikkert en fordel i første omgang å først fjerne evt. password fra både config.xml og klienten, og evt. heller sette det når du får forbindelsen i gang.
I config.xml er det i så fall passordet under <!-- Remote Command Server -->

Og port 36330 må være åpen på remote maskin ...
 

b-real skrev (10 timer siden):

Ingen GUI (eller jeg orker ikke koble til skjerm osv again på serveren)

Det er mulig å kjøre FAHControl på en annen pc og kople til serveren for å styre den (pause av/på, endre instillinger osv.)

Ut i fra "server status" oversikten ser det jo ut som at det er samme servere for "vanlig" som for beta.

Beta er mest forskningsmessig, og har egentlig lite med hvor bra serverne fungerer eller hvor lett det er å motta/sende en WU. Det er grovt sett, slik jeg forstår det, WU'er forskerne ikke er helt sikre på om vil "fungere" forskningsmessig eller at de tester ut nye algoritmer e.l.  Tror jeg.

ilpostino skrev (3 minutter siden):

På begge maskinene jeg folder på står 0.0.0.0 som collecting server.

Det er ikke nødvendigvis en feil/et problem, det kan bare bety at serveren som ga ut jobben også tar den i mot.