Microsoft ontwikkelt fix voor netwerkproblemen onder Vista

Softwarefabrikant Microsoft werkt momenteel hard een aan hotfix die een einde moet maken aan de door de audiospeler veroorzaakte netwerkproblemen onder Windows Vista.

Diverse Vista-gebruikers klagen al maanden op fora dat hun netwerkprestaties fors afnemen als er audio wordt afgespeeld. Zelfs als de muziek is gepauzeerd, lijkt de netwerksnelheid nog negatief te worden beïnvloed. Vorige week kwamen de ontwikkelingen in een stroomversnelling toen een driverprogrammeur op een forum de mogelijke oorzaak benoemde en met een oplossing op de proppen kwam.

Eind vorige week had Microsoft het probleem intern goeddeels ontleed, schrijft Larry Osterman van Microsoft op zijn MSDN-blog. 'Het blijkt dat dit probleem sterk afhangt van de netwerktopologie en de hoeveelheid data die door de netwerkadapter wordt gepompt. Het komt er op neer dat een Vista-systeem het inkomende netwerkverkeer afknijpt om te voorkomen dat de weergave van multimedia in gevaar komt.'

Volgens Osterman is het afspelen van multimedia niet vergelijkbaar met andere bezigheden van een computer. 'In Vista draait de audio engine met een interval van 10ms. Dat betekent dat de engine elke 10ms wakker moet worden om een serie samples te verwerken, anders hoort de gebruiker een onderbreking.' Dit proces heeft dus een hoge prioriteit, maar dat geldt ook voor het netwerkverkeer. Omdat het netwerk de audio engine kan beletten om elke 10ms zijn werk te doen, moet Vista ingrijpen om hoorbare storingen te voorkomen.

Het probleem doet zich alleen voor bij gigabit-ethernet. Om de geluidsweergave te beschermen, hanteert Vista een vast maximum van 10.000 packets per seconde. Met een 100Mbit-interface wordt die limiet zelden of nooit bereikt, maar met een gigabitkaart kan deze grens makkelijk gehaald worden. Osterman benadrukt dat er binnen Microsoft aan een oplossing voor het probleem wordt gewerkt. Het is niet bekend wanneer deze fix gereed zal zijn.

Reacties (86)

[Verwijderd]

Een bug is het niet eens.
Wat wel een bug is, is het feit dat bij meerdere NICs het maximum aantal pakketjes verkeerd berekend wordt, en hoe meer NICs, hoe minder pakketjes Vista doorlaat.
Daar hebben ze gewoon de formule niet goed geimplementeerd.

Dit is gewoon een wat onhandig gekozen default-waarde.
Een prima workaround hiervoor is om jumbo-frames in te schakelen.
Je hebt dan pakketjes van 9000 bytes ipv de standaard pakketjes van 1500 bytes, waardoor je veel minder interrupts per seconde hebt, en dus minder CPU load (de reden waarom ze geintroduceerd zijn... destijds waren veel CPUs niet eens snel genoeg om gbit voluit te benutten, zat je al op 100% CPU).
Dan heb je dus geen ~15% snelheid, maar ~90% snelheid, en dat is in de praktijk verwaarloosbaar (meestal haal je toch maar iets van 70% vanwege collisions of andere vormen van packetloss/vertragingen).

Verder zou het mooi zijn als Microsoft bij de patch meteen de gebruiker wat controle geeft. De feature aan/uitzetten, of zelf een maximumwaarde instellen bv. Misschien zouden ze zelfs een dynamische limiter kunnen maken (pas begrenzen als je richting de 100% CPU gaat..).

Het systeem van Windows op zich zit wel zeer netjes in elkaar. De workload wordt buiten de interrupt handler verwerkt, in een Deferred Procedure Call, terwijl intussen de interrupts alweer aan staan.
Vista zet er dan ook nog eens een begrenzer op zodat je niet al je tijd kwijt bent aan die DPCs wanneer je multimedia afspeelt (ik vraag me af in hoeverre dat in voorgaande Windows-versies ook gedaan werd, want haperende audio/video heb ik eigenlijk nog nooit meegemaakt onder Windows... onder andere OSen wel. Ik weet wel dat Windows bij fullscreen DirectX-applicaties een zg Win16-lock deed om resources te winnen, wat verschillende subsystemen platlegde).

Ik vind dus dat men een beetje overdreven kritisch reageert. Het idee is mooi, en de basis is gewoon goed. Veel andere OSen hebben deze technologie nog niet eens. Ja, de uitvoering is nog niet helemaal vlekkeloos, maar Windows zit er een stuk dichterbij dan veel van z'n concurrenten. Dit is een kwestie van even finetunen, en zal in een tijd van een paar dagen voor elkaar zijn.
Aangezien ik mijn systeem veel gebruik als DAW met Cubase vind ik het heel fijn dat ik kan vertrouwen op een OS dat mijn audio/video voorrang geeft op netwerk-activiteit en dergelijke. Ik kan begrijpen dat dat voor mensen met fileservers precies omgekeerd geldt, dus vandaar handig als de optie uit kan.

[Reactie gewijzigd door Verwijderd op 27 juli 2024 00:01]

[MneoreJ]

Veel andere OSen hebben deze technologie nog niet eens.

