Real time scheduler krijgt plaats in Linux-kernel

Versie 2.6.23 van de Linux-kernel zal voorzien worden van een nieuwe scheduler. Deze software zorgt ervoor dat ieder proces voldoende processortijd krijgt toegewezen om zijn taken uit te voeren in een multitaskingomgeving.

Programmeur Ingo Molnar heeft de nieuwe scheduler als volgt omschreven: 'CFS basically models an "ideal, precise multi-tasking cpu" on real hardware'. Een 'Ideal multi-tasking cpu' is een processor die beschikt over een rekenkracht van exact honderd procent en die ieder proces op dezelfde snelheid laat draaien. Als een dergelijke cpu twee processen moet uitvoeren, krijgt elk ervan precies de helft van de rekentijd toegewezen om de processen parallel uit te voeren. In werkelijkheid kan er op één processorcore slechts één taak tegelijk uitgevoerd worden, waardoor andere taken moeten wachten. Verder krijgt de actieve taak ten opzichte van de wachtende taken de beschikking over een onevenredige hoeveelheid cpu-tijd.

De Completely Fair Scheduler (CFS), zoals de scheduler heet, rekent per taak uit hoe groot de wachttijd oftewel tijdsonbalans is. Voor de helderheid, op de hierboven beschreven ideale cpu zou deze wachttijd altijd 0 nanoseconden bedragen, omdat iedere taak parallel evenveel tijd toegewezen zou krijgen. Verder zorgt CFS ervoor dat de taak met de grootste wachttijd het eerste wordt uitgevoerd door de processor. Anders gezegd, de taak die het hardst zit te wachten op rekentijd wordt als eerste uitgevoerd. Het effect hiervan is dat er een situatie ontstaat die sterk lijkt op ideal multitasking hardware. Dat is belangrijk voordeel voor real time applicaties, die op de nanoseconde precies moeten weten wanneer acties verwacht kunnen worden.

Reacties (77)

[Bluefan]

Zou de Completely Fair Scheduler (CFS) taken met hogere prioriteit voorang geven zodat die realtime kunnen draaien? Er staat "Verder zorgt CFS ervoor dat de taak met de grootste wachttijd het eerste wordt uitgevoerd door de processor. Anders gezegd, de taak die het hardst zit te wachten op rekentijd wordt als eerste uitgevoerd." Maar sommige processen mogen best even wachten als je een realtime systeem hebt waar niet alles realtime moet gebeuren (overige processen die buiten de belangrijke takens taan).

[burne]

De huidige infrastructuur aan prioriteiten blijft gewoon bestaan en telt gewoon mee in de selectie van taken om te draaien. Het verhaal in de nieuwspost beschrijft de situatie als alle taken een gelijke prioriteit hebben. Zodra een taak een hogere prioriteit heeft krijgt 'ie evenredig met z'n prioriteit meer kans om te draaien.

[Michael]

Voor wat vergelijkingen (welke niet 100% correct zijn volgens de maker ervan) zie http://people.freebsd.org/~jeff/sysbench.png

Daar komt freebsd 7.0 met de nieuwe sched_smp een stuk beter eruit dan deze scheduler.

Zie http://jeffr-tech.livejournal.com/ voor meer informatie over de schedulers en verschillende vergelijkingen

[Verwijderd]

Yup, wat bij mij wederom de vraag oproept:
Waarom gebruiken mensen linux?
Omdat linux toevallig het eerste was dat ze tegenkwamen toen ze per se van Windows af wilden?
Of hebben ze echt gekeken naar wat nou technisch het beste in elkaar steekt?

Ik hoor hier op tweakers vooral vaak dat linux zoveel beter is dan Windows... alsof ze dus een technisch bewuste keuze hebben gemaakt.
Maar dit soort benchmarks toont aan dat linux ook niet bepaald het ultieme OS is. CFS is zeker een verbetering, want de oude situatie was een ramp (zie hoe het systeem bij meer dan 8 threads (meer dan 1 thread per core) gewoon helemaal inzakt). FreeBSD had dat ook met de oude scheduler al niet, en presteerde daarom veel beter onder load voor bv zware websites of databases (ironisch genoeg presteert ook Windows beter dan de oude linux-scheduler onder zware load).

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:12]

[Jungian]

Waarom gebruiken mensen linux?

• _Veel_ beter package management. De front-ends van DPKG en RPM, Portage,pacman en overige package managers zijn superieur aan de brakke 150.000 tooltjes die je nodig hebt om je FreeBSD-installatie up-to-date en schoon te houden _zonder_ overbodige dependencies (pkg_cutleaves is te triest voor woorden en pkg_deinstall is niet bruikbaar als je een package delete en _daarna_ besluit de dependencies weg te gooien).
• Betere hardwareondersteuning (met wireless als triest dieptepunt bij FreeBSD).
• Linux heeft geen brakke agpgart, met de snelheid van een stervende schildpad (je mag van geluk spreken dat Nvidia wel een degelijke agpgart gefixed heeft).
• OSS op FreeBSD is veel beter dan OSS op Linux, maar komt niet eens in de buurt van ALSA.

Ik zou graag FreeBSD gebruiken, o.a. omdat de ports tree vrijwel altijd up-to-date is en een gigantische hoeveelheid packages bevat, maar brakheden als hierboven houden me er vanaf (en dit is nog maar een kort lijstje).

[Reactie gewijzigd door Jungian op 23 juli 2024 00:12]

[Verwijderd]

_Veel_ beter package management. De front-ends van DPKG en RPM, Portage,pacman en overige package managers zijn superieur aan de brakke 150.000 tooltjes die je nodig hebt om je FreeBSD-installatie up-to-date en schoon te houden _zonder_ overbodige dependencies (pkg_cutleaves is te triest voor woorden en pkg_deinstall is niet bruikbaar als je een package delete en _daarna_ besluit de dependencies weg te gooien).

Beetje overdreven.
Er zijn best goede tools voor, en sinds enige tijd is er ook KPackage, kun je in KDE mooi grafisch je packages managen.
Afgezien daarvan reken ik een systeem niet af op het managen van packages, want dat is niet de core-business. Software installeren doe ik omdat ik de software wil gebruiken, niet als doel op zich.

Betere hardwareondersteuning (met wireless als triest dieptepunt bij FreeBSD).Linux heeft geen brakke agpgart, met de snelheid van een stervende schildpad (je mag van geluk spreken dat Nvidia wel een degelijke agpgart gefixed heeft).
OSS op FreeBSD is veel beter dan OSS op Linux, maar komt niet eens in de buurt van ALSA.

Dit lijken me vooral issues voor desktop-gebruik. Ik zat meer aan (zware) servers/databases te denken, want de schaalbaarheid en robuustheid van FreeBSD steekt toch wel significant boven linux uit (hoewel CFS een stap in de goede richting is). Bij dergelijke hardware heb je ook minder problemen met driver-ondersteuning, dat is meer de hardware waar de focus op ligt bij de ontwikkelaars. Vooral Dell wordt heel goed ondersteund.

Dingen als agpgart en ALSA doen me denken aan spelletjes etc... en hoewel linux daar misschien beter is dan FreeBSD, zou ik Windows boven beiden verkiezen. FreeBSD is wat mij betreft echt een server-OS, en linux eigenlijk ook, al kun je daar iets meer mee op de desktop (hoewel dat ook weer betrekkelijk is... Gewoon OpenOffice, Firefox, Gaim, Thunderbird etc doet het op FreeBSD ook uitstekend natuurlijk).
Ik gebruik zelf FreeBSD voor server-taken en Windows op de desktop.

Iedereen die FreeBSD kan draaien, zou dat moeten doen in plaats van linux, naar mijn mening. Een site als tweakers.net zou ook prima op FreeBSD kunnen draaien. Tweakers willen toch het beste? FreeBSD heeft dan misschien wat praktische issues, maar die gelden niet voor iedereen, en technisch is het wel degelijk beter dan linux.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:12]

[Jungian]

Beetje overdreven.
Er zijn best goede tools voor, en sinds enige tijd is er ook KPackage, kun je in KDE mooi grafisch je packages managen.

Grafisch packages managen is een tweede (en overbodige) stap. Als ik op een mooie dag besluit om op een volledige KDE-desktop Brasero te zetten en om deze dan met pkg_delete (en niet pkg_deinstall) weg te gooien, dan heb je de poppen aan het dansen en kun je aan de slag met pkg_cutleaves (ruktool). Jij hebt daar blijkbaar geen problemen mee, helemaal omdat je FreeBSD al niet als desktop OS ziet.

