Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 34 reacties
Bron: Seagate

Seagate heeft gisteren aangekondigd dat haar high-end hardeschijven voorzien zullen worden van 'V optimized code'. V optimized code is een fancy naam voor betere software bij hardeschijven met 16MB cache geheugen om zo een constantere datastroom te kunnen garanderen, erg handig voor video editing (vandaar die V). Hardeschijven die met deze feature uitgerust worden zijn de Cheetah 73, de Cheetah 36LP en de Barracuda 180:

SCOTTS VALLEY, CA — 17 January 2001 — Having friends in Hollywood has its advantages, and Seagate Technology is leveraging its position as the entertainment industry's leading disc drive supplier to deliver higher-performance storage technology.

Seagate today announced the addition of exclusive new "V" optimized code on its large-cache Cheetah and Barracuda disc drives. Designed to meet the demanding requirements of professionals working with digital media, "V" optimized code allows 16-Mbyte cache-equipped disc drives to go to the next level of performance by minimizing the fluctuations that can occur when reading or writing bandwidth-intensive data such as digital video. The results? Large uncompressed video files can be stored, retrieved, and edited without fear of dropouts, screen freezes or data loss, delivering the most professional and highest quality results available today.

[...] Popular models featuring "V" optimized code include the 73.4-Gbyte Cheetah 73, the 36-Gbyte Cheetah 36LP, the 18-Gbyte Cheetah 36LP, and the recently announced 180-Gbyte Barracuda 180.

Lees meer over

Moderatie-faq Wijzig weergave

Reacties (34)

Tja , maar of het er ook sneller door wordt.

Volgens mij heeft een goede RAID-controller meer effect, laten ze daar lekker wat meer geheugen opgooien ... heeft veel meer zin IMO.
Het gaat hierbij juist om het gedrag in een RAID setup. Voor forse digitale video (HDTV) heb je datarates nodig van 100MB/s en meer. Dat haal je eigenlijk alleen met striping over meerdere Fibre Channel RAID arrays (wat een woorden). Sequentieel is dat goed te doen, maar voor een vlotte editing heb je random access nodig en ik kan me voorstellen dat intelligente en grote caches dan wel degelijk hun invloed hebben.
daar heb je echt geen meerdere fibre channel raid arrays voor nodig hoor .... pak een u160 raidcontroller en 4x atlas10k en je bent er ook ...
bovendien is de cache op een disk niet echt belangrijk meer in een array .. de raidcontroller cache is veel belangrijker .. en bij randoms is de rpm ook belangrijker ... 10k en 15k dus .....


was het niet zo dat av disken geen calibratie doen tusentijds ..bij normale schijven krijg je dan toch glitches in je stream ??
Volgens mij is dit ook reuze handig voor mensen die nog wel eens kampen met buffer-underruns tijdens het branden.
Maar dat is dan weer een keuze voor hun.
Of een nieuwe schijf of een nieuwe brander.
Dit zijn geen goedkope schijfjes. Je kunt dan beter een nieuwe schrijver met die fancy burnproof zooi of zo kopen.
Voor die prijs koop je volgens mij zelfs zo'n torentje die alles voor je doet EN een losse brander met burnproof :).

Daarnaast is video editing toch gewoon een prijzige bezigheid, je systeemeisen vliegen dan omhoog.
Toch vraag ik me af of die buffer echt zin heeft, betekent immers bij een leesoperatie dat je controller de datastroom niet aan kan, alleen bij een schrijfoperatie kan het in mijn ogen nuttig zijn.
Een meerkanaals RAID controller met veel geheugen lijkt mij soms ook voldoende.
Ehm... ik wil niet lullig doen maar video editing is al jaren een item in de computerwereld welke zeer vroeger al op 486 machines met standaard SCSI schijven gedaan werd, ok de baracuda's werden toen ook al aanbevolen.
Maar je kan je de vraag stellen als het editen van video deze hardware nodig heeft of juist alleen de huidige applicaties (lees ontwikkelingen) dergelijke kracht vragen.
Ik ken persoonlijk iemand die met een P-II 233 MHz met 64 Mb geheugen en 5400 toeren IDE schijven semi professioneel perfect video's monteert.
In die tijd werd meestal geen digitale video ge-edit. Dan kon je slechte kwaliteit beeldjes op je compu krijgen, alles editen zoals je het wilt hebben, en ging hij de tapedecks en analoge effecten-machines zo aansturen dat je een perfecte tape krijgt.
Met een 'normale' 30G 7200rpm IDE disk kan je al uitstekend je vakantie filmpjes editten :)
ff rechtstreeks uit je digitale camera via de firewire naar je disk lurken en gaan :)
Ik raadt je wel aan om een dedicated disk te gebruiken voor je filmpjes en ook de clustergrootte op de hoogst mogelijke waarde in te stellen (8>
I quote :"Volgens mij is dit ook reuze handig voor mensen die nog wel eens kampen met buffer-underruns tijdens het branden."

In princiepe wel ja ,maar een knappe jongen die met SCSI buffer underruns krijgt... of juist niet.... :)

