/u/48313/ava_mega_60.png?f=community)
Dames en heren, jongens en meisjes,
het is al weer heel lang geleden dat ik iets op GoT gepost heb. Maar gezien de grote hoeveelheid kennis en ervaring dat zich hier verzameld heeft wil ik toch mijn vraag hier neerleggen. Helaas heb ik niets specifieks kunnen vinden via de gebruikelijke zoekmethoden.
Aangezien ik dol ben op statistieken en grafiekjes wil ik ook graag weten hoeveel 1-en en 0-en er mijn computer binnenkomen en verlaten via de netwerkkaart. Echter heb ik al sinds ik mijn huidige PC heb een probleem met de aangegeven download snelheid. En dan niet eens zo zeer dat hij te laag naar mijn zin is...
In mijn PC zit een ASUS P5W DH Deluxe moederplank met onboard de Marvell Yukon 88E8053 PCI-Ethernet Controller. Daarop draait Windows XP met sinds kort SP3 en altijd de laatste updates. Mijn BIOS is versie 2406 (met oudere BIOS versies zelfde verhaal). Ik heb getest met NIC drivers 8.56.1.3 (ASUS website), 10.51.x (Windows update) en 10.61.2.3 (Marvell website). De laatste is zelfs pas van mei dit jaar.
Het probleem is dat bij de waarde voor Bytes received/sec, de waarde voor Bytes sent/sec opgeteld wordt. Dit is zichtbaar met Windows perfmon, Hagelsoft DU Meter en LCD Studio. Voor zover ik weet gebruiken die echter dezelfde counters. Wanneer ik de snelheden opvraag met SNMP (MRTG) krijg ik wel de juiste waarden terug. Let wel dat deze niet echt de snelheid opvraagt, maar kijkt naar het totaal aantal verzonden/ontvangen bytes en zelf de snelheid uitrekent door de twee laatste waarden te vergelijken.
Als voorbeeld heb ik een plaatje gemaakt:
Het is geen Picasso, maar het idee zal duidelijk zijn... Ik had daar een upload aanstaan met 82 kB/sec en GEEN downloads. Desondanks melden eerder genoemde programma's dat de download snelheid 86 kB/sec zou zijn. Dat had natuurlijk slechts 4 moeten aangeven!
Het probleem is op twee manieren op te lossen. Ten eerste kan ik via Device Manager de adapter uitschakelen en vervolgens weer inschakelen. De waarden zijn daarna correct. Maar na een reboot is het weer prut.
Als tweede optie kan ik de PC opstarten met de UTP kabel ontkoppeld. Als ik de kabel pas terugstop nadat Windows helemaal opgestart is werkt het ook goed. Datzelfde geldt wanneer ik de kabel bij opstarten in LAN1 stop en daarna overga naar LAN2. (Op het mobo zitten twee aansluitingen.)
Het helpt geen moer als ik de kabel los haal en weer aansluit op dezelfde aansluiting terwijl Windows actief is. Repareren van de verbinding geeft ook geen soelaas.
Ook heb ik de Yukon Diag (v 7.30.2.3) utility gedraaid welke aangaf dat alle tests succesvol waren uitgevoerd.
Op dit moment heb ik een batch file in mijn startup folder staan die via devcon de NIC uit- en weer inschakelt. Dit werkt op zich wel, maar is niet echt ideaal natuurlijk...
Mijn vraag is eigenlijk of iemand dit zelfde probleem bemerkt heeft en er een [b]echte[b] oplossing voor heeft. Of misschien zijn er mensen met hetzelfde mobo die op dit probleem willen testen en willen laten weten of zij hetzelfde gedrag zien?
Sorry voor de lange post, maar ik wil zo veel mogelijk info geven. Oops, is het al weer zo laat?
het is al weer heel lang geleden dat ik iets op GoT gepost heb. Maar gezien de grote hoeveelheid kennis en ervaring dat zich hier verzameld heeft wil ik toch mijn vraag hier neerleggen. Helaas heb ik niets specifieks kunnen vinden via de gebruikelijke zoekmethoden.
Aangezien ik dol ben op statistieken en grafiekjes wil ik ook graag weten hoeveel 1-en en 0-en er mijn computer binnenkomen en verlaten via de netwerkkaart. Echter heb ik al sinds ik mijn huidige PC heb een probleem met de aangegeven download snelheid. En dan niet eens zo zeer dat hij te laag naar mijn zin is...
In mijn PC zit een ASUS P5W DH Deluxe moederplank met onboard de Marvell Yukon 88E8053 PCI-Ethernet Controller. Daarop draait Windows XP met sinds kort SP3 en altijd de laatste updates. Mijn BIOS is versie 2406 (met oudere BIOS versies zelfde verhaal). Ik heb getest met NIC drivers 8.56.1.3 (ASUS website), 10.51.x (Windows update) en 10.61.2.3 (Marvell website). De laatste is zelfs pas van mei dit jaar.
Het probleem is dat bij de waarde voor Bytes received/sec, de waarde voor Bytes sent/sec opgeteld wordt. Dit is zichtbaar met Windows perfmon, Hagelsoft DU Meter en LCD Studio. Voor zover ik weet gebruiken die echter dezelfde counters. Wanneer ik de snelheden opvraag met SNMP (MRTG) krijg ik wel de juiste waarden terug. Let wel dat deze niet echt de snelheid opvraagt, maar kijkt naar het totaal aantal verzonden/ontvangen bytes en zelf de snelheid uitrekent door de twee laatste waarden te vergelijken.
Als voorbeeld heb ik een plaatje gemaakt:
Het is geen Picasso, maar het idee zal duidelijk zijn... Ik had daar een upload aanstaan met 82 kB/sec en GEEN downloads. Desondanks melden eerder genoemde programma's dat de download snelheid 86 kB/sec zou zijn. Dat had natuurlijk slechts 4 moeten aangeven!
Het probleem is op twee manieren op te lossen. Ten eerste kan ik via Device Manager de adapter uitschakelen en vervolgens weer inschakelen. De waarden zijn daarna correct. Maar na een reboot is het weer prut.
Als tweede optie kan ik de PC opstarten met de UTP kabel ontkoppeld. Als ik de kabel pas terugstop nadat Windows helemaal opgestart is werkt het ook goed. Datzelfde geldt wanneer ik de kabel bij opstarten in LAN1 stop en daarna overga naar LAN2. (Op het mobo zitten twee aansluitingen.)
Het helpt geen moer als ik de kabel los haal en weer aansluit op dezelfde aansluiting terwijl Windows actief is. Repareren van de verbinding geeft ook geen soelaas.
Ook heb ik de Yukon Diag (v 7.30.2.3) utility gedraaid welke aangaf dat alle tests succesvol waren uitgevoerd.
Op dit moment heb ik een batch file in mijn startup folder staan die via devcon de NIC uit- en weer inschakelt. Dit werkt op zich wel, maar is niet echt ideaal natuurlijk...
Mijn vraag is eigenlijk of iemand dit zelfde probleem bemerkt heeft en er een [b]echte[b] oplossing voor heeft. Of misschien zijn er mensen met hetzelfde mobo die op dit probleem willen testen en willen laten weten of zij hetzelfde gedrag zien?
Sorry voor de lange post, maar ik wil zo veel mogelijk info geven. Oops, is het al weer zo laat?
[ Voor 10% gewijzigd door MegamanNL op 26-11-2010 10:12 ]
Vroooommmm