Dingen als agpgart en ALSA doen me denken aan spelletjes etc...

Ga je eerst maar even inlezen

Ik gebruik zelf FreeBSD voor server-taken en Windows op de desktop.

En ik gebruik praktisch alleen Linux, met een uitstapje naar Windows (aparte machine) als het echt nodig is. Ik hou van een schoon, goed georganiseerd systeem (de kernel zelf schijnt daar steeds minder binnen te passen trouwens ).

Iedereen die FreeBSD kan draaien, zou dat moeten doen in plaats van linux, naar mijn mening. Een site als tweakers.net zou ook prima op FreeBSD kunnen draaien.

Als ik er niet helemaal naast zit worden de packages binnen een release niet bijgewerkt en ben je aangewezen op "STABLE" en vrienden (STABLE wil je niet op een server hebben) ?

Leuk stukje over het geluidssysteem van Windows trouwens (hierboven)

[Reactie gewijzigd door Jungian op 23 juli 2024 00:12]

[Laurens-R]

Prachtig voor servers. Voor linux als desktop wat minder. 'Completely fair' is ideaal in een server omgeving maar minder in een desktop omgeving. Ik vraag me af hoeveel goeds dit doet voor de integratie van linux op de desktop. Ben benieuwd in hoeverre dit de ervaring van normale gebruikers (in bijvoorbeeld Ubuntu) zal beinvloeden. Je zal wellicht geen significant verschil zien, maar veel gebruikers hebben toch onbewust wel snel door dat de OS/applicatie toch anders reageert qua tijd etc.

Juist binnen een desktop omgeving is het gewenst als desktop applicaties meer processortijd krijgen dan de achtergrond processen. En juist die voorgrond applicaties bepalen voor de gemiddelde gebruiker de ervaring van het OS.

edit: Weet iemand in hoeverre dit controleren valt in het nieuwe systeem?

[Reactie gewijzigd door Laurens-R op 23 juli 2024 00:12]

[YaPP]

Prachtig voor servers. Voor linux als desktop wat minder.

Dat mag je dan wel toelichten.. ;-)
Ik verwacht namelijk dat het voor desktops wel gaat uitmaken. Lees deze comment maar op slashdot. Bij deze een toelichting:

De taak van de scheduler is alle processen inplannen. (een "proces" is een geladen programma). Ieder proces krijgt bijvoorbeeld 10ms, en daarna is de volgende aan de beurt. Daardoor lijkt je computer meerdere dingen tegelijk te doen. In de werkelijkheid wisselt deze constant tussen de actieve programma's.

Alleen is het de kunst om dit slim te verdelen. Er wordt een volgorde bepaald waarin de processen uitgevoerd moeten worden, en deze volgorde wordt regelmatig aangepast. Een proces wat net veel CPU tijd gebruikt heeft wordt achteraan de rij geplaatst, en een proces wat lang op de schijf moest wachten wordt meer vooraan gezet.

De oude Linux scheduler (SD) keek echter alleen naar processen die CPU gebruikten (=runnable). De nieuwe Linux scheduler (CFS) houd ook rekening met de processen die wachten op iets (=sleeping). Dat zijn met name interactieve processen, die een tijd lang niets doen, en bij een muis of toetsenbord handeling pas weer in actie komen.

Dit maakt verschil bij de volgende situatie:
- proces A is met een zware berekening bezig. Iedere keer als het de beurt krijgt van de scheduler gebruikt het 100% van de CPU.
- proces B gebruikt gemiddeld maar 50% van de CPU bij zijn beurten, het wacht de rest van de tijd op invoer.

Omdat hier meerdere processen de CPU willen gebruiken wordt dit opgedeeld.
- Bij de oude scheduler (SD) krijgt proces A 66% van de tijd de CPU, en proces B 33% van de tijd.
- Bij CFS wordt het slapende proces ook meegenomen, dus wordt de tijd 50% voor beidde.

Om het nog eerlijker te maken wordt het het (ex-)slapende proces verder vooraan de rij geplaatst, zodat het letterlijk sneller aan de beurt is bij de CPU. Het nadeel van een tijd slapen (dus geen CPU tijd vragen) wordt hiermee opgeheven, wat interactieve processen zoals desktop applicaties een snellere reactietijd geeft. Ook is CFS beter in staat de processen beter te verdelen over de cores van je CPU.

[Reactie gewijzigd door YaPP op 23 juli 2024 00:12]

[user109731]

Volgens de maker en ervaringen van gebruikers is de scheduler juist zeer geschikt voor desktops, en zou het de gebruikservaring moeten verbeteren. Volgens mij was het zelfs 1 van de doelstellingen

En hij is ook nog wat te tunen:

There is only one central tunable:
/proc/sys/kernel/sched_granularity_ns
which can be used to tune the scheduler from 'desktop' (low latencies) to 'server' (good batching) workloads. It defaults to a setting suitable for desktop workloads. SCHED_BATCH is handled by the CFS scheduler module too.

(Er word trouwens ook gewerkt aan group scheduling, iets wat Linus graag in de kernel wil. Dus als 2 users actief zijn en user A is aan het tekstverwerken, en user B start 100 zware processen, dan word de CPU toch eerlijk verdeeld over de twee gebruikers. Erg leuk allemaal )

[Reactie gewijzigd door user109731 op 23 juli 2024 00:12]

[Bluefan]

Wat ik wel weet is dat:

Onder windows als je 1 zwaar proces is, je hele computer zo traag als dikke stront is.
Onder Linux je nog gerust verder kan met andere dingen, maar met wat geduld erbij.
Onder Irix er bijna geen vuiltje aan de lucht is.

Die laatste is trouwens erg bekend om zijn goede prestaties en eigenschappen in realtime omgevingen. Dus laat dat realtime maar komen
Gewoon dus omdat dan niet 1 proces de rest van z'n tijd kan beroven, en dan akn je optimaal blijven werken.

[Reactie gewijzigd door Bluefan op 23 juli 2024 00:12]

[Verwijderd]

Ik heb op dit moment Orthos draaien om mn CPU even te stresstesten. Beiden cores zitten op 100% en ik kan nog steeds gewoon rap browsen, torrenten, msn-en etc. . Windows is zo slecht nog niet.

[Verwijderd]

Dan ben jij toch de enige want als ik onder windows een mpeg aan het recoden ben dan gaat al de rest heel erg tot irriterend traag vooruit.

[Haan]

Op de een of andere manier belast Orthos de cpu wel voor 100%, maar dat heeft inderdaad nauwelijks invloed op de prestaties van de andere programma's. Terwijl als je met een ander soort programma (bijvoorbeeld encoden zoals Green.Velvet ook zegt) je cores 100% belast, dit wel echt merkbaar vertraging oplevert.. Blijkbaar is die 100% belasting van Orthos toch niet zo 100%

[Jesse]

Wat ik hier vaak merk is dat hdd-belasting veel harder in de desktop-ervaring hakt dan cpu-belasting. Je kan probleemloos je cpu stresstesten of een koe draaien en nog steeds lekker werken. (Ik heb het dus over Windows) Ga ik echter iets schijf intensiefs doen (virus of adware scanner bijvoorbeeld) dan kan je heel wat minder lekker doorwerken, terwijl de proc misschien een keer voor 60% gebruikt word.

[Reactie gewijzigd door Jesse op 23 juli 2024 00:12]

[comecme]

Wellicht gaat het erom of die CPU-tijd aan de kernel of aan de applicatie wordt besteed? Je kunt in de Task Manager de kernel times weergeven (Tab Performance, dan View | Show Kernel Times). Ik denk dat als de kernel times hoog zijn de PC traag reageert.

[PolarBear]

Wat is dat nu weer voor rant op Windows? Kan je het ook met bronnen onderbouwen?

[Jimbolino]

Windows heeft gui componenten op kernel niveau draaien, waarschijnlijk ervaart Bluefan problemen als er een aplicatie is gecrashed. (en dat gevolgen heeft op de performance van de kernel)

[Pietervs]