En een gemiddelde burnfreak heeft toch een plextor burnproof.. :)

Het schijnt dat A-open binnenkort met een nieuwe brander op de markt komt die NOG nauwkeuriger brand dan de Plextor ;TWEAKERS houd dit in de gaten.
Zelf houd ik het bij m'n plextortje.
Dat cache geheugen lijkt me inderdaad wel realaxt tenminste een constante datastroom.

Een gemiddelde P200 houd het nog wel bij om te braneden op 8x vanaf een harddisk die 5400 RPM is met een a/time van 9 ms UDMA/33.
Pas als je gaat zitten k*tten houd die schijf het niet meer bij...

-=@@D=-
//kompleet off-topic mode//
Wat is er in godsnaam met de tijd gebeurd. Vroeger had je nog niet eens 16 Mb intern. En nu zit het al op je HD.

"hoeveel geheugen heb jij???
- 476 Mb totaal;
256 Mb intern, 128 Mb op de grafische kaart, 64 Mb op m'n geluidskaart en 16 Mb op m'n Hd, 8 Mb op m'n burner en 4 Mb op m'n proc."

//kompleet off topic mode uit//
Vroeger had je nog niet eens een 16mb HD :)
(begon met 10MB)
Dat heet "5" hoor.

De Seagate ST506 en 412, met 5 en 10 MB respectievelijk, die een hele HD-interface standaard naar zichzelf genoemd hebben.

Toen ook al Seagate :D
Misschien is de GoT-Kroeg iets voor jou? :)
Dat AV had niks te maken met het aanwezige geheugen....

