27 berichten aan het bekijken - 1 tot 27 (van in totaal 27)
  • Q:
    Bijdrager
    iDavid

    Meer geheugen of snellere CPU?

    Hallo,

    Ik ben met Macpar een archief van 8GB aan het uitpakken en ondetussen probeer ik een 1080p filmpje te kijken in VLC media player. Maar dat gaat niet! De film hapert gewoon enorm en kan eigenlijk niet kijken.

    In Activiteitsweergave wordt het mij niet echt duidelijk of mijn geheugen nou juist vol zit of nog heel veel vrij is. Zie sreenshot:

    Ik vind het wel jammer want ik mag toch verwachten dat een 2,4Ghz core2duo iMac deze processen kan trekken?

    Wat denken jullie hier van? Moet ik mijn geheugen vol gooien met 4GB?

    Bedankt!

    Bijdrager
    readefries

    Kun je het uitpaken niet renicen?

    Bijdrager
    CedricH

    Ik denk dat het vooral te wijten is aan het feit dat dit twee CPU intensieve processen zijn. Je CPU gebruik toonde waarschijnlijk 99 of 100% terwijl je die dingen aan het doen was.

    Als het nu uitzonderlijk eens was dat het hapert zou ik er me geen zorgen over maken, die iMac is sterk genoeg :wink:

    Bijdrager
    calvin

    En wat doet je CPU?

    Je vraagt CPU of RAM en laat alleen info over RAM zien.

    Maar alletwee de dingen die je doet zijn nogal CPU intensief dus ik denk eerder dat die op 100% staat, of zou het lezen en schrijven naar disk er iets mee te maken hebben?
    Macpar staat lekker te schrijven, en VLC te lezen, gaat niet lekker met maar 1 disk en dus maar 1 lees/schrijfarm…..

    Dus, iets meer info………………

    Bijdrager
    iDavid

    Het schijnt toch de HD te zijn, aangezien macpar zwaar aan het uitpakken is en VLC dus zwaar aan het lezen voor zo’n groot bestand.

    Daar valt dus niets aan te doen.

    Lid
    Noc

    Dit ligt puur aan de CPU hoor, dat kan hij gewoon niet trekken.

    Bijdrager
    iJoost

    Als je wilt weten of je genoeg geheugen hebt voor een bepaalde taak, dan moet je kijken naar de pageouts. Niet naar het aantal maar naar het gedrag ervan. Maar dat heb ik al -tig keer eerder hier uitgelegd… Weet je wat? Hier!

    Bijdrager
    hendrik ijzerbroot
    ”Noc”

    Dit ligt puur aan de CPU hoor, dat kan hij gewoon niet trekken.


    @iDavid
    :
    Dit heeft niets met de CPU of RAM te maken, maar simpelweg met het feit dat de lees en schrijf opdrachten van de HD afhankelijk zijn van hoe snel het mechanisme van de kop is.

    Ik draai Vuze (voorheen Azureus) en die moet ik meestal uit zetten wil ik een film in de Vuze map vloeiend draaien.

    Als ik (heb ik net even gedaan) vanaf één en de zelfde drive een film wil bekijken terwijl Vuze download en er ook nog iets uitgepakt wordt, staat de film gewoon stil, terwijl de som van het CPU verbruik beneden de 80% zit (40/40 dus aangezien ik twee CPU’s heb) Mijn vrije geheugen is dan 860 MB (plus 830 MB “inactief” wat feitelijk ook vrij is op dat moment, want dat is over van gestopte programma’s)

    Bijdrager
    MrAcid
    ”hendrik
    ”Noc”

    Dit ligt puur aan de CPU hoor, dat kan hij gewoon niet trekken.


    @iDavid
    :
    Dit heeft niets met de CPU of RAM te maken, maar simpelweg met het feit dat de lees en schrijf opdrachten van de HD afhankelijk zijn van hoe snel het mechanisme van de kop is.

    Ik draai Vuze (voorheen Azureus) en die moet ik meestal uit zetten wil ik een film in de Vuze map vloeiend draaien.

    Als ik (heb ik net even gedaan) vanaf één en de zelfde drive een film wil bekijken terwijl Vuze download en er ook nog iets uitgepakt wordt, staat de film gewoon stil, terwijl de som van het CPU verbruik beneden de 80% zit (40/40 dus aangezien ik twee CPU’s heb) Mijn vrije geheugen is dan 860 MB (plus 830 MB “inactief” wat feitelijk ook vrij is op dat moment, want dat is over van gestopte programma’s)

    Hier sluit ik mij bij aan. Het is zeer waarschijnlijk de HD die hier de beperkende factor is.

    Bijdrager
    hendrik ijzerbroot
    ”iJoost”

    Als je wilt weten of je genoeg geheugen hebt voor een bepaalde taak, dan moet je kijken naar de pageouts. Niet naar het aantal maar naar het gedrag ervan. Maar dat heb ik al -tig keer eerder hier uitgelegd… Weet je wat? Hier!

    Stil maar.:)
    In dit geval heeft het niets met het geheugen te maken. Gewoon de lees/schrijf snelheid (en reactie tijd) van een drive, tenslotte kan een hd maar één ding te gelijk, OF lezen, OF schrijven.

    Bijdrager
    arnout
    ”hendrik

    Stil maar.:)
    In dit geval heeft het niets met het geheugen te maken. Gewoon de lees/schrijf snelheid (en reactie tijd) van een drive, tenslotte kan een hd maar één ding te gelijk, OF lezen, OF schrijven.

    Maakt het dan nog verschil of je je schijf in partities hebt verdeeld?
    Dat zou dan nl. een sterk argument voor partioneren betekenen…

    Bijdrager
    sven-

    De volgende dingen spelen:

    – De HD moet 2 dingen tegelijk doen: een leesintensieve taak en een schrijfintensieve taak.
    – De CPU moet ook 2 dingen tegelijk en voor het afspelen van een 1080p H.264 film wordt al een aardig percentage van de capaciteit gebruikt.
    – Mogelijk is de GPU (videokaart) niet goed genoeg voor het afspelen van 1080p H.264 content.

    ”arnout”

    Maakt het dan nog verschil of je je schijf in partities hebt verdeeld?
    Dat zou dan nl. een sterk argument voor partioneren betekenen…

    Nee, dit maakt niets uit. Het is en blijft één schijf, of je nou één partitie hebt of 10.

    Bijdrager
    hendrik ijzerbroot
    ”arnout”
    ”hendrik

    Stil maar.:)
    In dit geval heeft het niets met het geheugen te maken. Gewoon de lees/schrijf snelheid (en reactie tijd) van een drive, tenslotte kan een hd maar één ding te gelijk, OF lezen, OF schrijven.

    Maakt het dan nog verschil of je je schijf in partities hebt verdeeld?
    Dat zou dan nl. een sterk argument voor partioneren betekenen…

    Nee dat maakt niets uit.
    Het probleem hier is, dat er teveel verschillende processen zijn die allemaal tegelijk de zelfde drive aan sturen
    Aangezien er maar één lees/schrijf opdracht tegelijk kan worden uitgevoerd en de kop maar op één plaats tegelijk kan zijn, moet het ene proces steeds op het andere wachten.

    2 of meer partities heeft alleen nut als je 2 systemen op één schijf wilt zetten, of om te voorkomen dat bij een crash, er in ieder geval nog een werkende partitie (dus volume) is. Qua snelheid maakt het praktisch niets uit. Het gaat een fractie sneller omdat de afstand waarover de kop verplaatst fysiek kleiner is.

    Bijdrager
    arnout

    Ok, duidelijk.
    Jammer:)

    Bijdrager
    iJoost
    ”arnout”

    Maakt het dan nog verschil of je je schijf in partities hebt verdeeld?

    Jawel. Partitioneren is een goed recept om ervoor te zorgen dat de schrijf/lees-kop gemiddeld nog grotere afstanden moet afleggen over het oppervlak van je harde schijf om bij de data te komen. Het is eigenlijk gewoon een hele grove fragmentatie. Dat kost je zeker performance.;-)

    Bijdrager
    hendrik ijzerbroot
    ”iJoost”
    ”arnout”

    Maakt het dan nog verschil of je je schijf in partities hebt verdeeld?

    Jawel. Partitioneren is een goed recept om ervoor te zorgen dat de schrijf/lees-kop gemiddeld nog grotere afstanden moet afleggen over het oppervlak van je harde schijf om bij de data te komen. Het is eigenlijk gewoon een hele grove fragmentatie. Dat kost je zeker performance.;-)

    Dat gaat alleen op bij wisselen tussen de twee partities (dus bij kopiëren tussen de twee volumes op één schijf)
    Bij lees / schrijf werkzaamheden op één en de zelfde partitie is de fysieke afstand voor de kop juist minder.

    Tenslotte moet je er wel twee partities op zetten wil je op één device twee systemen zetten, en het ene is dan echt niet trager omdat dat andere er op staat.

    Bijdrager
    tarun
    ”hendrik
    ”iJoost”

    Als je wilt weten of je genoeg geheugen hebt voor een bepaalde taak, dan moet je kijken naar de pageouts. Niet naar het aantal maar naar het gedrag ervan. Maar dat heb ik al -tig keer eerder hier uitgelegd… Weet je wat? Hier!

    Stil maar.:)
    In dit geval heeft het niets met het geheugen te maken. Gewoon de lees/schrijf snelheid (en reactie tijd) van een drive, tenslotte kan een hd maar één ding te gelijk, OF lezen, OF schrijven.

    Zou het een optie zijn één van de processen op een externe FireWire schijf uit te voeren. Theoretisch heb je dan twee leeskoppen die onafhankelijk van elkaar werken.

    Bijdrager
    hendrik ijzerbroot
    ”tarun”
    ”hendrik
    ”iJoost”

    Als je wilt weten of je genoeg geheugen hebt voor een bepaalde taak, dan moet je kijken naar de pageouts. Niet naar het aantal maar naar het gedrag ervan. Maar dat heb ik al -tig keer eerder hier uitgelegd… Weet je wat? Hier!

    Stil maar.:)
    In dit geval heeft het niets met het geheugen te maken. Gewoon de lees/schrijf snelheid (en reactie tijd) van een drive, tenslotte kan een hd maar één ding te gelijk, OF lezen, OF schrijven.

    Zou het een optie zijn één van de processen op een externe FireWire schijf uit te voeren. Theoretisch heb je dan twee leeskoppen die onafhankelijk van elkaar werken.

    Dat is nu precies (kennelijk) het probleem van de TS
    Je kunt in zo’n geval de film inderdaad op de ene en het uitpakken op de andere drive uitvoeren.
    Alles via één drive zit “multi-tasking” in de weg, maar met een extra drive gaat het gewoon soepeler.

    Moderator
    unSOUND
    ”tarun”

    Zou het een optie zijn één van de processen op een externe FireWire schijf uit te voeren. Theoretisch heb je dan twee leeskoppen die onafhankelijk van elkaar werken.

    Dit is inderdaad de oplossing. Het probleem zit hem namelijk in het controleren van de rar-delen door MacPar DeLuxe. Ieder bestand wordt in feite geopend en gecontroleerd, wat enorm veel schijfactiviteit oplevert, iedere andere taak heeft daar last van, zelfs kleine filmpjes. Daarom heb ik dus al mijn downloads op een andere schijf staan als de rest, zodat het unrarren niks anders in de weg zit.

    Bijdrager
    iJoost
    ”hendrik
    ”iJoost”
    ”arnout”

    Maakt het dan nog verschil of je je schijf in partities hebt verdeeld?

    Jawel. Partitioneren is een goed recept om ervoor te zorgen dat de schrijf/lees-kop gemiddeld nog grotere afstanden moet afleggen over het oppervlak van je harde schijf om bij de data te komen. Het is eigenlijk gewoon een hele grove fragmentatie. Dat kost je zeker performance.;-)

    Dat gaat alleen op bij wisselen tussen de twee partities (dus bij kopiëren tussen de twee volumes op één schijf)
    Bij lees / schrijf werkzaamheden op één en de zelfde partitie is de fysieke afstand voor de kop juist minder.

    Tenslotte moet je er wel twee partities op zetten wil je op één device twee systemen zetten, en het ene is dan echt niet trager omdat dat andere er op staat.

    Als je op een van de twee partities je systeem hebt staan en op de andere aan het werk bent, dan heb je al een situatie waarin ie van hot naar her moet met die kop. Noodzakelijk of niet partitioneren is slecht voor je performance.

    Bijdrager
    hendrik ijzerbroot
    ”iJoost”
    ”hendrik
    ”iJoost”
    ”arnout”

    Maakt het dan nog verschil of je je schijf in partities hebt verdeeld?

    Jawel. Partitioneren is een goed recept om ervoor te zorgen dat de schrijf/lees-kop gemiddeld nog grotere afstanden moet afleggen over het oppervlak van je harde schijf om bij de data te komen. Het is eigenlijk gewoon een hele grove fragmentatie. Dat kost je zeker performance.;-)

    Dat gaat alleen op bij wisselen tussen de twee partities (dus bij kopiëren tussen de twee volumes op één schijf)
    Bij lees / schrijf werkzaamheden op één en de zelfde partitie is de fysieke afstand voor de kop juist minder.

    Tenslotte moet je er wel twee partities op zetten wil je op één device twee systemen zetten, en het ene is dan echt niet trager omdat dat andere er op staat.

    Als je op een van de twee partities je systeem hebt staan en op de andere aan het werk bent, dan heb je al een situatie waarin ie van hot naar her moet met die kop. Noodzakelijk of niet partitioneren is slecht voor je performance.

    Zoals jij het stelt wel. Maar ik bedoelde dus op de ene partitie b.v.b. Tiger, en op de andere Leopard. 1 van de 2 doet dan niets, dus je werkt op één partitie en nooit op de andere, dus is de fysieke afstand voor de kop kleiner.
    En bovendien: bij 1 (dus grotere) partitie moet de kop uiteindelijk ook van hot naar her.

    Bijdrager
    iJoost

    Precies dat is waar de automatische defragmentatie van MacOS X z’n stinkende best voor doet. Om dat dus te minimaliseren. (Lees er eens wat over het is boeiende materie). Maar dan moet je dus niet als gebruiker moedwillig de grofste fragmentatie die je maar kunt bedenken er tegenaan gooien. Nogmaals, dat is gewoon niet slim. En als het moet dan moet het… maar het blijft jammer. Partitioneren, doe het niet! ‘T is geen PC… ;-P

    Bijdrager
    iNsane

    Probeer eerst in ieder geval eens een andere player. VLC (of eigenlijk ffmpeg) is nl. niet multithreaded. Hier (MBP 2.4) schokt een 1080p film bijna altijd in VLC, terwijl Plex ze afspeelt zonder ook maar een frame te droppen.

    Bijdrager
    sven-

    Dat komt omdat Plex (eigenlijk XBMC) op een andere manier de videobeelden decodeert. Daar waar programma’s als QuickTime Player en VLC gebruiken maken van de videokaart, maakt Plex gebruik van de CPU, en dat levert meestal betere prestaties op.

    Moderator
    unSOUND
    ”iNsane”

    Probeer eerst in ieder geval eens een andere player.

    Ik weet niet tegen wie je dit zegt, want bij de topicstarter was de oorzaak het feit dat d harde schijf het veel te druk had… Een andere player zal daar weinig aan veranderen.

    Bijdrager
    hendrik ijzerbroot
    ”iJoost”

    Precies dat is waar de automatische defragmentatie van MacOS X z’n stinkende best voor doet. Om dat dus te minimaliseren. (Lees er eens wat over het is boeiende materie). Maar dan moet je dus niet als gebruiker moedwillig de grofste fragmentatie die je maar kunt bedenken er tegenaan gooien. Nogmaals, dat is gewoon niet slim. En als het moet dan moet het… maar het blijft jammer. Partitioneren, doe het niet! ‘T is geen PC… ;-P

    Even voor de duidelijkheid, ik heb zelf ook gewoon één partitie hoor. (2e systeem staat op een ander device)

    Bijdrager
    iJoost

    Jij stelde de vraag toch ook niet? Dat was arnout…;-)

27 berichten aan het bekijken - 1 tot 27 (van in totaal 27)

Je moet ingelogd zijn om een reactie op dit onderwerp te kunnen geven.