Nou, ervaring. Laat bijvoorbeeld McAfee maar eens een full-scan uitvoeren op je C: schijf. Zeker in de laatste versie komt het er op neer, dat de PC nagenoeg onbruikbaar is, tenzij je de prioriteit lager zet...

[elteck]

Dat hangt heel erg van de hardware af. Als je een IDE/ATA harde schijf hebt, dan gaat schijf communicatie niet goed samen met andere taken, en staat je machine zo goed als vast bij veel schijf verkeer. SCSI/SATA e.d. zijn wat dat betreft veel beter. Vandaar dat oudere CD spelers nogal eens een machine lam kunnen leggen.

Met Windows is mijn ervaring dat als je 1 core / processor hebt, hij erg traag wordt zodra een programma 100% cpu nodig heeft. Maar zodra je medere cores hebt, hij best wel efficient is. Ook al heb je met twee cores 3 programmas 100% staan gaat het nog steeds goed.
De enige verklaring die ik kan bedenken voor de slechte performance bij 1 core is dat Windows mischien op gamen is geoptimalizeerd en bij een core een programma alle resources geeft?

[Verwijderd]

Dat hangt heel erg van de hardware af. Als je een IDE/ATA harde schijf hebt, dan gaat schijf communicatie niet goed samen met andere taken, en staat je machine zo goed als vast bij veel schijf verkeer. SCSI/SATA e.d. zijn wat dat betreft veel beter. Vandaar dat oudere CD spelers nogal eens een machine lam kunnen leggen.

Mijn ervaring is dat de controller zelf ook een hoop verschil kan maken. Zo legde m'n KT133A-chipset de CPU redelijk lam bij disk I/O, waar m'n i810-chipset heel soepel draaide, ook al had de KT133A een AthlonXP 1800+ en de ander een Celeron 1000 (PIII-familie), beiden met identieke Maxtor IDE-schijven op UDMA100.
Nou weet ik niet in hoeverre het lag aan de hardware, en in hoeverre aan de software (driver), maar de een liep veel 'soepeler' dan de ander (eigenlijk werkte de Celeron prettiger, zolang je geen CPU-intensieve dingen deed). Het verschil tussen die 810 en m'n latere SATA-systeem is verwaarloosbaar, maar de vooruitgang van de KT133A is groot. Niet alleen loopt de harddisk sneller, maar ook 'onafhankelijker' van het systeem.
Mijn ervaring is wel dat Intel altijd erg goede controllers en drivers had, zelfs bij m'n P133 met Triton chipset liep het al heel soepel onder NT4.

De enige verklaring die ik kan bedenken voor de slechte performance bij 1 core is dat Windows mischien op gamen is geoptimalizeerd en bij een core een programma alle resources geeft?

Het is inderdaad 'by design', maar wat noem je 'slechte performance'?
Het is overigens niet specifiek op gamen gericht, maar wel op het maximaliseren van de performance van de foreground-applicatie in het algemeen. Dat is dus juist goede performance. De keerzijde is dat background-processen dus minder tijd krijgen (maar daarom draaien ze toch in de background?).
Zoals ik elders al zei, je kunt het gewoon omschakelen, wat vooral voor servers handig is... resources zo gelijkmatig mogelijk over alle processen verdelen. Ik meen dat Windows Server standaard ook hierop staat.

Eigenlijk is de linux-scheduler gewoon eenvoudiger dan die van Windows, en omdat hij niet zo veel probeert te boosten, blijven alle processen ongeveer even goed reageren. Nadeel is dan dus dat je wat minder resources krijgt voor de applicatie waar je op dat moment in werkt... Maar dat wordt nu een beetje een achterhaald concept, nu dualcores standaard zijn, en CPUs toch al dermate snel zijn dat je niet meer op die paar cycles meer of minder hoeft te kijken.
De strategie van Windows bij meer dan 1 core is idd al wat anders, minder 'extreem' dan op een singlecore. Het fenomeen van een foreground-applicatie die de rest wat kreupel maakt zal dus ook spoedig tot het verleden horen.

[Verwijderd]

Onder windows als je 1 zwaar proces is, je hele computer zo traag als dikke stront is.

Ga naar System Properties, tabblad 'Advanced', klik op 'Settings' onder 'Performance options', kies weer tabblad 'Advanced', en schakel 'Adjust for best performance of:' over van 'Programs' naar 'Background services'.

Voila, een round-robin-achtige scheduler zoals bekend van de meeste *nix/serversystemen.

(Om nog even terug te komen op de post hierboven aangaande realtime DSP... Cubase raadt aan om in Windows deze optie om te zetten naar 'Background services').

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:12]

[Pietervs]

Waar baseer je dat nou op? Ik zeg niet dat je ongelijk hebt, maar verbaas me hier wel over. Mijn PC is dual-boot WindowsXP/Ubuntu. Om Ubuntu op te starten heeft mijn PC toch echt zowat een minuut minder nodig voor ik mijn GUI heb dan wanner ik Windows opstart. Ook Firefox start een stuk sneller op onder Ubuntu als onder XP, zelfde geldt voor Thunderbird (hoewel ik daar weer andere probleempjes mee heb als onder XP).

[mtak]

Ja mod me maar omlaag. Dat is het enige wat je kan doen als je geen argumenten meer hebt...

Gelukkig is je eigen mening WEL zo goed onderbouwd....

[daft_dutch]

Goed doen we de test.met de laatste Linux/gnu software en de laatste microsoft software. (De Gui moet natuurlijk wel beschermd zijn tegen de laatste exploits)

en voor de gein pakken we een 533Mhz Pctje
es kijken wat er gebeurt

[MikeN]

Eh, is dit nou de default vanaf 2.6.23? Als dat zo is is het weer te belachelijk voor woorden dat er in een supposed-to-be stable kernel series _wederom_ een basisonderdeel van de kernel wordt omgegooid. Eea zal ongetwijfeld tot regressies leiden, houdt dat soort troep lekker in een andere tree...

[Keeper of the Keys]