Nou, nou, beetje overdreven; asynchrone interruptverwerking is redelijk gemeengoed, en het afknijpen van het netwerkverkeer is een nogal slordig geïmplementeerde hack (het audiosysteem zou niet rechtstreeks met het netwerksysteem moeten gaan spelen om z'n eigen latency veilig te stellen; zulke problemen worden beter op een hoger niveau opgelost).

Wat Windows dan weer niet heeft (en wat het probleem ook aanzienlijk zou kunnen verhelpen voor veel mensen) is de mogelijkheid om interrupts met meerdere processoren te verwerken. In Linux bijvoorbeeld kan dat wel: CPU 0 kan de netwerkinterrupts doen terwijl CPU 1 de audio-interrupts doet, als het OS denkt dat dat handig is. Dan zou je dit probleem niet eens gehad hebben. In Windows komen alle interrupts binnen op CPU 0. Begrijpelijk, maar misschien de moeite waard om aan te werken.

[Verwijderd]

(het audiosysteem zou niet rechtstreeks met het netwerksysteem moeten gaan spelen om z'n eigen latency veilig te stellen; zulke problemen worden beter op een hoger niveau opgelost).

Makkelijker gezegd dan gedaan.
Hoe had jij het dan gezien?
Dat iedere applicatie een limitNetworkBandwidth() moet aanroepen ofzo?
Dat is toch niks?
Alleen binnen het audiosysteem weet je zeker dat het altijd werkt zoals zou moeten, zonder dat applicaties er iets vanaf hoeven te weten.
En hoe had je het andersom bedacht trouwens?
Als je juist alle bandbreedte in een netwerkapplicatie wilt? Moet er dan een maximizeBandwidth() in iedere applicatie? En wat als limitNetworkBandwidth() en maximizeBandwidth() tegelijk gebruikt worden? Chaos?

Wat Windows dan weer niet heeft (en wat het probleem ook aanzienlijk zou kunnen verhelpen voor veel mensen) is de mogelijkheid om interrupts met meerdere processoren te verwerken. In Linux bijvoorbeeld kan dat wel: CPU 0 kan de netwerkinterrupts doen terwijl CPU 1 de audio-interrupts doet, als het OS denkt dat dat handig is.

Dat heeft Windows wel, maar dat helpt niet.
Het probleem is ook niet de audio-interrupts. Het probleem is dat zowel het afspelen van media als het gebruiken van een gbit netwerk veel CPU-overhead heeft. Bij media vaak zelfs meerdere cores tegelijk (vooral voor HD-content... een BluRay film zonder de hulp van een snelle GPU trekt op veel dualcore processors nog zomaar 80% CPU of meer.. en gbit met 1500 byte frames is dan gewoon teveel voor die laatste 20%).
Punt is dat je in de worst case gewoon niet genoeg CPU vrijhebt om zowel de media vol af te spelen als de netwerk-interface voluit te laten draaien.
Als je dan wilt dat je media ongestoord verder draait (wat mensen met Media Center ongetwijfeld zullen eisen), dan MOET je dus wel zorgen dat je je netwerkkaart je CPU niet verzadigt met interrupts.
Ik neem aan dat ze in Windows Server juist het netwerk voorrang geven, Server is immers bedoeld als server... Vista niet.

Kortom, er is niets mis met het idee, alleen de uitvoering is (nog) niet zo goed.
Hoewel, het grootste probleem is gewoon dat die jumbo-frames niet uitstaan. Daarmee heb je ineens al een factor 6 minder interrupts per seconde zonder bandbreedte op te geven. Met 1500 byte frames blijf je sowieso altijd veel CPU-kracht weggooien, dat is nooit wenselijk.

Lees ook dit maar eens door: http://blogs.technet.com/...e/2007/08/27/1833290.aspx

En zie ook het voorbeeld waar hij een film kopieert over een gbit-verbinding, en dat kost al ~42% CPU.
Hou je nog maar ~58% CPU over voor je film. Dat is voor realtime HD-content niet bepaald ideaal.
Dit is dus niet een probleem dat je kunt oplossen met een 'ideale' interrupt-handler. Je hebt gewoon de CPU-kracht niet om beide zaken te combineren zonder dat het gaat horten en stoten. Zelfs linux kan je CPU niet sneller maken dan ie is, dus het houdt gewoon op.

[Reactie gewijzigd door Verwijderd op 27 juli 2024 00:01]

[MneoreJ]

Makkelijker gezegd dan gedaan.

Tuurlijk. "That's why we pay you the big bucks", zeggen de managers dan.

Het probleem hier is dat het audiosysteem een minimale latency wil. Prima. Laat het dat naar een supervisor binnen het OS communiceren. Die kan vervolgens bepalen dat het netwerkverkeer eventueel afgeknepen moet worden, afhankelijk van de relatieve prioriteit van de systemen. Die supervisor heeft ideaal gezien een goed beeld van wat er aan interrupts heen en weer zoeft, en wat de gebruiker belangrijk vindt.

Eenvoudig? Nee, zeker niet. Maar de huidige oplossing is wel erg kort door de bocht: de engineers zagen dat netwerkverkeer voor problemen konden zorgen en gingen dus maar het netwerkverkeer afknijpen vanuit het audiosysteem. Da's toch geen nette scheiding.

Dat heeft Windows wel

Niet volgens het kernelteam (bij monde van Larry Osterman), die ik toch wel wat kennis toeschrijf. Als jij het beter weet mag je het zeggen.

Het probleem is ook niet de audio-interrupts.

Nee, inderdaad, het probleem zijn de netwerkinterrupts (of liever de DPCs). Die zorgen ervoor dat de CPU het doel van iedere 10 ms audio verwerken niet haalt. Nou weet ik inderdaad niet of Windows een DPC op een andere CPU kan verwerken dan waarop de interrupt binnenkwam, anders zou het misschien nog wel gaan: voor multicoremachines is het dan een kwestie van de DPCs beter verdelen. Als die "wakker worden voor audio" events ook interrupts zijn, daarentegen, wordt het wel degelijk weer interessant om interrupts via meerdere processoren te verwerken.

CPU belasting is niet de crux van dit verhaal. Het is niet zo dat de processor(en) het niet zouden trekken (dat kan wel, maar dat is niet het probleem waar mensen mee te kampen hebben) maar dat de realtime-eisen van de audiolaag moeilijk in te willigen zijn als er ook nog duizenden netwerkinterrupts verwerkt moeten worden (in XP is het al voldoende als een proces met hogere prioriteit de boel gaat verzieken).

Het gaat hier niet om superzware HD met DRM en wat al niet... Puur te weinig CPU overhouden is weer een ander verhaal.

[Verwijderd]

Het probleem hier is dat het audiosysteem een minimale latency wil. Prima. Laat het dat naar een supervisor binnen het OS communiceren. Die kan vervolgens bepalen dat het netwerkverkeer eventueel afgeknepen moet worden, afhankelijk van de relatieve prioriteit van de systemen. Die supervisor heeft ideaal gezien een goed beeld van wat er aan interrupts heen en weer zoeft, en wat de gebruiker belangrijk vindt.

Dit heeft dus niets te maken met prioriteit, omdat interrupt handers/DPCs qua prioriteit 'buiten categorie' zijn, en gewone threads pre-empten.
Het probleem is dus dat de threads die je media aan het decoderen zijn starved raken als je niet ingrijpt.
Het heeft dus niks met het audiosysteem zelf te maken, dat is niet hetgeen dat de CPU-cycles wil hebben. Het zijn de user-threads, en daar heeft het OS dan weer geen direct zicht op (hoe moet het OS nou ruiken welke threads verantwoordelijk zijn voor het genereren van de a/v-buffers die naar de hardware gestuurd worden? Dat weet je pas als de buffer verstuurd wordt, en dan is het al te laat). Volgens mij snap je het probleem dus niet.

Verder moet je het natuurlijk niet zo heel letterlijk nemen dat direct het multimediasysteem het netwerksysteem platlegt. Dat zal indirect gaan via een speciaal request naar de executive.

Niet volgens het kernelteam (bij monde van Larry Osterman), die ik toch wel wat kennis toeschrijf. Als jij het beter weet mag je het zeggen.

Dat zegt ie helemaal nergens.

Nou weet ik inderdaad niet of Windows een DPC op een andere CPU kan verwerken dan waarop de interrupt binnenkwam, anders zou het misschien nog wel gaan: voor multicoremachines is het dan een kwestie van de DPCs beter verdelen.

Nogmaals: nee.
Je hebt niet genoeg CPU-kracht om alle DPCs te verwerken en toch alle audio/video op tijd te decoderen, worst case. Het is gewoon teveel workload tegelijk. Beter verdelen helpt niet, je houdt altijd over.

Het gaat hier niet om superzware HD met DRM en wat al niet... Puur te weinig CPU overhouden is weer een ander verhaal.

Daar gaat het wel om. Daar is dit systeem namelijk voor. Dat je NOOIT te weinig CPU overhoudt voor je audio/video.
Het is alleen een bijwerking dat het netwerk ook al begrensd wordt als je wel genoeg CPU overhoudt, en dat is een kwestie van het systeem even fijnstellen.

[Reactie gewijzigd door Verwijderd op 27 juli 2024 00:01]

[MneoreJ]

Dit heeft dus niets te maken met prioriteit, omdat interrupt handers/DPCs qua prioriteit 'buiten categorie' zijn, en gewone threads pre-empten.

Ik bedoel prioriteit in de puurste zin des woords, niet de scheduling-prioriteit van threads. In dit geval is het dus zo dat de wensen van het audiosysteem (iedere 10 ms verwerking) prioriteit moet krijgen boven de wensen van het netwerksysteem (zoveel mogelijk bandbreedte).

Het probleem is dus dat de threads die je media aan het decoderen zijn starved raken als je niet ingrijpt.

Oooj, natuurlijk, ik zit omgekeerd te denken... Die audio-data verschijnt niet uit het niets, natuurlijk. Het zit hem in de voorkant van de stroom, niet aan de driverkant.

Tijd om de gevreesde woorden uit te spreken: u had gelijk, ik heb mij vergist.

Desondanks nog wel andere puntjes...

Verder moet je het natuurlijk niet zo heel letterlijk nemen dat direct het multimediasysteem het netwerksysteem platlegt. Dat zal indirect gaan via een speciaal request naar de executive.

Lood om oud ijzer, en niet wat ik bedoel. Of het audiosysteem dat nou rechtstreeks doet of via een tussenpartij, feit is dat het audiosysteem vrij letterlijk zegt "OK, en nu had ik graag de maximale packet rate aangepast gezien". Die beslissing is het stuk dat niet netjes is. Het audiosysteem zou moeten zeggen "die-en-die thread heeft iedere 10 ms CPU-tijd nodig om belangrijke realtime zaken af te handelen". Vervolgens moet dit onafhankelijk van de audiostack weer vertaald worden naar de beslissing dat het netwerkverkeer afgeknepen wordt om DPC-tijd terug te dringen (of welk systeem dan ook dat veel DPC-tijd aan het verbruiken is). Dat is niet wat ik uit Osterman's verhaal haalde: het lijkt erop dat e.e.a. veel rechtstreekser gedaan wordt.

Je hebt niet genoeg CPU-kracht om alle DPCs te verwerken en toch alle audio/video op tijd te decoderen, worst case.

Ja, worst case. Het punt hier is nou net dat het netwerkverkeer afgeknepen wordt onafhankelijk van wat voor case het toevallig eens is, en dat het systeem zelfs niet eens probeert te kijken wat er voor maatregelen nodig zijn.

Het is alleen een bijwerking dat het netwerk ook al begrensd wordt als je wel genoeg CPU overhoudt, en dat is een kwestie van het systeem even fijnstellen.

Ja, en ik dacht dus dat dat het onderwerp van de discussie was... Dat Vista dit allemaal doet om te zorgen dat audio soepel blijft spelen ongeacht de CPU-belasting snap ik ook wel. Dat is wat ik bedoel met "daar gaat het hier niet om": hier is het geval dat je een werkbare balans wil tussen systemen met latency-eisen en systemen met throughput-eisen. Wat Vista nu doet lijkt op een vijf-uur-fix van het team dat dacht "shit, soms toch nog haperen, dat kan echt niet, knijp dan maar het netwerkverkeer af".

[Verwijderd]

Die audio-data verschijnt niet uit het niets, natuurlijk. Het zit hem in de voorkant van de stroom, niet aan de driverkant.

Exact. Op het moment dat de audiodriver merkt dat er nog geen data aangekomen is, is het al te laat.

Dat is niet wat ik uit Osterman's verhaal haalde: het lijkt erop dat e.e.a. veel rechtstreekser gedaan wordt.

Osterman zegt zelf ook dat zijn uitleg sterk versimpeld is, en verwijst naar Mark's blog voor meer info... En ook Mark geeft niet een letterlijke beschrijving.
Hoe het precies werkt, zullen we waarschijnlijk nooit weten, maar dat het verhaal redelijk rechtstreeks is, zal ook komen doordat netwerken een geisoleerd geval is.
Aan de ene kant weet je dat netwerkdrivers enorm veel interrupts per seconde kunnen genereren. Aan de andere kant weet je ook dat netwerken niet 'realtime' zijn, en als een pakketje wat vertraging oploopt, of zelfs kwijtraakt, is er niks aan de hand. Netwerken zijn gebouwd om met dergelijke situaties om te gaan.
Voor veel andere drivers geldt dit niet. Enerzijds ken ik niets dat zoveel interrupts genereert als een netwerkkaart (en zoveel tijd nodig heeft om de data te verwerken... de TCP/IP-stack is een behoorlijk ingewikkeld ding... een audio-pakketje is veel simpeler... zet het volgende pakketje in de DMA-buffer en we gaan weer), en anderzijds kan ik genoeg voorbeelden bedenken van hardware die je liever niet wilt 'knijpen', waarbij je natuurlijk wederom audio/video uitkomt als het ultieme voorbeeld.

Ik neem aan dat Microsoft het dusdanig flexibel heeft geimplementeerd dat het uitgebreid kan worden naar andere hardware, mocht daar ooit een noodzaak voor zijn, maar op het moment is die er gewoon niet.

Het punt hier is nou net dat het netwerkverkeer afgeknepen wordt onafhankelijk van wat voor case het toevallig eens is, en dat het systeem zelfs niet eens probeert te kijken wat er voor maatregelen nodig zijn.

Yup, maar je blijft natuurlijk wel bij het probleem dat je al te laat bent op het moment dat je het merkt. Je zult dus altijd minimaal 1 keer het systeem horen/zien haperen als je over die grens gaat, en de zaak moet bijstellen. Zeker met VBR-media zoals DVD en BluRay is het bijna niet te voorspellen. Er kan ineens een piek zijn in de bitrate, en dan een hele tijd weer niks.
Het is een afweging die je moet maken. Ik denk persoonlijk dat het idee van een vaste waarde niet gek is. Alleen is de combinatie van een ongelukkige standaardwaarde en het gebrek aan jumbo-frames wat triest.

Ik heb zelf ook vaak genoeg media spelertjes en dergelijke ontwikkeld, zowel op Windows als op *nix, en ik kan je vertellen dat er soms grote verschillen zitten tussen de theoretisch maximaal benodigde CPU-kracht en de praktijk, puur omdat je vaak niet de CPU-kracht kunt krijgen op het moment dat je het nodig hebt.

Wat Vista nu doet lijkt op een vijf-uur-fix van het team dat dacht "shit, soms toch nog haperen, dat kan echt niet, knijp dan maar het netwerkverkeer af".

Ik denk eerder dat het andersom is. Dat ze dit al vroeg in de ontwikkeling van Vista hebben uitgewerkt, maar dat ze er niet bij hebben nagedacht dat er bij de release, jaren later, veel snellere CPUs zijn, en gbit praktisch standaard is.
Volgens Mark Russinovich is het nog ontwikkeld voor 100 mbit, en 'single CPUs' (wat ik moet interpreteren als singlecore, gok ik).
Het is natuurlijk ook niet bepaald een bug die gauw opvalt (blijkt ook wel uit het feit dat het nu pas in het nieuws is, terwijl Vista al maanden op de markt is).
Ik vind het een storm in een glas water. Het is een schoonheidsfoutje, meer niet (als het nou in een server-OS zat, okee... maar hoeveel mensen zitten op hun kantoorpctje ettelijke gigabytes over het lan te pompen, en dan nog dusdanig dat de snelheid van belang is? Ik heb op m'n werk nog niet eens een gbit-aansluiting).

[Reactie gewijzigd door Verwijderd op 27 juli 2024 00:01]

[Verwijderd]

@ddbruijn

Mag ik weten hoe jij aan 58% niet genoeg voor HD video komt? want ik heb hier 720p h264 content die ik met minder dan 30% cpu load afspeel (op mijn low end E2160).

Ik kan me nou niet voorstellen dat 1080p opeens meer dan 58% zou gebruiken... dat zou toch zeker moeten lukken...

[Verwijderd]

Bekijk dit maar eens:
http://www.anandtech.com/video/showdoc.aspx?i=2886&p=4

[P5ycho]

Boven een aantal pakketten per seconden worden je (netwerk)interrupts zeer inefficient omdat je steeds je huidige taak moet onderbreken. Je wil dan eigenlijk eens in de zoveel tijd het OS zelf laten checken voor binnengekomen packets ipv dat de nic een interrupt request doet. Zo kun je ervoor zorgen dat je op het moment van de packetcheck ook echt al klaar staat om ze te verwerken, en je geen andere processen abrupt moet afbreken.
Vista schakelt misschien wel om naar een polling-implementatie op een bepaald moment, en daar is dan ook een timer voor nodig. (als je niet op tijd incoming packets ophaalt raken ze verloren omdat nic buffers ook niet oneindig zijn)

Waar dan precies het probleem zit betreffende de relatie met audio afspelen dat kan ik zo niet voorspellen, het zal wel met de timer te maken hebben (gedeeld ofzo?)

Zie ook FreeBSD polling, wat bij mijn server flink wat CPUload scheelt bij veel packets/sec.

Overigens claim ik niet dat vista dit systeem daadwerkelijk implementeert, maar aangezien ze een hooop opnieuw geschreven hebben zou het me niets verbazen eigenlijk.

[Reactie gewijzigd door P5ycho op 27 juli 2024 00:01]

[deadinspace]

Een bug is het niet eens.
Wat wel een bug is, is het feit dat bij meerdere NICs het maximum aantal pakketjes verkeerd berekend wordt, en hoe meer NICs, hoe minder pakketjes Vista doorlaat.
Daar hebben ze gewoon de formule niet goed geimplementeerd.

Ze hebben de formule niet goed geimplementeerd, en dus is het een bug.

Ik snap niet waarom je het gebruik van het woord "bug" aanvalt? Als het niet werkt zoals het hoort, dan is het een bug, ongeacht waar die nou precies zit. Bovendien vind ik het ook een design bug.

Het idee is mooi, en de basis is gewoon goed.

Nee, de bedoeling is goed, de uitvoering lijkt waardeloos. "Er wordt audio afgespeeld, dus we beperken het netwerk tot X packets/sec" is geen charmante oplossing.

Alleen al het bepalen van X (wat hier dus ook fout gaat!) kan nooit in elk geval goed gaan. Een trage machine zal niet veel aankunnen voordat audio skipt, een supersnelle quadcore bak trekt veel meer.

Packetgroottes hebben ook hun invloed. 10k pps zal met 9000-byte packets een stuk meer van de computer vergen dan 1-byte packets, en daarmee dus ook eerder de audio latency in gevaar brengen.

En wat als andere factoren een rol spelen? Hetzelfde systeem zal minder pps kunnen verwerken bij zware disk I/O dan met idle disks. Of bij veel interrupts van de videokaart. Of firewire. Of USB. Of allemaal.

Een fatsoenlijke oplossing lijkt me om de audio engine een dusdanige prioriteit te geven dat deze iedere 10ms aan de beurt komt, wachtende netwerk interrupts of niet. Op die manier komt de audio engine altijd aan zijn trekken en hapert het geluid dus niet, terwijl de netwerk performance pas achteruitgaat als de belasting zo hoog is dat Windows echt moet kiezen voor OF haperend geluid OF packets niet kunnen afhandelen.

Ze zullen vast hun redenen hebben gehad om het op de huidige manier aan te pakken, maar "mooi"? Sorry, nee.

[Verwijderd]

Ik snap niet waarom je het gebruik van het woord "bug" aanvalt? Als het niet werkt zoals het hoort, dan is het een bug, ongeacht waar die nou precies zit. Bovendien vind ik het ook een design bug.

Dit valt in de categorie 'semantische fouten'.
Technisch is er niets mis, maar de 'gebruiker' (in dit geval degene die de standaard-waarde heeft ingesteld) heeft verkeerde invoer gegeven, waardoor het systeem wel precies doet wat de gebruiker het systeem vertelt, maar dat is niet wat de gebruiker eigenlijk wil.
Als de gebruiker de juiste waarde invoert, werkt het systeem wel.
Als ik per ongeluk een foto opsla als jpg terwijl ik png wou, dan is dat toch ook geen bug in het programma?

Alleen al het bepalen van X (wat hier dus ook fout gaat!) kan nooit in elk geval goed gaan. Een trage machine zal niet veel aankunnen voordat audio skipt, een supersnelle quadcore bak trekt veel meer.

Dat valt dus vies tegen. Qua geheugen/I/O is er VEEL minder verschil tussen snelle CPUs en trage CPUs dan met sec berekeningen uitvoeren (grotendeels in cache). Dit is communicatie met de hardware, en dat is vooral afhankelijk van PCI-bussen, FSB etc.
Ik heb de PC jarenlang vervloekt omdat de hele architectuur zo belabberd was, waardoor realtime audio/video zeer problematisch was, en heel veel CPU-kracht vereiste (ik was een Commodore Amiga gewend). Pas met de komst van de 486 en localbus was ik 'om'.

Packetgroottes hebben ook hun invloed. 10k pps zal met 9000-byte packets een stuk meer van de computer vergen dan 1-byte packets, en daarmee dus ook eerder de audio latency in gevaar brengen.

Zoals Mark Russinovich ook uitlegt, zit het hem vooral in het verwerken van de headers in de packets. De grootte van een packet maakt niet veel uit. Of een CPU nou 1500 bytes van A naar B moet kopieren, of 9000 bytes, dat is verwaarloosbaar met de huidige geheugenbandbreedte en cachegroottes.
Jumbo-frames zijn ook specifiek in het leven geroepen om de CPU-load te verlagen:
http://sd.wareonearth.com/~phil/jumbo.html
6 keer zoveel headers verwerken voor dezelfde hoeveelheid data, DAT is wat het systeem de das omdoet. Dat is 6 keer zo vaak het systeem onderbreken, en 6 keer uitzoeken bij welke applicatie, 6 keer de status van de sockets updaten, etc etc.
Interrupts zijn de duivel, dat kan iedere systeemprogrammeur je vertellen.
In het DOS-tijdperk was het niet ongebruikelijk om interrupts compleet te negeren terwijl een spelletje bv het beeld opbouwde, omdat dit significante snelheidswinst op kon leveren.

En wat als andere factoren een rol spelen? Hetzelfde systeem zal minder pps kunnen verwerken bij zware disk I/O dan met idle disks. Of bij veel interrupts van de videokaart. Of firewire. Of USB. Of allemaal.

Het aantal interrupts per seconde dat die devices genereren is verwaarloosbaar vergeleken met een netwerkkaart.
Al die systemen gebruiken DMA, en kunnen daardoor grote stukken geheugen verplaatsen zonder assistentie van de CPU. Dat gaat niet per 1500 bytes, maar eerder per 64k of meer. Vooral harddisks en videokaarten zijn zeer 'intelligent', en hebben grote buffers en slimme processors om de CPU zo veel mogelijk te ontlasten.
Check maar met HD-tach. Om mijn raid0-systeem op de volle 140 mb/s te laten draaien, heb ik zo'n 3% CPU nodig. Dat is wel even wat anders dan de 41,61% die Mark Russinovich in zijn blog laat zien.
FireWire en USB hebben sowieso lang de bandbreedte niet om veel interrupts/dataverkeer te genereren. Gigabit is een HEEL stuk sneller.

Een fatsoenlijke oplossing lijkt me om de audio engine een dusdanige prioriteit te geven dat deze iedere 10ms aan de beurt komt, wachtende netwerk interrupts of niet. Op die manier komt de audio engine altijd aan zijn trekken en hapert het geluid dus niet, terwijl de netwerk performance pas achteruitgaat als de belasting zo hoog is dat Windows echt moet kiezen voor OF haperend geluid OF packets niet kunnen afhandelen.

Kan dus niet, zie mijn discussie hierboven met MneoreJ.
Het gaat om de userthreads, niet om de audio-engine zelf. Die audio-engine iedere 10 ms wakker laten worden is het probleem niet, maar als er geen nieuwe audio-data klaarstaat omdat je mediaplayer te weinig CPU-tijd heeft gekregen, dan hapert ie alsnog.

[Reactie gewijzigd door Verwijderd op 27 juli 2024 00:01]

[Cameleon73]

Een 'semantische fout'? Da's hetzelfde als zeggen "it's not a bug, it's an undocumented feature". Zonder nou te gaan mierenneuken over het verschil tussen een (semantische) fout en een bug: dit is simpelweg een bug.

Een verkeerd aangestuurd systeem (hoe mooi en perfect ook) werkt niet zoals het moet: bug! Maar laten we gewoon hopen dat Microsoft een mooie oplossing heeft voor deze semantiek problematiek

[Verwijderd]

Zonder nou te gaan mierenneuken over het verschil tussen een (semantische) fout en een bug: dit is simpelweg een bug.

Ben ik het pertinent niet mee eens.
Een bug is wanneer iets niet volgens specificatie werkt.
Hier werkt het systeem volgens de specificatie, alleen de specificatie zelf deugt niet.
Het is een configuratiefout, geen programmeerfout, en daarom vind ik het woord 'bug' niet op z'n plaats.

Definitie gevonden volgens define:bug in Google:
"A computer bug is an error, flaw, mistake, failure, or fault in a computer program that prevents it from working correctly or produces an incorrect result. Bugs arise from mistakes and errors, made by people, in either a program's source code or its design."

Er zit hier geen fout in de sourcecode, en ook niet in het ontwerp (de bedoeling is om het netwerk te beperken tot X pakketjes per seconde, om het aantal interrupts per seconde te beperken, zodat er genoeg CPU-resources in userspace overblijven, en je kunt niet ontkennen dat Vista precies datgene doet. Het werkt eerder 'te goed', als in te conservatief).
Er wordt geen fout resultaat geproduceerd, niets loopt vast, en alles werkt in principe correct.
Alleen het getalletje '10000 pakketjes per seconde' is niet helemaal lekker gekozen, gecombineerd met het feit dat veel mensen blijkbaar niet weten wat een jumbo-frame is, en waarom die altijd gebruikt moeten worden op gigabit-netwerken.
Van een echte fout kun je ook niet eens spreken, want zoals Mark Russinovich vertelt, is het destijds op systemen met 100 mbit-hardware getest (1 gbit was destijds zeker nog niet gangbaar), en daar is er ook geen enkel probleem.
Door gewoon het getalletje '10000' aan te passen werkt hetzelfde ontwerp en dezelfde sourcecode beter met gbit-netwerken.

Nou heb ik dus nog nooit gehoord dat iemand een misconfiguratie een 'bug' noemde. Men spreekt dan eerder van een 'issue'.

Van een bug mag je spreken als er verkeerde resultaten geproduceerd worden, zoals bv bij het gebruik van meerdere kaarten, waar het aantal pakketjes per seconde steeds verder beperkt wordt, zoals ik in m'n eerste post al aangaf. Dat kan gewoon nooit de bedoeling geweest zijn.

Maar goed, als je liever MS afzeikt dan correcte terminologie gebruikt, noem het dan maar een bug.

[Reactie gewijzigd door Verwijderd op 27 juli 2024 00:01]

[yvesg]

Ik erger mij ook al een tijdje aan de traagheid van de network connections in vista zelf.
Als ik bestanden kopieer van desktop naar server (Vista > W2K3) haal ik nooit meer dan 3MB/s over een full gigabit lijn.

Kopieer ik daarentegen een bestand van mijn ftp servertje dat maar een simpele P3 is met een 100Mbit interface dan gaat dat tegen een verbluffende 10 à 11MB/s.
NB dat die ftp ACHTER mijn linux routing firewall pc staat, dus de gateway moet de pakketen nog masqueraden & 2 switchen passeren. Niet dat dit laatste zoveel uitmaakt, maar het is wel een ENORM verschil als je weet dat mijn pc en server op de zelfde gigabit switch zijn aangesloten.

<EDIT> Weet zelfs niet met 100% zekerheid te zeggen dat audio hierin een rol speelt. Heeft er gewoon altijd last van.</EDIT>

[Reactie gewijzigd door yvesg op 27 juli 2024 00:01]

[MAX3400]

Hoeveel mensen trekken geregeld hun Gbit-NIC dicht? Oftewel; met een theoretische snelheid van 128MB per seconde bij meer dan 10.000 packets?

Er lijkt dus meer aan de hand dan wat Microsoft toegeeft...

[Reactie gewijzigd door MAX3400 op 27 juli 2024 00:01]

[Verwijderd]

Net eventjes gekeken in NIC properties, en elke MB kost ongeveer 1000 packets, nu top ikzelf maximaal uit rond de 9MB/s op mijn 100Mbit netwerk, en zit dus al erg dicht tegen die 10k packet limiet waarbij dus problemen komen.

Met een 300Mbps, 1Gbps of sneller netwerk zit je dus bijna altijd over die limiet heen en vele mensen hebben die snelheid tegenwoordig, vandaar dus ook zoveel klachten.

Jumbo packets daargelaten, en ik heb het grof gedaan, maar met Wireshark is dat precies na te zoeken. Heb zelf echter nog steeds Vista met rust gelaten op mijn persoonlijke systemen dus kan geen goede vergelijking maken.

[Verwijderd]

300Mbps netwerk?? is dat een OC-iets verbinding ofzo?

[Turtle]

300Mbps klinkt als 802.11n (nieuwe Wi-Fi / wireless LAN). Die zal effectief echter nog niet de helft halen, dus komt onder de 150Mb (~15MB) en daarmee altijd weg met "maar" 10.000 pakketten.

[Kuhlie]

Met 10000 packets met hun volledige standaardgrootte van 1500 bytes hebben we het hier over bijna 15 megabyte per seconde. Ook als ik muziek luister zou ik meer door mijn gigabitverbinding heen willen trekken hoor

[freeco]

zo'n 12-15MB/s is idd wat ik sinds Vista nog over mijn gigabit lan kan trekken. Maar da's bij mij altijd zo, ook zonder winamp open... Zelfde PC met XP haalde vroeger 20-25MB/s. Dacht eerst dat het aan brakke Vista drivers lag van mijn Attansic L1 chip op mijn Asus P5B-E bord, maar na het lezen dat het een algemener probleem was, maar wat verder gezocht.
Ik heb gisteren de bak een volledige reinstall gegeven en de 2 performance en reliability patches gerund. Nu eens uitgebreid testen of dat iets verhelpt... Via USB2 merk ik toch ook al een bescheiden snelheidswinst. Nu toch 25MB/s bij het copieren van MP3's, vroeger ook een 15MB/s.

[NjedVet]

Zeker ook gezien het feit dat het bij XP niet voorkomt (althans, daar heb ik nooit iets over gehoord). En XP ondersteund ook Gigabit Interfaces. . .

[Abom]

Vista heeft echter een geheel nieuwe audio architectuur, zoals je kunt lezen in het artikel is dat ook de boosdoener...

[The_DoubleU]

Audio is NIET de boosdoener.
Microsoft heeft een scheduler gemaakt die het netwerk aanpast wanneer audio programma's gestart worden.
Dit hebben ze op een zeer domme manier gedaan.
Netwerk prioriteit wordt naar beneden gezet ook al zijn er genoeg systeem resources vrij.
+ Hoeveel pakketjes er gedropt worden is in de code geschreven en is niet aanpasbaar door de eindgebruiker.
Daarom zul je dit ook niet merken op een 100Mb kaartje maar wel op een Gigabit kaartje.
Lees dit eens door.

En nog steeds hebben ze niet verklaard waarom het afspelen van media + netwerk zoveel van het systeem vraagt.
Ik gok op DRM.

[Cameleon73]

The hard-coded limit was short-sighted with respect to today’s systems that have faster CPUs, multiple cores and Gigabit networks, and...

(uit het artikel van Mark Russinovich)

Dat vind ik dus een beetje vreemd: de 10.000 pakketjes grens is bepaald a.d.h.v. 100Mb apparatuur. En ik maar denken dat Vista het onderste uit m'n nieuwe hardware haalt!

[roy-t]

Vista heeft een compleet nieuwe netwerkinterface, allemaal leuke dingen om dynamisch dingen te regelen en om realtime of per x-clockticks packets af te handelen. Vandaar dat het niet in XP gebeurd.

* roy-t heeft er zelf eigenlijk geen last van gehad

[Verwijderd]

"Dit proces heeft dus een hoge prioriteit, maar dat geldt ook voor het netwerkverkeer. Omdat het netwerk de audio engine kan beletten om elke 10ms zijn werk te doen, moet Vista ingrijpen om hoorbare storingen te voorkomen."


BULLSHIT... waarom kan zelfs windows 2000 muziek afspelen zonder onderbreking of netwerkvertraging? Of is die nieuwe architectuur van Vista gewoon inferieur?

[Verwijderd]

BULLSHIT... waarom kan zelfs windows 2000 muziek afspelen zonder onderbreking of netwerkvertraging? Of is die nieuwe architectuur van Vista gewoon inferieur?

Bijna niemand had toen gbit, dus merkte bijna niemand dat muziek kon gaan haperen bij het overpompen van veel data.
Het probleem bestond dus eigenlijk niet in de tijd van 2k (en deels XP), het is van de laatste tijd. En Microsoft pakt dat meteen aan in de nieuwe Windows-versie. Het is echt geen onzin dat Vista ontworpen is voor moderne PCs. Dit is een voorbeeld ervan.
Dat er een kinderziekte in zit, soit. Maar er is wel rekening mee gehouden. Straks even een patch, en hop, Vista is de enige Windows die media kan spelen zonder problemen van netwerkverkeer te ondervinden.

[Verwijderd]

Dit heeft niks met de scheduler te maken. Lees nou die blog van Mark Russinovich eens, en denk ook eens logisch na.
Interrupts kunnen niet via de scheduler afgehandeld worden, die heeft een te lage resolutie. Waarom denk je dat pre-emptive multitasking uitgevonden is?
Interrupts moeten *meteen* afgehandeld worden.. Als je het met de scheduler doet, heb je zomaar een vertraging van 20 ms te pakken, en dat is onacceptabel.
Het probleem ontstaat dus op het moment dat je te veel interrupts per seconde krijgt, en die interrupts teveel tijd kosten om af te handelen.
Omdat interrupts voorrang hebben op alles, komen je applicaties dus in het gedrang.
Nogmaals, ik verwijs naar http://sd.wareonearth.com/~phil/jumbo.html
Je ziet dat een aantal jaren geleden ook en 300 Mhz Sun systeem gewoon 100% CPU gebruikte, en daarbij maar 400 mbps haalde.
En Sun staat met zijn Solaris juist bekend als van de beste multi-CPU schedulers op de markt.

Windows bashen is dus veel te makkelijk. Alle OSen hebben hier last van. Op bovengenoemd Sun-systeem zou je uiteraard ook niet eens een mp3tje kunnen afspelen, omdat er geen CPU-resources meer zijn.
En zelfs met jumbo-packets blijft het CPU-gebruik behoorlijk hoog.
En zoals we hier zien:
http://www.anandtech.com/video/showdoc.aspx?i=2886&p=4
Zelfs een E6600 heeft nog best wel wat werk aan een h264 film, en dat is toch een behoorlijk snelle CPU.
Zeer logisch dus dat Microsoft hier een mechanisme moet maken om in te grijpen, wil je je media zonder problemen kunnen afspelen, zeker op wat minder snelle systemen.

Tot zover les 1 in de basis van organisatie van computersystemen.

[MneoreJ]

Jij bent nooit tegen de scenario's aangelopen waaronder 2000 en XP het niet meer trekken. Kijk anders even op meneer Osterman's blog, waar hij deze stelling poneert ("To blow away multimedia playback on XP, all you need to do is to have an app that loads the CPU running at priority 15.")

Vista's probleem is dat het een beetje te proactief is met het oplossen van haperingsproblemen die veel mensen niet eens hebben (ik heb op mijn systeem ook niet zoveel processen die met een hogere prioriteit gaan draaien), en daarbij zijn eigen problemen introduceert.

[Dutch2007]

het audio systeem zit anders in elkaar, draait niet meer direct op de kernel, draait nu in usern niveau, dus jah tis anders dan NT/2000/XP

[kidde]

Of is die nieuwe architectuur van Vista gewoon inferieur?

Volgens de maker van de network-stack van Vista (niet Microsoft zelf overigens), het bedrijf NetQoS.inc, wel enigzins ja, en daarom zitten de 'twijfelachtige' delen ervan ook niet in de Enterprise editie van Vista. De oude BSD netwerk stack, gebruikt vanaf NT tot XP - is jarenlang verbeterd en getest - dat laatste door honderden miljoenen, maar de NetQoS stack is niet goed genoeg getest lijkt het,

Wat NetQoS er zelf over zegt: NetQoS still recommends testing it on a small scale before rolling it out across the enterprise (Zie mijn eerdere post hierover)

[Reactie gewijzigd door kidde op 27 juli 2024 00:01]

[Avdo]

Het is mij echt niet duidelijk hoe Microsoft met zijn problemen omgaat. Zoek maar eens op google en vista network issues. Overal worden oplossingen gesuggereerd, maar nergens is er een werkelijke oplossing te vinden.
Wanneer je vervoglens met Microsofts helpdesk belt... Dan moet je eerst 60 euro betalen voor het antwoord dat er nog geen oplossing is voor het probleem.
Uiteindelijk is het een driver programmeur die het probleem tot op de bodem uizoekt en met een oplossing komt? Vreemd voor een bedrijf dat zon positie heeft.

[Nooto]

Een tijd terug had ik een probleem met mijn Exchange 2000 server en had ik contact opgenomen met de Microsoft support om het op te lossen.
Moest op het begin wel een creditcard nummer geven, maar omdat de fout in de Exchange programmatuur zat en moest worden opgelost met een speciale hotfix werd er niets in rekening gebracht.

[MAX3400]

Ja, dat klopt dat je moet betalen. Of heb jij een apart support-contract bij je Vista-installatie gekocht?

Iets met kleine lettertjes en licentie-mogelijkheden eens doornemen.

[tweakerbee]

Het probleem is niet dat je moet betalen voor een vraag, het probleem is dat je moet betalen voor een vraag die je:
a) in de eerste plaats niet had hoeven stellen (het is HUN fout)
b) niet fatsoenlijk beantwoord krijgt van MS, nml. idd hij doet het niet

[Avdo]

Support contract? Die lui krijgen geen cent van mij.... Enige reden dat ik vista legaal heb is omdat ik m van de universiteit heb gekregen :\

[Zyppora]

En als ik mijn muziek nu op een thuisserver heb staan en deze 'streaming' beluister? Wordt het netwerk dan ook afgeknepen? Zou wel erg messy zijn als dat ook zo zou zijn (en ik lees nergens dat het niet zo zou zijn).

[Reactie gewijzigd door Zyppora op 27 juli 2024 00:01]

[Adion]

Ik denk niet dat er muziek is of zelfs films die meer dan 100Mbps nodig hebben om af te spelen. Als dat verkeer dus ook prioriteit krijgt boven het andere verkeer dan kan dat er nog net door.
Volgens wat ik hier op tweakers van het probleem lees vind ik het overigens maar een vreemde 'oplossing' die microsoft bedacht heeft om gewoon een vaste limiet te hanteren.
Op het moment dat je die limiet bedenkt kan je toch al gaan rekenen dat het vanaf x mbps voor problemen zal zorgen.
Ik snap hoe dan ook niet helemaal het probleem eigenlijk. De audio heeft idd dus elke 10 ms even tijd nodig, maar een beetje audio kopieren/decoden vergt toch slechts een paar procent cpu tijd tegenwoordig, dus zolang als de netwerkkaart beperkt wordt tot 9 ms werken bijvoorbeeld hoort dit toch geen probleem te zijn?

[OddesE]

Het probleem is dat de timing van interrupts niet met die precisie gebeurt. De netwerk interface zal waarschijnlijk zelf de processor 'afgeven' na x pakketjes. Als de processor door een timer interrupt afgepakt moet worden dan ben je al te laat.

Sowieso valt mij op dat als ik een zware pagina binnenhaal met welke browser dan ook, Windows XP vaak even lijkt te 'hangen'. Task switchen lukt dan vaak ook even niet. Die network I/O loopt niet smooth. Opvallens is dat de taskswitch en het binnenkomen van de pagina dan tegelijk gebeuren. De PC schiet dan ineens weer 'los', net alsof hij op de internet server aan het wachten was. Als dat verbeterd is in Vista dan lijkt me dat fantastisch. Herkent iemand dit?

[GeeMoney]

Nog geen pure 1080P films afgespeelt denk ik?
Met 100Mbps red je dit niet vloeiend hoor.

[Milt]

Zou toch wel moeten hoor... 1080p met H.264 is ongeveer 15 Mbit/s. Met MPEG2 ongeveer 30 Mbit/s. Dat moet op een 100 Mbit/s netwerk geen probleem zijn, tenzij er nog het nodige andere verkeer is.

[Pietervs]

tenzij er nog het nodige andere verkeer is.
Er is altijd ander verkeer, zeker als je nog een paar PC's hebt staan met oudere Windows-versies erop. Vraag is alleen hoeveel ander verkeer, of dit een beetje goed gerouteerd wordt, enzovoort...

[LDenninger]

Hoera, er is weer een reden voor alle 14-jarige bleke puistenkoppen om microsoft te bashen !

Tja, shit happens.
De hele audio-interface is veranderd en een stuk logischer geworden.
Het zal alleen - zoals vaak met vernieuwingen - even duren voor het allemaal naadloos aansluit.
Een ongeluk / probleempje zit in een klein hoekje.

[Zyppora]

Wat is dit nu weer voor non-post?

A. Ik weet niet hoeveel 14-jarige bleke puistenkoppen jij kent, maar veel van de mensen die er negatieve gedachten over MS op na houden hebben daar gegronde reden toe.

B. Shit happens indeed, maar om nu voor die shit te moeten betalen ...

C. Volgens mij is de interface van WMP11 (ik ga er even vanuit dat het probleem zich daar ook voordoet) tov. diezelfde WMP11 op XP niet noemenswaardig veranderd is.

D. Naadloos aansluiten? Waarom überhaupt linken van audio playback en networking? Zo gigantisch veel CPU cycles hoeft networking toch niet te kosten? Denk dan eerder aan video editing/encrypting/etc. op de achtergrond tijdens het kijken van een DVD of zo. Daar zou ik juist de problemen verwachten:

Het komt er op neer dat een Vista-systeem het inkomende netwerkverkeer afknijpt om te voorkomen dat de weergave van multimedia in gevaar komt.'

Ik kan me nauwelijks voorstellen dat networking de grootste bedreiging vormt voor de weergave van media qua resources.

[Reactie gewijzigd door Zyppora op 27 juli 2024 00:01]

[Abom]

A. veel van de mensen die echt negatief over MS denken, begrijpen nog altijd niet dat MS gewoon net zoals elk ander groot bedrijf, goed is in zaken doen en niet, itt de OSS wereld, altijd het meest maatschappij verantwoord handeld...

B. ik betaal wel meer voor software wat ik veel minder gebruik en slechter gebouwd is...

C. Welke interface? Het probleem wordt veroorzaakt door de vernieuwde audio architectuur in Vista...het ziet er voor jou misschien hetzeflde, dat betekend niet dat het op de achtergrond exact hetzelfde werkt...

D. Wie zegt dat networking en audio aan mekaar gelinkt is? Er wordt gezegd dat beide processen met een verhoogde prioriteit afgehandeld worden. Networking kan overigens best zwaar zijn voor je systeem, vandaar dat veel gigabit NICs de CPU kunnen ontlasten door zelf veel berekening af te handelen.

Wat ik echter wel kwalijk vind is dat dit probleem blijkbaar al aan het licht is gekomen tijdens de beta...

[Reactie gewijzigd door Abom op 27 juli 2024 00:01]

[The_DoubleU]

Hou nou eens op Abom.
Het komt NIET door de audio. Het komt doordat MS geen goede scheduler heeft geschreven.
http://blogs.technet.com/...e/2007/08/27/1833290.aspx

En kom voor een PC dat Vista kan draaien moet een beetje netwerk verkeer + mp3 afspelen toch geen probleem zijn? Of worden alle resources gebruikt door die DRM checks die elke 10 sec uitgevoerd worden?

[Abom]

Hey huilie, het is niet mijn schuld dat de schrijver van het artikel beweerd dat het aan de vernieuwde audio engine ligt.

Als je zelf al zegt dat het aan de MMCSS ligt, waarom kom je alsnog met de paranoide opmerking over DRM...

[Zyppora]

A. Als een bedrijf niet maatschappij verantwoord handelt, dan is dat toch een gegronde reden om negatief over dat bedrijf te denken? Daarnaast versta ik de vergelijking tussen de concurrent en kanker niet als 'goed zijn in zakendoen'.

B. Tja, da's een keuze die jij zelf maakt. Bij het aanschaffen van een computer is die keuze vaak niet aanwezig (maar gelukkig steeds meer door de kritieken op Vista).

C. Excuses, ik kreeg de indruk dat het hier echt om de UI ging. Maar dat neemt niet weg dat de architectuur dan gewoon brak is. Op XP heb ik daar geen last van, waarom op Vista wel?

D. Zoals ik al aangaf, ik kan me niet voorstellen dat networking qua resources ook maar in de buurt komt van bijv. video editing/encrypting/etc. Magoed, ik ben daar geen guru in.

[OkkE]

Het feit dat netwerk-verkeer wordt geknepen, op een snelheid die gewoon laag is, omdat er multimedia afgespeeld wordt, noem ik niet een 'ongeluk / probleempje', en vind ik ook niet perse logisch.

Het zou mooi zijn wanneer ze een optie maken in Vista, dat je als gebruiker zelf kunt aangeven of je netwerk-verkeer belangrijker vindt, of toch de multimedia.

Persoonlijk heb ik namelijk liever een stotterende HD-film tijdens hevig netwerk-verkeer als een traag netwerk. En zoals al door meer mensen opgemerkt, bij afspelen van bijvoorbeeld audio, heb ik nog nooit last gehad van stotterende muziek tijdens netwerk-verkeer. Al heb ik geen Vista, maar onder XP nooit iets gemerkt.

@Egodepego; Ja, het kan ook door geen Vista te gebruiken. Niet echt zinnige oplossing, ik zet mijn mediaplayer zelf wel op pauze, als ik de stotteringen te erg vind worden. Tot die tijd, vind ik dat mijn OS van dit soort dingen af moet blijven.

[Reactie gewijzigd door OkkE op 27 juli 2024 00:01]

[Verwijderd]

Het zou mooi zijn wanneer ze een optie maken in Vista, dat je als gebruiker zelf kunt aangeven of je netwerk-verkeer belangrijker vindt, of toch de multimedia.

Komop, audo afspelen kost 5 MHz en netwerkverkeer ook (nou ja, beetje gechargeerd, maar je begrijpt me wel). Hoe kan het in hemelsnaam zo zijn dat een 2 GHz+ dulacore-processor hier nu last van heeft? Je moet toch met gemak een audiostream én een netwerkverbinding in de lucht kunnen houden.

Ik wil met zo'n geavanceerd systeem helemaal niet voor die keuze komen te staan. Dat mag als je 60 MHz tot je beschikking hebt, dan kan het niet allemaal tegelijk, maar als je meerdere gigaherzen hebt is het ronduit belachelijk.

Ik heb het idee dat er een beetje een brakke implementatie is gekozen.

[Reactie gewijzigd door Verwijderd op 27 juli 2024 00:01]

[Thyraon]

Het mag dan een klein hoekje zijn, het staat gewoon een beetje slordig dat een operating system dat met veel bombarie op de markt gezet wordt - nota bene gepositioneerd als hét OS om je multimedia mee te bekijken en beluisteren - en lijdt aan zulke knullige kinderziektes.

Ik gun Microsoft de klandizie en cash van harte, ik had alleen veel meer van Vista verwacht, zowel qua features en mogelijkheden als qua stabiliteit bij release.
Dat het dan ook nog zo lang duurt voor een redelijk vervelend probleem als dit opgelost is, zou ik als Vista-gebruiker onacceptabel vinden.

(Oh ja, by the way, ik ben een 21-jarige zongebruinde Adonis )

[Reactie gewijzigd door Thyraon op 27 juli 2024 00:01]

[scsirob]

Het is ook niet bepaald iets waar MS pas achter kwam nadat Vista ge-released was. In de beta groups is er meer dan een jaar lang over geklaagd, zonder dat MS dit als een serieus probleem zag. In dit geval dus eigen schuld, dikke bult voor MS

[Justice]

interessant, dit geldt dan ook voor online games. Audio engine + netwerk verkeer. Nou heb je natuurlijk niet de hele bandbreedte nodig, maar het zou wellicht je ping kunnen verhogen? Wie weet.

[roy-t]

mwah, tenzij je BF2 speelt (idiot veel packets nodig) zal dit wel mee vallen, misschien een ping van 1ms erbij. maar 10MB/s heb je niet nodig om te gamen, ik denk dat de gemidelde game ongeveer 10KB/s nodig heeft

[BillyBee]

... online games trekken een fatsoenlijke breedband verbinding nog niet vol, laat staan een 100mb verbinding, laat staan 1gb verbindingen... zolang als je niet aan die snelheden komt wordt er dus ook niet geknepen, aldus het nieuws bericht.

[peter007]

Lijkt me toch een redelijke ernstige bug.

Probeer maar eens een rdp sessie te openen naar een 2003 server. Dat gaat ook bijna niet werkbaar.

oplossing is trouwens al aanwezig:

netsh interface tcp set global autotuning=disabled

[MAX3400]

Vreemd; heb dagelijks tientallen RDP-sessies naar 2003-omgevingen zonder problemen. Maar ja, heb tijdens mijn werk dan ook geen (streaming) audio aan staan.

[Verwijderd]

Ikke wel. Geen tientallen, wel verschillende sessies gelijktijdig. (icm streaming audio dus)
Ook op gigabit nog geen probleem geconstateerd met de doorvoer of de performance van de RDP sessies.
(nooit throughput gemeten bij file-acties, trouwens)

[Reactie gewijzigd door Verwijderd op 27 juli 2024 00:01]

[TheVMaster]

Hmm...ik bouw met regelmaat vanaf mijn Vista machines RDP sessies op naar zowel 2003 als 2008 servers en moet zeggen dat dat best soepel gaat.

Ik zou ook niet weten wat dat met de genoemde audio-bug te maken heeft

[WhiteDog]

Ik heb een ander probleem. Als ik files download via het netwerk dan begint hij @ 35 MB / sec. enkele seconden later is het nog 1 MB / sec. Waarna hij weer omhoog schiet naar 35 MB / sec. Data uploaden is geen probleem.

Ter info: Gigabit netwerk, transfer tussen 2 RAID systemen.