Normale schijven bewegen om de zoveel tijd naar de rand van de schijf om te `hercalibrerenī ...

AV schijven deden dit zo weinig mogelijk (1 keer per min) wat schoken bij videoediting verminderde....
Deze schijven zullen nog wel hercalibreren, alleen heb je hier geen last van bij een buffer van 16Mb.

Dat hercalibreren doen ze omdat ze door de hitte uitzetten en het positioneringsmechanisme van de schrijf/lees kop niet meer goed functioneert.

Dus gewoon flink koelen die harddisks! }>
Ik vraag me af in hoeverre dat waar is. Want hij heeft inderdaad 16MB cache, maar stel je voor dat je een constante datatransfer hebt van precies de snelheid waarmee de schijf kan schrijven. Dan komt hij toch soms in de problemen omdat hij moet calibreren, wanneer hij dat doet kan hij hetgeen hij zou moeten opslaan even in de cache zetten, maar moet hij vaker calibreren, dus bij heel veel data, dan raakt de cache vol en ga je toch data verliezen. Kan ook andersom, wanneer je ervanuit gaat dat hij eerst de cache als een soort buffer volschrijft.
Ok ik geef toe dat dit zeer zelden zal voorkomen, maar juist bij videobewerking heb je lange tijd een zeer hoge transferrate. Het gaat dus wel alleen op wanneer de transferrate videodata precies overeenkomt met de maximale snelheid waarmee de schijf fysiek kan wegschrijven. Is die hoger dan zul je sowieso frames verliezen, ligt ie een stuk lager dan kan hij dat makkelijk met de cache opvangen.
Dat is niet erg waarschijnlijk, want zoals je nu suggereert is de gevraagde datatransfer precies gelijk aan de maximumtransfer van de HD...
Ja aan de maximum transferrate, dat is dus zonder dat ie moet calibreren. Een schijf kan voor een bepaalde tijd schrijven en dan moet ie calibreren en met de maximum schrijfsnelheid bedoel ik dus tussen het calibreren in.
Maar ik heb ook nog een ander puntje erbuiten gelaten, dat is namelijk dat een schijf sneller kan schrijven naarmate hij naar de meer naar buiten gelegen cylinders schrijft. Maarja was ook maar even een gedachtegang en zal in de praktijk ook bijna nooit voorkomen. Vroeg me af of het wel mogelijk was.
Ligt eraan, of je schijf de snelheid verhoogt naarmate ie meer naar het midden gaat of niet... (je hebt het zo ook bij cd-roms, CAV en CLV ), mijn HD ondervind dit wel, dat heb ik eens getest met HD Tack, die test om de x aantal mbīs de snelheid en zet dat in een grafiekje, dat was duidelijk een dalende lijn (aangenomen dat de eerste paar mbīs aan de buitenkant zitten...)...

Verder zal het moeilijker zijn om AV versies te maken van snelle (oge RPM) schijven, omdat de koppen sneller zullen opwarmen (is mijn hypothese...)..., en dan is het wel logisch dat ze grote buffers gaan gebruiken...

//off-topic
owja, ik heb de hele tijd niet genest lopen reageren, komt doortdat ik sinds kort Opera (win32) of Mozilla (linux, ok al iets langer, maar daar reageer ik niet zo vaak mee...) gebruik en ik zie nu dat die niet automatisch genest reageren als je op het kopje linksboven iemands reply klikt, dit moet je handmatig doen...
//off-topic
Ligt eraan, of je schijf de snelheid verhoogt naarmate ie meer naar het midden gaat of niet...
Zover ik weet is dat wel het geval. Kan me nog een discussie herinneren over Linux vs Windows en toen waren ze er dus alles bij aan het halen om de test zo eerlijk mogelijk te krijgen en daar werd ook gezegd dat ze bij het aanmaken van de partities moesten rekening houden. Dus wanneer ze beide OS'en wilden testen ze achter elkaar op dezelfde partitie zetten. Zo heb je enige controle over waar op de schijf (fysiek) gezien de data komt te staan.
Het was trouwens zo dat de schijf sneller werd naar buiten toe.
Het zou me ook niks verbazen als die schijven voor high-end servers wel instelbaar zijn om de transferrate een beetje constant te houden, bij servers zijn vertrouwd men op een constante data stroom, dan kan je niet hebben dat ie aan het eind van de partitie opeens inzakt...
Genest-vinkje is gefixed in Opera 5.02! :)

Keyboard-focus voor java-1.3 applets helaas nog niet :( maar je mag niet alles ineens verwachten he!
Voordeel van zo'n groot buffer is ook dat je toegangstijd ietsie lager wordt doordat je meer kans hebt dat je file nog in het cache zit. Ik denk dat mensen die met vele kleine files werken hier ook baat bij hebben.

Ik heb bij een bedrijf een apparte opslagserver mogen bewonderen die een gemiddelde toegangstijd van minder dan 4 !!! miliseconden kan realiseren doordat er 4 gig! aan cachegeheugen in zit verwerkt, afgezien van de raid configuratie. Compleet met laptop om hem te monitoren / in te stellen. Het grote voordeel van cache. Het compenseerd de zoektijden....

Correct me if i'm wrong.
uhm ..jij heb het over cache in de server ..niet op de disk .. de cache op de disk wordt direct geflushed..


ik denk dat ze een adaptive cache erin zetten ,dat houd in dat de cache langzamer naar de disk flushed als de datastoom lager wordt, dit om stilstaan te voorkomen[ zou glitches in de stream kunnen veroorzaken] .. dit wordt bijvoorbeeld al in tapedrives [dlt7000] gebruikt om de tape streamend te houden ...
Hehe eindelijk eens echt een nieuwe voorruitgang op HD's die dingen blijven op snelheid toch wel heel erg achter.
Geen Idee. Was een spannende grote kast met veel lawaai. Intern in die kast die diskaray met 4 gig geheugen. Deze kast is dan weer met glasvezel verbonden met de rest. Geheugen niet op de disk zelf idd maar heeft uiteindelijk het zelfde doel.

ERG OFFTOPIC:
tapedrive: naar ik weet mogen die nooit stil komen te staan omdat dat veel heen en weer gespoel opleverd en veel tijd kost. Onstream schijnt dat te hebben opgelost met een fluctuerende tapesnelheid. Maar onstream drives zijn niet voor grote bedrijven bedoeld. Lijkt mij. Meer MKB of nog kleiner. Blabla dwaal af etc.
Is het niet gewoon zo dat het hoog tijd werd dat de cache vergroot werd? het lijkt me toch dat dit een beetje in verhouding moet staan met de grootte van je HD. En aangezien die nu naar de 180 GB gaan, mag er best een enorme cache bij geprikt worden. Zo simpel is het toch gewoon?? De uitleg dus, niet de HD's...

da-Lynx
Waarom zou het niet mogelijk zijn om een PCI kaartje te fabrieken wat IDE RAID beheerst met de CPU usage van SCSI ??? (ongeveer 15 - 20 %) en daar gewoon een SDRAM slot op gooien ??
En die chip kan ook op -zeg- 0.25 micron gebakken worden met een lange pipeline ? of zie ik het te simpel ?

... :Z

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True