2.6.23 Is een ontwikkeling kernel, 2.6.22 is de officiele stable (zie www.kernel.org).
Als ik me niet vergis is het al vrij lang zo en bij meer projecten, ongelijke nummers zijn development versies en gelijke nummers zijn de stabiele producten van de ontwikkeling.
(Een ander voorbeeld van zo'n versie nummering is gnome)

[MikeN]

Vroeger was het zo dat 2.5 de development was en 2.4 de stable. Met 2.6 hebben ze dat hele zaakje afgeschaft gezien oppergoeroe Linus geen zin had om een 2.7 tree bij te houden. In plaats daarvan is ervoor gekozen om de losse releases iets verder door te ontwikkelen (2.6.x.1, 2.6.x.2 enz.) en wordt er getest in de -mm tree.

Praktijk wijst echter uit dat wijzigingen met slechts een paar maanden testing in de stable tree terechtkomen en er continu regressies optreden. Linus is hier zelf ook niet tevreden over maar blijft toch vasthouden aan de "trap alles maar in 2.6" attitude. Het is te idioot voor woorden dat gedurende de development van de kernelseries waar veel mensen op draaien vanalles wordt omgegooid, van ide subsystems tot devfs/udev en van proces schedulers tot i/o, alles is al aan de beurt geweest.

[Pietervs]

hmmm, klinkt of je iets hebt tegen vooruitgang?
Iets sereneuzer: Als er binnen de ontwikkelomgeving wordt besloten dat iets een daadwerkelijke verbetering is voor de kernel, en uit de unstable releases blijkt dat het ook goed werkt in de "real world", waarom zouden ze het dan niet opnemen in de nieuwe stable?

Maar zoals ddofborg al zegt: ik zou ook graag benchmarks willen zien, en dan iets beter gedocumenteerd als de voorbeelden van Michael (hierboven).

[frogger3d]

Dit slaat nergens op.. Voor real-time applicaties heb je adeos met rtai/lxrt o.i.d. nodig. Hiermee kan je naar harde real-time mode switchen zodat je real-time programma niet onderbroken wordt door andere programma's en de kernel.

Een completely fair scheduler maakt het makkelijker om te schatten hoe snel iets klaar zal zijn, maar is niet afdoende voor echte real-time toepassingen.

edit: suggestie voor nieuwe titel: 'Linux krijgt alweer een nieuwe scheduler'

[Reactie gewijzigd door frogger3d op 23 juli 2024 00:12]

[freggy]

Het artikel suggereert inderdaad dat dingen als Xenomai of RTAI in de kernel zijn opgenomen, wat dus helemaal niet het geval is. Alleen Xenomai en RTAI zijn in staat om "hard real time" toepassingen te maken, zoals nodig voor bijvoorbeeld de besturing van motoren en dergelijke... De standaard Linuxkernel (en de kernel van andere general-purpose besturingssystemen) halen nooit de latency's die daarvoor nodig zijn.

Deze scheduler heeft dus niks met real time maken. De hoofdtaak van CFS is ervoor te zorgen dat de verschillende tasks tegelijkertijd op de machine draaien, elk voldoende CPU-tijd krijgen, zonder dat ze mekaar teveel voor de voeten lopen. Typisch zou met CFS bijvoorbeeld het tijdelijk haperen van muziek die aan het spelen is terwijl je andere zware taken op de machine doet, moeten vermeden worden. De machine zou met dergelijke belasting toch behoorlijk responsive moeten blijven.

De CFS scheduler is gebaseerd op de ideeën van de SD scheduler van Con Kolivas, die al veel langer bezig was met het ontwikkelen van patches om de responsiviteit van Linux desktops te verbeteren, maar onlangs beslist heeft om die ontwikkeling te staken, na meningsverscillen en getroll ivm zijn werk.

Zie ook http://www.linuxdevices.com/articles/AT8906594941.html voor het verschil tussen interrupt latency en scheduler latency.

[Reactie gewijzigd door freggy op 23 juli 2024 00:12]

[Verwijderd]

Inderdaad, scheduling en real-time zijn in principe tegengesteld aan elkaar.

[Verwijderd]

Hangt er vanaf welke real-time je bedoelt. Het verlopen van de gebruikerservaring zodat die zodanig is dat er geen merkbare vertraging is voor de gebruiker of real-time in de zin van de tijd die een proces nodig heeft en deze gegarandeerd altijd deze deadline haalt. Beide zijn real-time maar afhankelijk van wat je bedoelt.

[Verwijderd]

Als we het over kernels hebben is er maar 1 interpretatie van real time mogelijk, en die heeft niks met de gebruikers ervaring te maken. Voor real time toepassingen is er in de regel geen "gebruikers ervaring", en als die er al is is die compleet onbelangrijk.
Het gaat hier om systemen die niet kunnen werken als er ook maar 1 nano seconde vertraging optreedt om wat voor reden dan ook.

Een gebruikers ervaring lijkt me per definitie niet real time, er is altijd de vertraging veroorzaakt door de gebruiker. Ik heb het niet over real time 3D of een leuke desktop, het gaat hier om kritische systemen.

[moto-moi]

Een completely fair scheduler maakt het makkelijker om te schatten hoe snel iets klaar zal zijn, maar is niet afdoende voor echte real-time toepassingen.

Er zijn 2 manieren om tot een geniaal systeem te komen, het programmeren en pas vrijgeven als het helemaal af is, of het incrementele model. Linux is al jaren een voorbeeld van het laatste. Uiteraard is Linux er nog niet op dit gebied, maar er is nu wel een kleine stap gedaan, da's toch niet zo vreselijk loos?

[humbug]

Er is niet vreselijk veel loos maar ik denk dat iedereen die iets van real-time applicaties weet nogal "verrast" was door deze titel. de inhoud van het artikel valt dan toch redelijk tegen. De titel van het artikel dekt de lading gewoon niet, maar voor linux is het waarschijnlijk wel weer een stapje vooruit.

[Emmef]

Dit betekent zeker NIET dat de complete preemptible kernel patches van Ingo worden doorgevoerd in de kernel?

Real time scheduling is heel mooi. Maar voor (professionele) audio heb je ook een low-latency kernel nodig (heel toevallig worden die patches gemaakt dor Ingo Molnar): elke driver in je kernel moet (voor zover mogelijk) compleet preemptible zijn. Dat staat los van de scheduling. Goed shcdulen OK, maar als je ide-module niet preemptible is, moet de volgende taak toch ECHT wachten, tot de ide-module klaar is...

En dan mis je net je geluisdfragment

[Reactie gewijzigd door Emmef op 23 juli 2024 00:12]

[fraggie]

Mis een voorbeeld waar realtime gebruikt word..

[Bluefan]

In muziekstudio's waar de computer als ingewikkelde DSP moet dienen
Bij realtime videobewerken, zoals in studio's die live uitzenden.
In al die gevallen mag beeld/geluid niet haperen en moet er hard aan gewerkt worden. En dit zijn maar 2 toepassingen, denk ook eens aan medische apparatuur en nog veel meer.

[Verwijderd]

In muziekstudio's waar de computer als ingewikkelde DSP moet dienen

Valt wel mee hoor. Meestal gebruikt men daar gewoon een Mac of PC met Protools of VST-effecten.
Zowel MacOS als Windows zijn technisch gezien geen realtime-OSen, ook al komen ze dicht genoeg in de buurt om praktisch gebruikt te worden in dit soort situaties.
Over het algemeen zorg je gewoon dat je meer processorkracht hebt dan nodig (wat tegenwoordig niet echt een probleem meer is, cores genoeg). Zolang je computer niet tegen de 100% belasting aan zit, kun je dan 'realtime' werken.
(Een echte realtime-scheduler heeft flink wat meer overhead, dus dan kun je per definitie al niet echt 100% van je CPU gebruiken voor de software... de vraag is wat er in de praktijk nou het beste vanaf komt).

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:12]

[Verwijderd]

Zolang je computer niet tegen de 100% belasting aan zit, kun je dan 'realtime' werken.

Wat je schrijft is niet waar.

Het geluid dat uit je computer komt wordt eerst gebufferd, dit geeft latency (tijdsvertraging). Om bijv. mee te zingen/spelen en tegelijk om te nemen, moet deze vertraging zo kort mogelijk zijn. Voor real-time is 2ms latency acceptabel; als je geen real-time module in je kernel hebt is deze latency al gauw 70-100ms, en dat merk je echt wel als je meespeelt.

Apple heeft inderdaad low-latency performance, terwijl Windows weer niet.
Voor Linux moet je deze soms zelf in de kernel compilen, maar je haalt dan met gemak 2ms.

Voor bijv professionele software voor Linux
http://www.ardour.org
http://www.ardour.org/files/main-screenshot-big.png

[Verwijderd]

Wat je schrijft is niet waar.

Wat ik schrijf is de praktijk. Ik doe het al jaren. Zie hier mijn opnamen: http://www.soundclick.com/scali. Vrijwel alles met Windows opgenomen in Cubase, met een Terratec EWX 24/96 kaart via ASIO. Realtime multitracken dus. Soms ook realtime effecten toegevoegd.

Voor real-time is 2ms latency acceptabel; als je geen real-time module in je kernel hebt is deze latency al gauw 70-100ms, en dat merk je echt wel als je meespeelt.

Daarvoor is de ASIO-standaard in het leven geroepen. Een beetje geluidskaart kan 1.5 ms latency halen in een standaard Windows-PC.
Dit is de standaard waarop professionele software zoals Protools en Cubase hun werk doen, realtime, gewoon onder Windows dus.
Ik gebruik dat al jaren zelf, en dat werkt prima hoor. Met een pakket als Amplitube of Guitar Rig kan ik zelfs realtime een gitaarversterker + effecten simuleren op een standaard Windows-PC, snel genoeg om echt op te spelen (want latency merk je wel degelijk).

Ik denk dat je je eens wat beter in de zaken moet verdiepen. Windows geen low-latency performance, pffft. ASIO kent toch iedereen die wel eens met audio gerommeld heeft? Zit tegenwoordig zelfs op standaard Soundblaster-kaartjes, met Cubase LE erbij geleverd.

Echt triest hoe weinig tweakers van Windows weten. Windows is een veel beter en completer OS dan jullie denken, jullie doen gewoon geen moeite om te kijken wat er allemaal mogelijk is, en nemen voor het gemak het ergste geval maar aan. Realtime audio-bewerking in Windows kan echt al jaaaaren. Voordat OS X uberhaupt bestond, laat staan die kernel-patches voor linux.

Lijkt me ook wel duidelijk waar de 'inspiratie' van dat Ardour-project vandaan komt: http://www.steinberg.net/983_1.html

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:12]

[Verwijderd]

Wat ik schrijf is de praktijk. Ik doe het al jaren.

Een probleem, wat ik vergat te refereren, is wanneer meerdere programma's werken. Bijv. een file transfer van 1GB of 50 torrent connecties tegelijkertijd. Dan gaat een windows systeem haperen en mis je de real-time scheduler.

Natuurlijk kun je alles van je computer eraf gooien dat resources gebruikt, maar een computer gebruik ik meer dan muziek/geluid maken.

Lijkt me ook wel duidelijk waar de 'inspiratie' van dat Ardour-project vandaan komt: http://www.steinberg.net/983_1.html

Zucht...

[Verwijderd]

Een probleem, wat ik vergat te refereren, is wanneer meerdere programma's werken. Bijv. een file transfer van 1GB of 50 torrent connecties tegelijkertijd. Dan gaat een windows systeem haperen en mis je de real-time scheduler.

Ten eerste is CFS geen realtime scheduler in de zin van hard/soft realtime systemen (de scheduler van Windows daarentegen is near-realtime, en is dan ook een stuk aggressiever in het leveren van resources aan realtime-processen, als je daarvoor kiest. Wat inderdaad haperen tot gevolg kan hebben, maar dan zit het probleem tussen stoel en bureau).
Ten tweede kun je in Windows gewoon je systeem instellen op 'background processes', zoals ook in de Cubase-handleiding staat. Dan gedraagt Windows zich net als CFS als een 'eerlijk' systeem. Dit bestaat in Windows overigens al een eeuwigheid, al sinds NT4 meen ik.
Ten derde, het is op geen enkel systeem aan te raden om dingen met veel threads in de achtergrond te draaien als je realtime respons nodig hebt. Bepaalde dingen zoals harddisk-access kosten gewoon tijd, en geen OS of scheduler die daar iets aan kan doen. Dat voorbeeld van een bestand van 1 gb doorsturen zal op de meeste systemen fout gaan, omdat de hdd-zoektijd problematisch wordt. Als jij je audiotracks opneemt/afspeelt terwijl je een ander bestand aan het doorsturen bent, vraag je gewoon om problemen.
Binnen normale grenzen van gebruik voldoet Windows prima als audio workstation, en is een stuk populairder dan linux, dus het zal allemaal wel loslopen.

Ik kan me niet aan de indruk onttrekken dat jij zelf nooit serieus met audio hebt gewerkt... Niet op Windows, en ook niet op andere OSen. Je zegt nogal domme dingen.

Zucht...

Ja? Wat is er dan? Zeg het dan?
Noem je het professioneel trouwens?

"Ardour is not:
a sound file editor
a MIDI sequencer (though that is planned)
a loop-based music system

MIDI sequencing lijkt me toch wel de basis van een professionele audio-applicatie, maargoed, dat zal wel aan mij liggen.
Als ik m'n MIDI-apparatuur er niet goed mee kan aansturen, hoef ik er al niet eens aan te beginnen.
Laat ze het eerst maar eens afmaken.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:12]

[kidde]

Ik heb niet zoveel kaas gegeten van muziek op Linux / Windows, maar hier wat ik wel weet:

Windows zelf heeft redelijk wat latency. ASIO is volgens Wikipedia slechts een hack deze te omzeilen, door het OS tijdens de communicatie tussen audiosoftware en audiohardware zo veel mogelijk te omzeilen:

Its main strength lies in its method of bypassing the inherently high latency of operating system audio mixing kernels (KMixer), allowing direct, high speed communication with audio hardware.

Om de latency in de kernels zélf aan te pakken in plaats van deze te omzeilen, heb je echter een gepatchte kernel nodig. Wat Windows betreft ben je dan afhankelijk van en slechts van Microsoft. Wat Linux betreft heb je dan een lange lijst opties, zie bijv. hier:. Omdat Linux een low-latency kernel kan hebben en Windows niet (zonder steun van Microsoft, of zonder de code te omzeilen), worden Linux kernels o.a. gebruikt voor stoplichten, HardDisk recorders en digitale camera's, en de Windows-kernel niet. Als de Windows-kernel al voor applicaties wordt gebruikt waar een korte antwoorttijd belangrijk is, dan is dit meestal een Windows-CE kernel, die nogal verschilt van de grote lompe Windows-XP kernel.

Verder heb je helaas het idee van CFS verkeerd begrepen; het idee is juist om bij vele tegelijk-draaiende processen toch de 'reageertijd' op gebeurtenissen (in abstracte zin; events) laag te houden, zoals in de jaren oude CK-patches. CFS is alleen, in tegenstelling tot de CK-patches, niet alleen op de desktop gespitst. Dit heeft weinig tot niks met 'background processes' te maken heeft.

Als je vindt dat in Ardour het een en ander mist, is dat waarschijnlijk omdat er in Linux voor iedere taak aparte programma's zijn (Audacity voor sound file editing, RoseGarden voor MIDI-sequencing, enz.), en deze kan je met de low-latency geluid-server Jack virtueel aan elkaar knopen op elke manier die je wilt, met herprogrammeerbare in/uitgangen voor wie bijvoorbeeld een goede RME kaart heeft.

Het is logisch dat een aantal Tweakers niet weet hoe de Windows/Cubase etc. stack werkt, want deze kost honderden euro's wil je hem legaal op je PC hebben, dat begrijp ik. Wat ik niet begrijp is dat hier de pot de ketel schijnt te verwijten: Iemand die zelf niet zoveel van gratis te testen Linux-geluidsdistributies (Met low-latency kernel patches!) weet loopt in een nieuwsbericht over Linux te verwijten dat anderen niet weten hoe geluid in Windows werkt?

[Verwijderd]

Windows zelf heeft redelijk wat latency. ASIO is volgens Wikipedia slechts een hack deze te omzeilen, door het OS tijdens de communicatie tussen audiosoftware en audiohardware zo veel mogelijk te omzeilen:

Dat moet je in de juiste context plaatsen.
Destijds had Windows alleen de WinMM-audio interface. Die was inderdaad niet geschikt voor low-latency.
Pas later kwam DirectSound, die daar wel geschikt voor is (met de juiste geluidskaart natuurlijk. Goedkope onboard-kaartjes hebben gewoon hoge latency omdat de hardware niet snel is).
Maar toen was ASIO er al.
Een 'hack' is overigens geen goede benaming. Het is gewoon een alternatieve driver, net zoals bv OpenGL 'naast' het standaard Direct3D-model hangt, zonder dat daarbij iets aan Windows 'gehackt' moet worden. Het is gewoon een normale Windows-driver. Je werkt om de oude (Windows 3.x) WinMM-laag heen, niet om de kernel zelf (mooi bewijs is ASIO4ALL, dat kan ASIO zelfs op non-ASIO-hardware redelijk goed emuleren, met gewoon Win98/2k WDM-drivers, dat is dus ook snel genoeg).
ASIO moet je dus eerder vergelijken met zoiets als ALSA, een driver-laag die de hardware abstraheert.
Bij linux is het wel een hack, je moet immers je kernel patchen. ALSA alleen is niet goed genoeg, daarmee krijg je de latencies niet laag genoeg. Met ASIO wel.

WinMM, DirectSound en ASIO zijn gewoon ieder met een eigen doel ontworpen, en hebben daarom allen bestaansrecht. Ze draaien alledrie echter op dezelfde ongemodificeerde kernel.

Je had op z'n minst kunnen opzoeken wat die KMixer dan wel niet is
Dat is de kernel-mixer die softwarematige mixing doet. Dat heb je dus niet nodig op een geluidskaart die zelf hardware-mixing heeft, welke je via DirectSound kunt aanspreken, maar dat bestond nog niet. Deze software-mixer was destijds nodig, omdat de meeste Soundblaster-compatible kaarten maar 1 digitaal kanaal hadden. Kortom, lang vervlogen tijden, moet je niet gaan vergelijken met de linux van nu... Destijds HAD je op linux amper audio, laat staan dat je een mooie kernel-mixer had die multichannel audio toestond ongeacht de hardware die je gebruikte, en geen code in iedere applicatie nodig had (en gewoon meerdere applicaties door elkaar heen kon mixen, waar je voorheen altijd exclusief 1 applicatie kon horen. Dus geen geluidje als er mail binnenkomt, als je een mp3tje op de achtergrond wil luisteren).
Bij linux komt audiobewerking pas sinds heel kort om de hoek kijken. Logisch dat het beter is dan wat Windows ruim 10 jaar geleden had. Zowel de hardware als de software is vandaag de dag veel geavanceerder.
Desondanks is linux degene die kernel-patches nodig heeft, niet Windows.

Sowieso klopt jouw info niet. De KMixer werd pas in Win98/Win2k toegevoegd in het WDM-drivermodel. Voor die tijd was er geen mixing, en kon je maar zoveel streams openen als je hardware ondersteunde. ASIO is echter al geintroduceerd op Windows 95/NT4 (met Cubase VST), die het WDM-model niet ondersteunen. Dus hoe kan ASIO ontworpen zijn om het probleem van de KMixer te omzeilen als WDM/KMixer nog niet bestond?
Zie ook hier: http://www.heise.de/ct/english/97/14/068/
Ik denk dat je ergens het woord 'kernel' hebt gelezen, en dat werkt als een rode lap op linux-fanboys. Maar zeg nou zelf... Als je systeem-brede software-mixing gaat toepassen, zodat alle applicaties tegelijk audio kunnen afspelen, ongeacht of de hardware dit aan kan of niet, zou je die mixing dan ergens anders willen dan bovenop de audio-hardware? In de kernel dus? Het lijkt mij in ieder geval de meest logische optie, zeker in die tijd, waar elke cycle telde.
In Vista is de KMixer overigens verdwenen. Hij is niet meer nodig. Dus enige kritiek op de KMixer in de kernel is achterhaald.

Om de latency in de kernels zélf aan te pakken in plaats van deze te omzeilen, heb je echter een gepatchte kernel nodig. Wat Windows betreft ben je dan afhankelijk van en slechts van Microsoft.

Windows heeft dus geen gehackte kernel nodig. De latencies zijn in de standaard-kernel al laag genoeg, in tegenstelling tot linux.

Als de Windows-kernel al voor applicaties wordt gebruikt waar een korte antwoorttijd belangrijk is, dan is dit meestal een Windows-CE kernel, die nogal verschilt van de grote lompe Windows-XP kernel.

Alsof die embedded-systemen precies dezelfde linux-kernel en omliggende OS-software draaien als een 'gewone' PC desktop-distributie. Dat is ook een soort Linux-CE.

Verder heb je helaas het idee van CFS verkeerd begrepen; het idee is juist om bij vele tegelijk-draaiende processen toch de 'reageertijd' op gebeurtenissen (in abstracte zin; events) laag te houden, zoals in de jaren oude CK-patches.

In welk opzicht heb ik het dan verkeerd begrepen?
Ik heb gezegd dat het een 'eerlijk' verdelende scheduler is, en niet realtime in de zin van soft/hard realtime-systemen.

Het is logisch dat een aantal Tweakers niet weet hoe de Windows/Cubase etc. stack werkt, want deze kost honderden euro's wil je hem legaal op je PC hebben,

Helemaal niet. Cubase LE (danwel Cakewalk Sonar LE) krijg je kado bij de wat luxere Audigy en X-Fi kaarten (en vast ook vele andere merken), alsmede de meeste USB/FireWire interfaces. Kost weinig hoor. Sowieso moet je een dergelijke kaart aanschaffen, wil je van low-latency gebruikmaken, ongeacht welk OS je kiest. Een onboard kaartje is gewoon niet snel genoeg.
Maar het is niet erg als je niet weet hoe het werkt... Maar kom dan niet hier met je grote mond even vertellen dat je onder Windows geen realtime audio-bewerking kan doen.

Wat ik niet begrijp is dat hier de pot de ketel schijnt te verwijten: Iemand die zelf niet zoveel van gratis te testen Linux-geluidsdistributies (Met low-latency kernel patches!) weet loopt in een nieuwsbericht over Linux te verwijten dat anderen niet weten hoe geluid in Windows werkt?

Ik heb nergens iets over linux beweerd dat niet klopt, in tegenstelling tot jullie twee over Windows.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:12]

[Verwijderd]

For your information:

Bij linux is het wel een hack, je moet immers je kernel patchen. ALSA alleen is niet goed genoeg, daarmee krijg je de latencies niet laag genoeg. Met ASIO wel.

Er wordt niet echt iets gepatched; slechts een ingecompilde driver wordt nu als module geladen en je moet de realtime driver compilen. Verder moet je vertellen dat een bepaalde usergroup realtime mag werken.

Ik haal met Debian Linux (Etch) op Dell Inspiron 1150 een latency van een woopie 2.9ms

[Verwijderd]

Er wordt niet echt iets gepatched; slechts een ingecompilde driver wordt nu als module geladen en je moet de realtime driver compilen.

Er wordt wel het een en ander gepatcht (Ingo Molnar's realtime pre-emptive patch), bepaalde dingen moeten pre-emptive gemaakt worden om die lage latencies te halen, dat is in de gewone kernel niet het geval. Bij die audio-distributies/RPMs/etc wordt ook de complete kernel gewoon vervangen. Het is dus geen module.

Ik haal met Debian Linux (Etch) op Dell Inspiron 1150 een latency van een woopie 2.9ms

Geweldig hoor. Creative garandeert met hun X-Fi al 1.0 ms onder Windows

You'll also get support for ASIO recordings with latency as low as one millisecond

Ook met een Juli@ haal je onder Windows een latency van 1.0 ms (en dat gewoon op een oude singlecore 3500+). En daar hoef je niet eens je kernel te patchen. Gewoon out-of-the-box.
Moet ik dan onder de indruk zijn van een getweakte linux die dat nog niet eens haalt?
En dan dat arrogante edoch ongeinformeerde gerant over dat Windows niet onder de 70 ms zou kunnen komen. Ga toch weg man.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:12]

[Verwijderd]

Er wordt wel het een en ander gepatcht (Ingo Molnar's realtime pre-emptive patch)

.
De source-code die bij je distributie wordt geleverd is al afgepatched met dit soort patches, zo ook acpi etc. etc. dus dat hoef je allemaal niet te doen. Door jou ogen lijkt realtime in Linux 'magic by the gurus', terwijl het een kwestie van enkele commands dat op vele vele sites terug te vinden is.

Ik haal met Debian Linux (Etch) op Dell Inspiron 1150 een latency van een woopie 2.9ms

Geweldig hoor. Creative garandeert met hun X-Fi al 1.0 ms onder Windows

Haal je nu weer OS (software) en hardware door elkaar?

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:12]

[Verwijderd]

De source-code die bij je distributie wordt geleverd is al afgepatched met dit soort patches, zo ook acpi etc. etc. dus dat hoef je allemaal niet te doen. Door jou ogen lijkt realtime in Linux 'magic by the gurus', terwijl het een kwestie van enkele commands dat op vele vele sites terug te vinden is.

Erm, blijkbaar denk jij als een gebruiker, en ik als een developer.
Je moet je kernel recompilen. Dat dat inderdaad een kwestie van enkele commando's is, neemt niet weg dat je ingrijpende veranderingen in je kernel doorvoert. Het feit alleen al dat je iets moet doen om het voor elkaar te krijgen is al een teken aan de wand dat het nog niet zo volwassen is.
Als het goed doorontwikkeld was, zou het standaard allemaal meegecompileerd worden, omdat het verder geen nadelige gevolgen heeft voor applicaties die er geen gebruik van maken, net zoals bij Windows en Mac OS X.
Maar het bevindt zich nog niet in een dermate stabiele fase. Linux komt op dit gebied dan ook net pas kijken, waar andere OSen al jaren meedraaien.

Verder waren het hierboven nog je eigen woorden:

Apple heeft inderdaad low-latency performance, terwijl Windows weer niet.
Voor Linux moet je deze soms zelf in de kernel compilen, maar je haalt dan met gemak 2ms.

Je spreekt nu dus jezelf tegen.

Huh? Haal je nu weer software en hardware door elkaar?

Het een leidt tot het ander he. Bij Windows is kennelijk de hardware de beperkende factor, niet de software.
Aan jouw opmerking begrijp ik dat dat in linux niet het geval is?

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:12]

[Verwijderd]

Dat dat inderdaad een kwestie van enkele commando's is, neemt niet weg dat je ingrijpende veranderingen in je kernel doorvoert.

Je hoeft niet bang te zijn voor een nieuwe kernel installatie.

Verder heb je weer een 'rant', nu jegens Linux kernel. Gaat alles verder goed daar?

[Verwijderd]

Je hoeft niet bang te zijn voor een nieuwe kernel installatie.

Dat zeg ik toch niet? Ik zeg alleen dat het nog niet geheel vrij van kinderziektes is. Wil niet zeggen dat je er niet gewoon mee kunt werken.

Verder heb je weer een 'rant', nu jegens Linux kernel. Gaat alles verder goed daar?

Je probeert zeker de aandacht af te leiden van het feit dat je er niet verder naast kon zitten qua Windows audio, en dat jouw claims over linux' betere audio-ondersteuning nogal gigantisch onderuit gegaan zijn, met jouw geloofwaardigheid erachteraan.
Mooi hoor, die linux-community.
Totaal niet gehinderd door kennis van zaken gaan ze ervaren mensen even vertellen dat wat ze al jaren doen helemaal niet kan, en dat ze linux moeten gebruiken. En dan nog bijdehand doen als ze een keer iemand tegenkomen die de moeite neemt om uit te leggen hoe het werkelijk zit.
Ik word er zo langzamerhand een beetje onpasselijk van, dat arrogante gedrag. Wees in ieder geval volwassen genoeg om toe te geven dat je er gigantisch naast zat, wat Windows betreft, en je mag me ook wel bedanken voor de uitgebreide info die ik hier voor je neergezet heb, compleet met links naar achtergrond-informatie, zodat je ziet dat ik het niet uit m'n duim zuig, maar dat het echt zo is.

Ik werk dan ook al sinds begin jaren '90 met Cubase, eerst op een Atari ST, en later op Windows, en heb de ontwikkeling helemaal meegemaakt. Verder ben ik software-engineer, en heb ik door de jaren ook wel wat gehobbied met WinMM en DirectSound, dus ook met die verdomde KMixer ben ik wel bekend.

Ik weet het, het komt waarschijnlijk maar zelden voor dat je een Windows-gebruiker tegenkomt die verstand van zaken heeft, maar als het gebeurt, en hij wijst je op je gebrek aan kennis en verspreiding van foute informatie, dan kun je daar iets volwassener mee omgaan.
Als de linux-community nou niet zo arrogant deed alsof ze alles hebben uitgevonden, en niet zo onwetend was aangaande andere systemen, dan zou ik er niet zo'n antipathie tegen ontwikkeld hebben, door de jaren.

[Verwijderd]

Je schrijfstijl is zo charmant!

Kun je ons nog meer verhaaltjes vertellen?

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:12]

[Verwijderd]

Thank you!

[Verwijderd]

Dus in welk punt geef je me nu ongelijk?

Ik kan me niet aan de indruk onttrekken dat jij zelf nooit serieus met audio hebt gewerkt... Niet op Windows, en ook niet op andere OSen. Je zegt nogal domme dingen.

Ad Hominem argumentatie.

De rest van je tekst is jouw 'rant' jegens Ardour (waarom eigenlijk?) hetgeen me niet interesseerd en feitelijk incorrect is:

MIDI sequencing lijkt me toch wel de basis van een professionele audio-applicatie, maar goed, dat zal wel aan mij liggen. Als ik m'n MIDI-apparatuur er niet goed mee kan aansturen, hoef ik er al niet eens aan te beginnen.

Een MIDI-sequencer is wat anders dan een MIDI-controller! Voor MIDI aansluiting:
http://ardour.org/files/manual/sn-midi-configuration.html
http://ardour.org/files/manual/ch-control-surfaces.html
Erg stoer is het met de Behringer BCF2K, waar de automatic faders meebewegen met veranderingen die je aanbrengt op het scherm of tijdens playback! Ook erg fancy is de learn mode van de faders en rotary encoders voor de vele plugin/filters.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:12]

[Verwijderd]

Een MIDI-sequencer is wat anders dan een MIDI-controller!

Ik weet wat een sequencer is. Ik heb het nergens over een MIDI-controller gehad.
Hou alsjeblieft je mond, je hebt geen flauw idee waar je het over hebt. Ga me dus niet vertellen hoe het moet.

[mae-t.net]

Uit de wikipedia entry van ASIO:

Its main strength lies in its method of bypassing the inherently high latency of operating system audio mixing kernels (KMixer), allowing direct, high speed communication with audio hardware.

Met andere woorden: de kernelperformance van windows is bagger, met deze standaard omzeil je het nodige aan scheduling en andere bronnen van latency. Weet jij toevallig of er al goed werkende ASIO implementaties onder Vista zijn?

EDIT: ik had even een aantal veel diepgravender reacties hierboven gemist, die ook al op deze punten ingaan.

[Reactie gewijzigd door mae-t.net op 23 juli 2024 00:12]

[Verwijderd]

Met andere woorden: de kernelperformance van windows is bagger, met deze standaard omzeil je het nodige aan scheduling en andere bronnen van latency.

Lees mijn bovenstaande post.
Ten eerste omzeilt ASIO niet de KMixer omdat ASIO al langer bestaat dan de KMixer.
Ten tweede heeft de KMixer niets met scheduling te maken.
Ten derde verandert ASIO ook niets aan de scheduling.

Windows heeft dus prima kernel-performance... alleen komt dat er niet uit als je er een software-mixer tussen gaat zetten, maar dat lijkt me logisch. De software-mixer was bedoeld om gewone Windows-applicaties allen geluid te laten hebben, zonder specifieke hardware-support. Multitasking audio, zeg maar.
Niet bedoeld voor professionele audio. Daar is de ASIO-driver voor bedacht. Niet door Microsoft zelf, maar dat geeft maar weer de flexibiliteit en modulariteit van Windows weer. Een 3rd party als Steinberg kan iets dergelijks aan Windows toevoegen zonder aanpassingen aan het bestaande systeem. De efficiente low-latency kernel was er al. Er was alleen nog geen direct pad naar high-end audio-hardware. Op zich ook niet gek, want PCs en Macs kwamen pas net op het niveau dat ze krachtig genoeg waren voor dit soort werk. Voor die tijd gebruikte men gewoon analoge apparatuur of dure dedicated hardware DAWs. Cubase VST ontketende wat dat betreft een revolutie door dit op 'gewone' Macs en PCs mogelijk te maken. De rest is geschiedenis.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:12]

[Verwijderd]

Daarvoor is de ASIO-standaard in het leven geroepen. Een beetje geluidskaart kan 1.5 ms latency halen in een standaard Windows-PC.

Heb mijn kernel zojuist gerecompiled met Ingo Molnar’s realtime patch.
Anderen hebben ook 0.8ms latency, dat is 2x sneller dan WIndows.
http://ardour.org/node/546

Pech voor je dat Windows closed-source is, zodat je niet kan tweaken

Een howto met referenties is op:
http://www.rdegraaf.nl/DEBIAN_Etch-realtime

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:12]

[Verwijderd]

Heb mijn kernel zojuist gerecompiled met Ingo Molnar’s realtime patch.
Anderen hebben ook 0.8ms latency, dat is 2x sneller dan WIndows.
http://ardour.org/node/546

Hoe laag de latency van Windows precies kan zijn, weet ik niet.
Mijn kaart is uit 2000, stokoud dus, en kan ik niet lager instellen dan 1.5 ms.
Met een nieuwe X-Fi of andere ASIO 2.0-kaart kun je blijkbaar de latencies nog verder omlaag gooien.

De Juli@ kun je tot 48 samples latency instellen, wat bij 192 KHz dus echt verwaarloosbaar weinig is (0.1 ms ofzo). Met zo'n kaart zou je kunnen testen hoe laag Windows kan. Ik ken wel iemand die die kaart heeft, en betrouwbaar met 1 ms werkt op een oude 3500+. Op een moderner systeem kan ie vast ook wel onder de 0.8 ms.

Bij mij is Windows in ieder geval niet de beperkende factor. M'n kaart heeft gewoon geen lagere instelling in de driver dan 1.5 ms. Wat op zich al beter is dan de 3 ms bij 96 KHz waar men zo enthousiast over was in de handleiding van het ding. Maargoed, in 2000 waren de computers wat minder krachtig.

http://www.creative.com/p...ategory=669&product=14064

Get ASIO recording with latency as low as one millisecond and zero CPU load for the most precise audio recording capabilities in any class!

Vooral die zero CPU load is natuurlijk ook interessant...
Want als ik jouw linkje lees:

Going even lower would definetely generate too much context switching overhead.

Blijkbaar gaan die lage latencies in linux dus ten koste van CPU-overhead. Dat is natuurlijk geen optie, want dan kun je weer minder VSTis gebruiken.
1.0 ms is in principe al ideaal, lager hoeft niet. En 0% CPU load is natuurlijk ook ideaal. Laten we het dus eens hebben over de CPU-belasting in linux bij 1.0 ms.

Pech voor je dat Windows closed-source is, zodat je niet kan tweaken

Waarom zou ik moeten tweaken?
Zelfs al zou ie niet lager dan 1.0 ms kunnen, boeit het eigenlijk niks, want 1 ms is al goed genoeg.
Maar de mannen in Redmond hebben gewoon hun werk goed gedaan, dus er hoeft niets getweakt te worden. Jammer voor jou dat je zoveel moeite moet doen aan dat gratis opensource kerneltje van je, om een beetje in de buurt van Windows te komen met zoiets eenvoudigs als audio-bewerking.
Ik zie de gemiddelde muzikant/studiotech nog niet echt aan de slag gaan met kernel recompiles etc. Het zijn geen computer-experts (mede daarom prefereren ze vaak de Mac, die werkt het makkelijkst). Nog niet klaar voor het grote publiek dus.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:12]

[Verwijderd]

Waarom zou ik moeten tweaken?

Het was een plaagje

Ik zie de gemiddelde muzikant/studiotech nog niet echt aan de slag gaan met kernel recompiles etc. Het zijn geen computer-experts (mede daarom prefereren ze vaak de Mac, die werkt het makkelijkst).

Yep, een Mac staat ook op mijn verlanglijstje!

Have fun...

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:12]

[flowerp]

Belangrijk is om te begrijpen dat real-time niet betekent zo snel mogelijk of zonder wachttijd voor de gebruiker.

Wat dat betreft is de term "real-time" wat gedegradeerd sinds de 'gewone' gebruiker hem ook is gaan gebruiken.

De echter liefhebbers lezen er natuurlijk even een goed artikel over, maar heel simpel gezegd komt real-time erop neer dat de factor tijd meeweegt voor de correctheid van berekeningen te bepalen.

Als jij een time-window voor een berekening instelt op 10 minuten, dat moet je voor elk sub-onderdeel van die berekening i.c.m. de hardware kunnen -garanderen- dat die berekening ook binnen 10 minuten klaar is. Gebeurd dat onverhoopt toch niet (en in een hard real-time systeem is dat per definitie niet vaak), dan is er sprake van een fout; een exception.

10 minuten moeten wachten op een berekening is echter niet waar de meeste mensen aan zouden denken bij real-time, maar het gaat dus heel expliciet om het garanderen van time-windows, niet om het 'niet hoeven wachten door mensen'.

[elteck]

Ik heb altijd geleerd dat voor OS-sen "real time" betekent dat een "event" (hardware of software) gegarandeerd binnen een bepaalde tijd in behandeling wordt genomen.

Dus als je een muisklik geeft moet daar zeg binnen 100 ms op gereageerd worden.

De eerste vraag naar "real time" operating systems kwam ook uit de proces industrie, waar bijvoorbeeld binnen bepaalde tijd op een alarm van een overdruk ventiel gereageerd moest worden.

De Linux kernel heeft al een tijdje een "real time" optie die je aan de scheduler mee kan geven. Maar die wordt voor normaal gebruik niet aangeraden, omdat de overhead dan relatief hoog wordt.

Op de Kernel trap blog wordt niet bijster positief op deze CFS gereageerd. Het schijnt niet goed met prioriteiten om te gaan. Sommigen beweren zelfs dat het vriendjes politiek van Linus is. Lees hier maar: http://kerneltrap.org/node/11737

[moto-moi]

kernreactor, om maar een schoolvoorbeeld uit m'n mouw te toveren

[Verwijderd]

In vliegtuigen...

[Verwijderd]

Mobiele telefoons...

[Verwijderd]

En dan priority inversion veroorzaken zodat de boel blokkeert? Nee bedankt.

Het soort real-time dat in kernreactors gebruikt wordt heeft zowiezo weinig te maken met wat in scheduling de real-time prioriteit genoemd wordt.

[Verwijderd]

Het soort real-time dat in kernreactors gebruikt wordt heeft zowiezo weinig te maken met wat in scheduling de real-time prioriteit genoemd wordt.

Precies, realtime betekent daar keiharde garanties dat bepaalde operaties NOOIT meer dan X ms duren.
Scheduling/multitasking staat daar natuurlijk haaks op, want hoe kun je dergelijke garanties leveren als de gebruiker alle software kan draaien die ie wil?

Realtime prioriteit in een multitasking OS betekent vooral dat jouw proces zo veel mogelijk resources krijgt (en doorgaans zelf z'n vrije cycles op moet geven middels sleep() en vergelijkbare calls). Waardoor ie 'hopelijk' altijd snel genoeg reageert, maar garanties leveren kun je niet. Je kunt namelijk ook twee of meer van dergelijke processen opstarten in een multitasking-omgeving, en wie krijgt dan de resources?

[BoXie]

Bij het robotvoetballen van Universiteiten

[jealma]

Wordt hiermee het probleem opgelost waar ik met VMware Workstation 6 steeds tegenaan stuit: namelijk dat de timer in een virtueel OS niet goed loopt met de timer van het host OS (linux), waardoor het virtuele OS crashed? Dat had ook iets met HPET (High Precision Event Timer) en RTC (real time clock) te maken.

[TaXaN]

Dat gaat niets te maken hebben met CFS maar ik vermoed eerder met de recente 'tickless kernel' wijzigingen.

Typisch wordt de RTC gebruikt om op vaste intervallen een interrupt te genereren die door de kernel gebruikt wordt om te checken welke timers expired zijn. Het nadeel hiervan is dat er meestal geen timers expired zijn en de kernel dus niets moet doen. Dit weerhoudt de CPU ervan om lange tijd in deep sleep (C3) state door te brengen.
Met de tickless kernel kan er nu via een programmable timer zoals HPET de kernel vastleggen wanneer er een interrupt moet komen. De tijd tot die interrupt kan het systeem dan volledig in deep sleep doorbrengen

Op x86 is heel het timer gebeuren erg complex en daarom heeft het lang geduurd vooraleer dit mogelijk werd. Het is goed mogelijk dat er nog problemen zijn hier en daar; BIOSsen staan niet bekend om hun bugvrije timer en power saving code...

[YoMarK]

De timer in je VM loopt nooit helemaal gelijk met het host OS.
In je VM heb je een processor op een bepaald aantal MHz-en, en deze kloktikken worden gebruikt voor je Real Time Clock. Het probleem is dat in werkelijkheid je VM nooit dit aantal kliktikken krijgt toegewezen, omdat b.v. je host OS of een andere VM er ook wat nodig heeft. Afhankelijk van belastingen van de CPU, klopt de tijdsberekening in je VM dus helemaal niet.
De tijd moet dus om de zoveel tijd worden gesynchroniseerd. In het geval van Vmware kan dit gebeuren doormiddel van de Vmware tools in je VM(dit is vrij precies).
Ook kan je in je VM gebruik maken van een NTP server. Afhankelijk van je instellingen is dit niet zo precies, en kan je klok in je VM in een half uur makkelijk minuten fout gaan lopen.
Bepaalde applicaties draaien dus niet zo goed in een VM(en moet je dus niet virtueel draaien). Goed voorbeeld is b.v. een VOIP centrale met voicemails, deze kunnen wel eens raar gaan klinken.
Wat ik nog nooit heb meegemaakt is dat applicaties gaan crashen, dus dat is een vreemd verhaal.

[martijnvanegdom]

Zeer vermoedelijk niet, want timing is geen functie waar een schedular verantwoordelijk voor is. Een Schedular heeft 1 taak.. zorgen dat processen de benodigde resources krijgt toegewezen.

[tjerkw]

Waat en prutpraat artikel. Schedulers zijn onderdeel van elke multitasking OS...
Waarom wordt nu uitgelegd wat is een scheduler is terwijl het enigste nieuws is dat er een andere Scheduler wordt gebruikt??

[Blokker_1999]

voor de mensen die er niet zo veel van kennen?

[ddofborg]

Ik zou erg graag benchmarks willen zien.